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

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Wed, 26 Jun 2002 23:08:49 +0100

Hi Folks,
   whilst on the topic of issues for the agenda...
I am glad that someone has been discussing the format for 
enumservices - it seemed quiet on the list.

BTW, Rudi, Richard, and I have three drafts that are germane here:
The "enum scenarios" draft <draft-stastny-enum-scenarios-00.txt>.
The "enumservice analysis" draft <draft-stastny-enum-services-analysis-00.txt>
The "enumservice categories" draft 
<draft-brandner-enum-categorical-enumservices-00.txt>

 From the above it's pretty obvious that I/we agree with the 
protocol/function matrix.
(Note though that for protocol, we have URI-scheme).

Whether or not the URI-scheme is needed within the service field is a 
question that has been raised in the draft (and on the list), and 
will be raised in the meeting, I'm sure.

I believe that it's just a regexp away, so isn't needed in the 
service field - the NAPTRs will have been filtered on function 
(a.k.a. enumservice category) already so there won't be a lot.

(Further comments on "function" in a separate mail :).

Also, some nasty people have pointed out that one could download 
URI-scheme handlers :(
In that situation, it's not easy to tell what URIs are appropriate.

Thus I *think* I'm with Patrik on this one - we don't NEED the 
URI-scheme to be copied into the services field, and it complicates 
parsing with a non-terminal NAPTR (where there IS no URI-scheme).

The idea that we should specify the eventual session/protocol that 
will result from the Service Resolution Service (i.e. SIP) is 
interesting. However, I have a question and a nightmare::

If I fire up a browser window for the 7cent.com site 
<http://www.clockadial.btinternet.co.uk/starter.html>
where in this URL does it specify the embedded sound that plays as a 
result of opening this URL (no - it won't make your ears bleed)?

Seems that there ARE precedents for not indicating the mess one will 
get into when following a URL; plus this is a nightmare to validate 
and synchronize (between DNS and a SIP registrar/proxy).

Re. a possible "shape" for the category definitions:
- see the enumservice category draft - this includes the URI-schemes 
that will "fit" within each category.

I'm not sure this fits exactly with Patrik's "give the client 
everything he needs" - as that would include the URI-scheme that is 
found after regexp replacement.

-------
Regarding Rich's comments:

*  Whoa - In each NAPTR there is (potentially) a list of 
enumservices. That's in both RFC2916 and draft-2916bis.
All right, Rich - I'll buy you a beer if I don't have to re-write all 
of the drafts that have used this term.
If one beer's not enough, I'm sure that Rudi and Richard will as well  :)
-Please- choose another term for the sub-field you called 
enumservice1/enumservice2.

* Hmm....Just when you thought URI-scheme was bad, we bring in protocols.
Should SMTP read mailto?
(As for rtp - is there an rtp: URI-scheme?)

* Transport....SIP has its own negotiation mechanism for selecting 
between UDP, TCP, and TLS.
(As well as the protocol that will be used for the resulting session 
to be initiated)

* (I think it's topic A and B and C :))

Just my 7 cents for this one.

all the best,
   Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 27 Jun 2002 21:20:30 +0200

Hi folks,
I have to agree with Lawrence that the EBNF is badly structured, because it confuses different levels of services.
 
Once again:
We have basically URI-schemes (and I also have to agree with Lawrence, we do not have protocols), and services, which may be defined with the svc parameter (e.g sms or mms are services, not protocols or URIs). To not confuse things to much, we should use other "names" for other things, e.g. categories.
 
Since the URIscheme and the services are somewhere in the NAPTR anyway, they may be left out or be optional.
 
This leaves ónly the categories like talk, msg, info, etc.
 
One word to Robert: talk and voice are not redundant, because voice is a service, like video, but talk (or rtc - real time communication) is a category, which may include voice and video services. And it was selected on purpose to be different.
 
And we should not forget, there is a hierachy, as can be seen in the related drafts:
 
It is well defined which URIschemes are within which categories, and it is also well defined (with the URI definition), which services are possible within an URIscheme (either explicit or implicit)
 
E.g msg > tel > sms
 
So may proposal is still:
"E2U+category" --- URIscheme;svc
"E2U+category+URIscheme+services" --- URIscheme;svc
where there are distinct "names" for category, service and URIscheme to keep things easy for the clients.
 
regards
Richard

	-----Ursprüngliche Nachricht----- 
	Von: Lawrence Conroy [mailto:[email-masked]] 
	Gesendet: Do 27.06.2002 20:09 
	An: [email-masked] 
	Cc: [email-masked]; Michael; Patrik; Stastny Richard; Rich 
	Betreff: Re: [Enum] enumservices in new version of 2916bis

	At 12:59 pm -0400 27/6/02, Michael Mealling wrote:
	>On Thu, Jun 27, 2002 at 06:34:17PM +0200, Patrik Fältström wrote:
	>>  --On 2002-06-27 11.09 -0400 "Robert H. Walter" <[email-masked]>
	>>  wrote:
	>>  > I propose the following EBNF for the ENUM service field:
	>>  >
	>>  >    enum-service : "E2U" ( function )+
	>>  >    function     : "+" service [ ":" protocol ]
	>>  >    service      : "voice" | "video" | "email" | "vmail" | other
	>>  >    protocol     : "smtp" | "sip" | "h323" | "mms" | other
	>>  >    other        : <TOKEN>
	>>  >
	>>  > For those that don't read EBNF, the enum-service field starts with the
	>>  > string "E2U" and is followed by one or more functions.  Each function
	>>  > starts with a "+" and consists of a service string and optional protocol
	>>  > string that starts with a ":".  Several examples are:
	>>  >
	>>  >    "E2U+email"
	>>  >    "E2U+email:smtp"
	>>  >    "E2U+vmail:smtp"
	>>  >    "E2U+email+vmail"
	>>  >    "E2U+voice:h323"
	>>  >    "E2U+voice"
	>>  >
	>>  > The service and protocol strings should be registered with IANA, while
	>>  > other extensions should be ignored.
	>>
	>>  I like this.
	>>
	>>  I would like to rephrase the requirement, and that is that the
	>>  _combination_ of service and protocol string needs to be registered with
	>>  IANA, and registration is via the IETF RFC publication process.
	>
	>Yep! That sounds perfect to me!
	>
	To which I reply:
	  In the words of Mandy Rice-Davis, "Well, he would say that, wouldn't he".
	
	Conversely, I would say No, as described.
	
	*    The naming of names
	
	I am confused (even within some of the posts) on function as opposed to service
	as opposed to category.
	
	I am also confused over protocol as opposed to sub-protocol as
	opposed to URI-scheme.
	
	For a start, what is the "vmail" protocol? This looks like a low
	level service to me.
	
	Similarly, "mms" is not a protocol, it's a service (Strictly, if you
	really want to
	look into the 3GPP documents, there *is* a protocol for a GSM mobile
	sending and
	receiving SMS or MMS, but I sure hope you don't mean this).
	
	Further, when did the service field get re-named? We appear to have
	the enum-service
	field now. Yet more changes to the documentation. Sigh...
	
	--------
	
	*    What's in a service/function/category?
	
	We now have "service" as the only option, on the grounds that
	category is redundant.
	
	Have folks checked with the end users? I'm not sure what the correct
	options should be
	- that's why we're developing trials ->right now<-. Once they're done
	we'll have some
	data on what the customers want. Until that time, I'm not willing to
	restrict this.
	
	Personally, I'd be surprised if end users were interested both in
	category AND in
	low level service (I'd be surprised if the first user interface
	they're provided
	with allows this anyway :). However, I can't dictate in what terms they think.
	
	--------
	*   There's more to this BNF than meets the eye
	
	Now, I *had* assumed that the URI-scheme was what people meant when
	they said protocol.
	Thus, for "smtp" read "mailto".
	
	However, the continued use of the term protocol makes me unsure. If
	you all DO mean
	protocol, then why? We have URI-scheme - either it's copied in the
	service field or
	it's just a regexp away.
	
	Thus, as written, I can't accept the BNF; there are already definitions in RFCs
	for each URI-scheme, and so these tokens SHOULD NOT be copied here.
	If you choose
	to use the protocols specified in the URI-scheme RFCs, then these should also
	be included only by reference.
	
	Following on from this, <TOKEN> is not enough - the existing 2916bis defines
	a mechanism for specifying enumservices in RFCs; this MUST be nailed
	down rather
	than just using the <TOKEN> BNF primitive.
	
	What does "other extensions MUST be ignored" mean?
	
	I also can't accept it as it's badly structured - there's ONE URI
	within a NAPTR.
	Its URI-scheme is associated with ONE protocol. There are a number of
	services for
	which the URI can be used, so the services part is (potentially) a
	multi-valued set.
	If the URI-scheme is to be duplicated within wht was called the services field,
	then it should be a discrete sub-field - there's no earthly point in
	duplicating
	it in more than one enumservice as it will be the same each time.
	
	(Implementation hat on here); The BNF makes parsing the field a pain
	in the parts
	- it's a game of hunt the URI-scheme copy.
	
	all the best,
	    Lawrence

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 27 Jun 2002 13:45:09 -0500

I would like to register some (no doubt predictable) support for Mr.
Shockey's suggestion that protocol come before service in the enumservice
field, and that ideally protocol be mandatory and other fields optional.

As we discussed in Minneapolis, and as has been raised in this thread
already, many of the SIP people feel that forcing a characterization of one
or more services (such as 'voice' or 'rtp' something) in ENUM actually
materially impedes the functioning of a SIP address-of-record URI, and
limits the utility of ENUM for SIP. If a 'service' subfield in the
enumservice field is to be mandatory, we SIP folk would appreciate the
specification of a 'service' identifier that signifies that the protocol in
question has its own capability negotiation - such capability negotiation
is, after all, the whole point of the SDP offer-answer model in SIP. I
personally would like to see an identifier to this effect (with 'negotiate'
something as the token) in the revision of rfc2916bis, so that we could cite
in the SIPPING ENUM draft.

Jon Peterson
NeuStar, inc.

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]]
> Sent: Thursday, June 27, 2002 8:57 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [Enum] enumservices in new version of 2916bis
> 
> 
> At 11:09 AM 6/27/2002 -0400, Robert H. Walter wrote:
> > > E2U+function+protocol+...?
> >
> >So the extreme boundaries of the problem have been identified...
> >
> >minimum:  E2U
> >maximum:  E2U+category+service+URIscheme+subprotocol+addinfo
> >
> >Einstein once said:
> >
> >   "Everything should be made as simple as possible, but not simpler"
> 
> Well said .... that should be a guiding rule as we attempt to 
> come to some 
> rough consensus ...
> 
> 
> 
> >The answer lies somewhere in between... The service field should
> >be used to enable a client application to rapidly select the NAPTR
> >records it is interested in, Consequently...
> >
> >1. The DDDS indicator (E2U) is required because the NAPTR record can
> >    be overloaded for many purposes and NAPTRs must be 
> distinguishable
> >    between applications.
> >
> >2. The FUNCTION is required because a client application 
> needs to be able
> >    to distinguish between NAPTRs that share the same URI 
> scheme or protocol.
> >
> >    For example, assume the following two NAPTRs are 
> associated with a
> >    telephone number:
> >
> >    NAPTR 0 0 "U" "E2U" "!^.*$!mailto:[email-masked]!" .
> >    NAPTR 0 0 "U" "E2U" "!^.*$!mailto:[email-masked]!" .
> >
> >    The first identifies an voice messaging system that 
> supports and SMTP
> >    interface, the second identifies a conventional 
> electronic mail system.
> >    Assume the client application wants to send a recorded 
> voice message
> >    to the voice messaging server.  How does the application 
> differentiate
> >    between the two NAPTRs? The answer is simple, by service...
> >
> >    NAPTR 0 0 "U" "E2U+vmail" "!^.*$!mailto:[email-masked]!" .
> >    NAPTR 0 0 "U" "E2U+email" "!^.*$!mailto:[email-masked]!" .
> 
> yes thank you ... from a Client User Agent perspective the 
> first parse is 
> against ALL enumservice fields for ALL NAPTR records to 
> select which is the 
> most appropriate at that point discard all other NAPTR 
> records.. If 2 or 
> more enumservice fields are identical then use the preference 
> field to 
> sort.... we we are on the same track
> 
> 
> >3. The PROTOCOL should not be required but deserves serious 
> consideration.
> >    Processing of the regular expression dominates the 
> overall processing
> >    time of the ENUM response.  By including the protocol 
> the application
> >    can rapidly select all NAPTR records that are of interest.  The
> >    alternative is to LESS rapidly select interesing NAPTR records.
> >
> >I am having difficulty distinguishing between CATEGORY and 
> SERVICE, i.e.
> >TALK and VOICE, feel redundant.  As for SUBPROTOCOL, this is 
> the purpose
> >of Session Description Protocol and is undoubtably 
> over-kill.  Finally,
> >ADDINFO is an extension mechanism, which violates Einstonian 
> wisdom...
> >
> EXCELLENT start !  transport or port as options seem 
> reasonable  .. ...
> 
> what about reversing the order ... protocol > service > other 
> ..... I'm 
> asking what is the C/UA looking for first?
> 
> 
> But I also personally argue that SIP in and of itself is a 
> service...but 
> I'm not going to beat a dead horse here.
> 
> 
> should or could be ignored ???
> 
> 
> Bob ...this is a most useful contribution to the discussion 
> ... what is 
> your thinking about the protocol field being mandatory and all others 
> optional or are you thinking the service should be mandatory etc?
> 
> There is a reason for this ... I'm sorry if I continue to 
> harp on the issue 
> but there are privacy considerations here that I continue to worry 
> about.  Exposing too much personal preference data _could_ 
> create problems 
> with various national governments that are properly looking 
> into this issue 
> and understand that the DNS is global and globally accessible.
> 
> Without necessarily trying to restrict the clear preference 
> by some to move 
> in this direction ..how can the two requirements be balanced?
> 
> Thanks again....
> 
> 
> 
> >Regards,
> >
> >Bob Walter
> >NetNumber, Inc.
> >
> >
> Richard Shockey, Senior Manager, Strategic Technology Initiatives
> NeuStar Inc.
> 45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
> 1120 Vermont Ave NW Suite 400 Washington DC 20005
> Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
> <mailto: [email-masked]> or
> <mailto: [email-masked]>
> <http://www.neustar.biz>
> <http://www.enum.org>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> 
>

---

From: Richard Shockey <[email-masked]>
Date: Thu, 27 Jun 2002 15:59:36 -0400

At 09:20 PM 6/27/2002 +0200, Stastny Richard wrote:
>Hi folks,
>I have to agree with Lawrence that the EBNF is badly structured, because 
>it confuses different levels of services.
>
>Once again:
>We have basically URI-schemes (and I also have to agree with Lawrence, we 
>do not have protocols), and services, which may be defined with the svc 
>parameter (e.g sms or mms are services, not protocols or URIs). To not 
>confuse things to much, we should use other "names" for other things, e.g. 
>categories.

There seems to be a serious disconnect here between definition of terms...

I dont see a real difference between what you describe as a 'category' and 
what Bob and others describe as a "service"

these are things like voice, video, text, vmail,

now I see some confusion between the concepts of protocol and URIscheme... 
this looks like to me SIP, mailto, ldap, h323, tel  etc

Then is your concept of the services ......

The EBNF concept is the right one its just how is it structured.

>they may be left out or be optional.

No you cant do that since the first order processing of all the NAPTR 
records is on the enumservice field itself and you clearly see some of us 
want the URIscheme (aka protocol) there to be processed, unless you will 
permit the SIP community to call SIP a "category" in and of itself.

so in your scheme it would looks like   E2U+SIP+SIP+N for negotiate.. which 
strikes me as a violation of the simplicity principal here

What I continue to suggest is that there is a body of evidence ( the SIP 
community) that _may not_  want to expose things like categories in the 
enumservice field and I think that can be accomodiated if the protocol/URI 
portion is A. mandatory B first

we seem to differ on which field is more criticial.

>One word to Robert: talk and voice are not redundant, because voice is a 
>service, like video, but talk (or rtc - real time communication) is a 
>category, which may include voice and video services. And it was selected 
>on purpose to be different.
>
>It is well defined which URIschemes are within which categories, and it is 
>also well defined (with the URI definition), which services are possible 
>within an URIscheme (either explicit or implicit)
>
>E.g msg > tel > sms
>

Its just prefer ..for well known reasons that the URIscheme (aka protocol) 
is ordered first so that concepts like catagory and services could be made 
optional.

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 27 Jun 2002 22:32:45 +0200

To the .biz people;-)
 
I see the point of your argument, in direction sip and also in direction privacy. I also talked to a lot of people recently and there are really two groups:
 
Group A does not mind to put as much information in ENUM, and
Group B would like to have only one NAPTR with a "srs", eventually even with a meaningless URI (and this need not only be sip., it may also be h323. or later UCI.), to be able to negotiate and filter.
 
This is BTW also one issue we want to find out with trials, what people prefer, but as I said, there are two groups and we have to serve both. Of course, there is also group C, which tell me that there would never think of giving any information in ENUM, but there are not causing any problems with the enumservices anyway;-)
 
>is ordered first so that concepts like catagory and services could be made

The order of the "tokens" is not so important, if we keep the "names distinct, but so I have no problem to follow your suggestion:
 
"E2U+URIscheme(mandatory)+category(optional)+service(optional)"
 
It is up to the ENUM End User entering the information in ENUM if he gives category and/or service information. The trials may show what the users prefer, but the clients can be designed to work with all options.
 
Jons request could the be fullfilled either with "E2U+sip", where negotiation is the default, or "E2U+sip+srs",
where srs is indicating the "negotiate".
 
regards
Richard

	-----Ursprüngliche Nachricht----- 
	Von: Peterson, Jon [mailto:[email-masked]] 
	Gesendet: Do 27.06.2002 20:45 
	An: Shockey, Richard; [email-masked]; [email-masked] 
	Cc: 
	Betreff: RE: [Enum] enumservices in new version of 2916bis

	
	Jon Peterson
	NeuStar, inc.
	
	> <mailto: [email-masked] <mailto: [email-masked]> >
	> <http://www.neustar.biz>
	> <http://www.enum.org>

---

From: Richard Shockey <[email-masked]>
Date: Thu, 27 Jun 2002 22:42:23 -0400

>To the .biz people;-)

and .us too !

>
>I see the point of your argument, in direction sip and also in direction 
>privacy. I also talked to a lot of people recently and there are really 
>two groups:
>
>Group B would like to have only one NAPTR with a "srs", eventually even 
>with a meaningless URI (and this need not only be sip., it may also be 
>h323. or later UCI.), to be able to negotiate and filter.
>
>This is BTW also one issue we want to find out with trials, what people 
>prefer, but as I said, there are two groups and we have to serve both. Of 
>course, there is also group C, which tell me that there would never think 
>of giving any information in ENUM, but there are not causing any problems 
>with the enumservices anyway;-)
>
>Rich states:
>The order of the "tokens" is not so important, if we keep the "names 
>distinct, but so I have no problem to follow your suggestion:
>

Thank you very much ...this is substantial movement to rough consensus ... 
now I think its reasonable to set the definition of terms and   URI vs 
protocol  catagory vs service  service vs other and revisit the list of 
options and consider a minimal subset suitable for testing.

>
>It is up to the ENUM End User entering the information in ENUM if he gives 
>category and/or service information. The trials may show what the users 
>prefer, but the clients can be designed to work with all options.

I think this is precisely where we want to be ... end user choice is a 
"good thing" tm.

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?

>where srs is indicating the "negotiate".

Bob ..what do you think?

Patrik ...Mike ... thoughts?

This will help with agenda planning immensely....

>
>
>         -----UrsprÃ¼ngliche Nachricht-----

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 28 Jun 2002 10:25:19 +0100

Hi Folks,
   Quick points here:
-  The URI-scheme *is* available "within the NAPTR" - strictly, once 
the regexp-replacement has been done.

-  For historical reasons we have non-terminal NAPTRs - whether or 
not they are used is another question, but they are a valid part of 
ENUM D3S.
It's hard to have a mandatory element (the URI-scheme) within the 
service field when in some NAPTRs there IS no URI-scheme.
I appear to have walked into ETSI/ITU - a conditionally mandatory 
information element, no less :).

all the best,
   Lawrence

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 28 Jun 2002 12:59:08 +0200

Comments inline:

> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Friday, June 28, 2002 4:42 AM
> To: Stastny Richard; Peterson, Jon; [email-masked]; 
> [email-masked]
> Subject: Re: AW: [Enum] enumservices in new version of 2916bis

> 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:[email-masked]

---

From: Richard Shockey <[email-masked]>
Date: Fri, 28 Jun 2002 13:23:29 -0400

>I only have the following requirements for the definition of

Speaking for myself I don't see a problem with this and that could be added 
to the EBNF syntax proposed by Bob

    enum-service : "E2U" ( "+" URI/protocol [ ":" service] )+
    URI/protocol  [mandatory]   : | "tel"  |"mailto" | "H323"  | "sip"  | other
    service   [optional]   : "voice" | "video" | "email" | "im" |  "sms" |other
    info        [optional]      : <TOKEN>

In a private note Mike Mealling remarked to me his definition of terms:

"IMHO, a service is an action that can be expressed via multiple protocols.
A protocol is profile of some set of semantics and an on the wire
protocol that is used to accomplish the task expressed by the service...

A protocol is seperate from a URI scheme because URI identify endpoints
and many protocols can handle multiple URI schemes..."

What I'm trying to resolve here is the definition of terms .........

>meaning in tel:, sip:, etc.

can we just call it "service" ?  its verbose and easily understandable

>"E2U+tel:voice+tel:fax" "...tel:+431...!" or should two NAPTRs be used

Ok now I'm getting confused again... I'm assuming that if you are assuming 
a T.30 capable fax terminal device that is PSTN addressable that 
"E2U+tel:fax" IMHO is sufficient with a tel URL.

>A. Define a default (e.g. mailto defaults to email) (BTW: is vmail

It will be .... I'm very wary of defining things like this at this time 
since I'm assuming the VPIM WG will want to address those issues separately 
in their own drafts.

I've personally briefed both the VPIM and FAX WG on the progress of the 
ENUM WG at several IETF meetings and I'm assuming they will use our 
guidance to construct appropriate ENUM service fields for their respective 
protocols.

>preferred NAPTR for talk, msg, etc, but also "home", "office", "mobile",

I think its best all around if we look at this info field as being 
ambiguous .. your examples make my nervous since it defines a lot more 
information than I think some folks want to disclose in the DNS as you 
correctly point out .  If we start to suggest things like this in 2916bis 
the assumption will be made that its "official" and that will trigger some 
serious misconceptions on the part of the privacy community.

I don't dbout there may be users that want to do this ..its just that we 
will have to be very careful in the language to point out that uses like 
this are purely optional at the discretion of the End User.

>they need to be defined in the URI Scheme.

Sure ..but the ENUM WG itself may not be the appropriate WG to create those 
drafts. I think we need to have a bit more outreach to other communities of 
interest here.

>URIs and services anyway).

Yes and I think we know what those are the question is what is the document 
instrument we use to define those initial trial fields.  We have a process 
issue to deal with ... first we need to see 2916bis and the IANA 
registration procedures associated with it.

>There could also be some first feedback from the trials.

I think this is a very very good idea. A specific ID on a limited series of 
enumservice constructs for the purposes of global trials. ..we can create a 
simple matrix with verbose explanations along the lines of your 
"Catagoricial enumservices" document and Bob Walters syntax.

enum-service : "E2U" ( "+" URI/protocol [ ":" service] )+
    URI/protocol  [mandatory]   : | "tel"  |"mailto" | "H323"  | "sip"  | other
    service   [optional]   : "voice" | "video" | "email" | "im" |  "sms" |other
    info        [optional]      : <TOKEN>

The purpose of the document would be to explain the current state of ENUM 
development perhaps highlight the agreement made with SG2 etc and note that 
several nation-states have committed to developing trials etc. This new ID 
is offered to "facilitate" these trials under way blah blah etc.

Now in addition, putting my WG chair hat on, I think it would be a good 
idea for both you , Rudolf, and Larry to collaborate with Bob Walter and 
Doug Ranalli on this.

Bob and Doug have put a lot of thought into this and their original draft 
suggested many of the concepts here so it only seems reasonable to combine 
efforts.

You all could have something ready shortly after Yokohama and put it on 
track to "Experimental" in conjunction with 2916bis itself.

Is this a plan?

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 28 Jun 2002 21:52:02 +0200

Comments inline:

	-----Ursprüngliche Nachricht----- 
	Von: Robert H. Walter [mailto:[email-masked]] 
	Gesendet: Fr 28.06.2002 21:05 
	An: Michael Mealling 
	Cc: [email-masked] 
	Betreff: RE: [Enum] enumservices in new version of 2916bis

	> Umm.... I'm not sure in what context you're using the string 'mailto'
	> here but just in case:
	>
	> mailto is a URI scheme defined in RFC 2368 which only mentioned SMTP _once_
	> in a caveat about making sure the SMTP 'From' address is set correctly in the
	> message.  RFC 2368 does not define any transport system to be used. Period.
	> 'mailto:' identifies RFC 822 addresses and messages. How you get to an
	> address or send a message is not defined.
	>
	> Everyone: Please be _very_ careful how you use 'mailto:'. It _does NOT_
	> mean what you think it means simply from your usage on a web page. Please
	> read RFC 2368 and RFC 2396 if this is confusing....
	
	Agreed, the uri-scheme and protocol are different things and should not
	be used interchangeably...
	
	Bob Walter
	NetNumber, Inc.
	
	Richard Stastny replies: Ok. I have learned a lot today. For years there were given examples on how to use ENUM, especially mailto+E2U and E2U+mailto. Every dummy out there, including myself and ITU-T SG2 thought you can send an e-mail with this.

	Today I have heard, we all are stupid, mailto does not mean what everbody think it means and you need to add a protocol information to get this working. As a dummy MS operating system user you may click on mailto: link, MS Outlook starts, you write an e-mail and it is also received by the recipient, but this is just pure luck.

	I have also learned today, that a couple of very sophisticated and wise guys have defined an RFC2916 and even a 2919bis, which has been discussed for 2 years in all necessary and unnecessary standard bodies, but which cannot implemented at least in is simplest version, because at the moment not even ONE bl... ENUM service is defined.

	I have also learned (not only today, but since some months), that what is proposed does not work, why it does not work, Nah, you cannot do this and you cannot do that, it should be done in another way, etc.

	Can anybody who defined ENUM please explain to me what I shall use in a trial.

	What I want is at least a simple basic workable solution, for mail, tel, fax, sms and http: and I want this after Yokohama.

	Since I am on vacation for 2 weeks in Spain (I really need this now), I promise not to interfere (to much) any more, maybe this helps.

	So you have two weeks to get this sorted out.

	best regards 

	Richard

---

From: Brandner Rudolf <[email-masked]>
Date: Sat, 29 Jun 2002 04:18:45 +0200

Hi all,

I'd like to come back to the very pressing issue: enumservice field structure. I'm with Richard Stastny on this: we really need to sort this out. Thus I'd like to ask whether we do have a (rough) consensus on
     servicefield = "E2U" ("-" <uri-scheme>) [*("+" <enumservice/category>)] ["*" <addinfo>]
or not.

[note: I think I've got the addinfo right now. If not, please let me know.]

And yes, I agree that we will have to be very clear about addinfo being optional.

Now on to the thread of protocols and APIs:

> Von: Michael Mealling [mailto:[email-masked]]
> Gesendet: Freitag, 28. Juni 2002 23:01
> An: Lawrence Conroy
> Cc: [email-masked]; Michael Mealling; [email-masked]
> On Fri, Jun 28, 2002 at 09:21:47PM +0100, Lawrence Conroy wrote:
> > At 3:05 pm -0400 28/6/02, Robert H. Walter wrote:
> > >> mailto is a URI scheme defined in RFC 2368 which only 
> mentioned SMTP 
> > >> _once_
> > >> message.  RFC 2368 does not define any transport system 
> to be used. 
> > >> Period.
> >   Amen to that.
> > (In answer to Michael's question regarding implementing URL 
> handlers 
> > ...me too !)
> > I guess that the problem is that I'd rather like to have something 
> > implemented by the end of the summer that doesn't just have 
> SRS as the 
> > service and sip: as the URL.
> 
> Can you describe that something?
> 

Hmmm, I'm not sure, whether this discussion is helpful on our main issue: enumservice field structure.

> > I believe that I and everyone else here understands the 
> difference between 
> > the architecture and the implementation - at least the old 
> fogeys around here
> > [and I still have hopes for Xanadu].
> > 
> > We seem to be getting to the nub here - how an end user gets to the 
> > resource with which they want to communicate is not 
> specified in the URL.
> 
> Correct. It just specifies what that resource is. We still need a way
> to specify what method is used to talk to it.
> 

Sorry, but I think no, we don't as far as protocols are concerned.

Today, I can send an SMS to an e-mail address. My mobile phone might not get a very popular e-mail client any time soon, but it might get ENUM-enabled. If my mobile phone gets a mailto: it might fire up the SMS UI to enter the message, prepends the e-mail address and sends it to a gateway of choice, which forwards it as an e-mail to the reciepient.

If you are going to specify protocols here you are opening a whole new can of worms. The only thing I need to know is how the receiving end can be reached. How the communication is started with is a complete different story. For instance, if you are specifying SMTP as the protocol of choice, I won't be able to send a message to an e-mail address from my mobile phone any more until it get's STMP or at least an e-mail client.

> > At what point did instructing the querying end user/client exactly 
> > how to connect to their intended correspondent become a 
> core part of ENUM?
> 
> When it became clear that simply identifying the endpoint 
> wasn't sufficient
> for knowing how to interact with that resource since the 
> protocol you use
> to do has a large amount of impact on what services you can 
> express for
> that endpoint.
> 

Define a default behaviour of the client for a default protocol. However, the protocol used at the recieving side does not necessarily be the same as on the sender side. ENUM is about how a recieving side can be contacted.

> > In answer to the "what will it break"? question, my answer is 
> > "nothing, if ignored".
> 
> Depending on your implementation schedule and feature list that might
> be sufficient for now. I assume you'll be coming out with updates?
> 

You're not? (sorry, couldn't resist ;^)

> > Those fine OS manufacturers have provided an easy API to 
> fire up a URL 
> > handler for "mailto:". 
> 
> Sure. But on a very popular OS platform all that does is bring up the
> Outlook with a few header fields filled in. You can't really 
> use that as
> a voice mail interface. I.e. if the _service_ you want is voice mail
> then bringing up Outlook is probably _not_ what you wanted to happen,
> regardless of whether or not there's a built in handler for 
> the 'mailto'
> scheme on that platform.
> 

As for that very popular OS platform: is it ENUM enabled?

If you are looking for a vmail service and start an application which is not capable of dealing with voice.... er... what's wrong here?

Maybe there need to be some application to glue together. In this particular case, looking for a vmail it might be of help first start some voice recording software and then send it using that very popular mailer until that very popular software company gets its very popular mailer ENUM-enabled.

> > I also have an easy API to fire up a URL handler for "tel:"
> > (strictly, this one's via TAPI), and for "http:", and 
> (shortly) for "sip:".
> 
> Sure. But do those APIs know what it is you're trying to _do_ with
> those endpoints? 
> 

Maybe I am off some miles here, but I think that the APIs do not need to know. An ENUM client software should know about the features ENUM enables and start the appropriate pieces of software already being there.

> > The querying end user (or the defaults of a certain Redmond company)
> > configure what protocols and programs these URLs trigger.
> > No great pain, and we'll get something out soon.
> 
> The Asynchronous Pluggable Protocol (bad terminology!) APIs found in 
> urlmon and friends are great. But they're only half of the 
> story. Before 
> your call ever goes the actual scheme handler it goes through a 
> security and caching policy filter that can determine whether or not
> your 'ftp:' URL request actually gets sent to your proxy via the HTTP
> protocol. If you're client has this specified then your 'sip:'
> url is going to get sent to the the 'http:' handler as a 
> proxy proccess.
> So it isn't as clear cut as "Microsoft just gives me nifty 
> APIs and that's
> all I need". There are nasy side effects when you use it if you aren't
> clear why your using it.
> 

Is Microsoft's software ENUM enabled already? If not, maybe they just up the ante in changing APIs and their semantics a little bit.......

Sorry for being somehow sarcastic here. I see that there are problems with actual APIs. However, I do not see any immediate link to the enumservice field. The trials will show how easy or complicated it is to implement useful ENUM clients. APIs might change after getting some experice.

> > If ENUM implementors are expected to find a way to override these 
> > configurations and control the programs to run whatever 
> protocol the 
> > registrant specifies, we might have the trials sometime before the 
> > end of 2003.
> 
> I'm not so sure. I think we're actually converging very quickly. 
> We've only been having this particular discussion for 2 days. A couple
> of more and I think we'll have it...
> 
> > My gripe is that, until this week's wheeze, there was none 
> of this - it's 
> > all new. New and "by September 2002" don't mix.
> 
> Well, its a discussion that's been going on in fits and starts since
> Minneapolis. IMHO, we'll get there soon. I'll do my best to get this
> settled by Yokohama...
> 

I'm with you here.

.... and if not, I suggest that we discuss this in Yokohama over a beer or two.....

Rudi
------[snipp]-----