RE: AW: [Enum] enumservices in new version of 2916bis

Comments inline:

> -----Original Message-----
> From: Richard Shockey [mailto:rshockey@ix.netcom.com] 
> Sent: Friday, June 28, 2002 4:42 AM
> To: Stastny Richard; Peterson, Jon; rwalter@netnumber.com; 
> enum@ietf.org
> Subject: Re: AW: [Enum] enumservices in new version of 2916bis

> Jons request could the be fullfilled either with "E2U+sip", where 
> negotiation is the default, or "E2U+sip+srs",
> 
> or in the Walter convention ..."E2U+sip:srs"  ?? IMHO there 
> is much to 
> recommend in his approach....  Rudolf? Larry?  are we close here?
> 

If used in this order, I have to admit, that I cannot reject this
proposal, because it is in principle the combination of the "3.1 Simple
URI Scheme" and "3.2 Combined URI Schemes and Services" from my
draft-stastny-enum-services-analysis-00.txt

The difference is that I proposed to use +telvoice, +telfax, +sipvoice,
etc., but this is obviously the same as +tel:voice, +tel:fax,
+sip:voice.

I only have the following requirements for the definition of
"E2U+URI:svc+addinfo":

1. The "svc" SHALL be the same as defined with the URI Scheme used, and
SHALL be defined with the URI Scheme. Only defined svc shall be used.
The idea behind this is that it shall be possible (and shall be the same
for the application-SW) to use a URI equivalent to the one used in the
NAPTR also stand-alone on a webpage.

2. An "svc" SHALL be defined (used) consistently over all URI Schemes,
if used in more than one URI Scheme. So e.g. svc=voice has the same
meaning in tel:, sip:, etc.

3. A NAPTR containing "E2U+tel:voice+tel:fax"
"...tel:+431xxx;svc=voice,fax!" is equivalent to 
"E2U+tel:voice+tel:fax" "...tel:+431...!" or should two NAPTRs be used
in that case?

4. Only the URI Scheme is mandatory, but only if there is a "u" flag, to
keep Lawrence happy;-)

5. There is a definition necessary, what it means, if only the URI
scheme is used:
A. Define a default (e.g. mailto defaults to email) (BTW: is vmail
defined?)
B. void svc means either "all", "any" or "negotiate" (or is "neg" an svc
on ist own?)

The "all" now leads to the question how to deal with the categories
proposed in draft-brandner-enum-categorical-enumservices-00.txt?

"all" may come in handy with the enum: URI and also others, for a
detailed discussion see section 7.1 of the above mentioned draft.

The other categories may go to the "+addinfo", provided at courtesy of
the ENUM End User. So he may provide additional info, e.g. this is the
preferred NAPTR for talk, msg, etc, but also "home", "office", "mobile",
etc may be convinient.

An open issue is categories like presence, location, certificate, etc.
If we use it together with the URI Scheme as "svc" (e.g. ldap:cert),
they need to be defined in the URI Scheme.

My proposal here is to agree on the principal format as stated above, of
course correctly defined and to include this in RFC2916bis. This
together with a rough consensus could also serve as a basis for the
format used at the trials (we will start with the simple and obvious
URIs and services anyway).

The details could be worked out in a separate draft (e.g. along the
lines of my draft-stastny-enum-services-analysis), also resolving the
above mentioned open issues on the list between Yokohama and Atlanta.
There could also be some first feedback from the trials.

Best regards

Richard STASTNY
OeFEG/Telekom Austria
Box 147, A-1103 Vienna, Austria
tel:+43 664 420 4100
fax:+43 1 797 80 13
mailto:richard.stastny@oefeg.at 

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum