Subject: RE: [Enum] ..and I quote

From: "Stastny, Richard" <[email-masked]>
Date: Tue, 28 May 2002 13:21:09 +0200

Lawrence wrote, to which I reply:

> -----Original Message-----
> From: Lawrence Conroy [mailto:[email-masked]] 
> Sent: Monday, May 27, 2002 9:12 PM
> To: [email-masked]
> Subject: [Enum] ..and I quote
> 
>> 
> OK, if we need to add URI-scheme to the service field, we add 
> it. If we do this, then the sipvoice in the above extract 
> might become "sip-voice".
> 
> If people want to tag more than one enumservice, then this 
> could be sip+voice+somethingelse (assuming that the 
> somethingelse RFC included sip: as a valid protocol).

Agreed, but I would like to suggest (as already proposed in my response to
Rich), and as also proposed by Lawrence:

At 3:38 pm +0100 26/5/02, Lawrence wrote:
> >Thus, the syntax gets a little tricky here. I guess that 
> something like:
> >     <D3S-application-tag> - <URI-scheme> 1*( + 
> <enumservice-tag>) is 
> >better - i.e. have the URI scheme immediately after the 'E2U' D3S 
> >application tag, and before any enumservice list.

that we do it the other way round:

We take the URI-scheme and add the services. This would resolve also the
problem for using one URI (e.g. tel) for multiple services. It may also
solve the sip(srs) problem, that you either list all available services with
sip, or provide only the sip URI (either with no service or a default (any
or *)), meaning that the services should be negotiated. 

If one has other NAPTRs beside sip with services, this would mean that all
other services may be negotiated besides the one listed.

It would also allow a "forwarding" of the whole domain with the new URI
enum:+431..., meaning, that another ENUM query should be made with the given
number, either for all services or only for the service listed.

Eg: NAPTR blabla "E2U-enum+*" blabla enum:+431...
Or
NAPTR blabla "E2U-enum+voice" blabla enum:+431... if the fwd is only for
voice

One can assume, that normally a user provides in any case only one URI for a
given service, and the order and preference fields will not be used. If
really a user wants to provide more than one URI for a given, he could use
the preference field (and he shall use only one URI and one service:
E.g.
NAPTR 10 10 "E2U-sip+voice" blabla sip:[email-masked]
NAPTR 10 20 "E2U-tel+voice" blabla tel:+34...

IMHO opinion we should provide templates for registration, but not for the
services, but for the URI-schemes used. Each template should list the
allowed services for the URI in context with ENUM. This also would be a nice
cleanup of the currently (a bit messy) URI definitions. I honestly have
currently no complete picture of all of the URIs under discussion with ENUM.

I think it is also better practice, if the URI experts provide the basic
templates than the service experts. The services experts may than add
services to the basic templates.

Best regards
Richard

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum