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

From: "Stastny Richard" <[email-masked]>
Date: Thu, 27 Jun 2002 11:01:39 +0200

Hi folks,

E2U+function+protocol+...?

So we are back to G.711 again?

I really have a problem with this discussion, especially with SIP and TEL.
On one side I hear from SIP people, that SIP is enough, because it is "srs" and everything can be negotiated anyway, and now I hear that we have to include rtp as well?

Since we have multiple (6) dimensions here, we have IMHO two (three?) options.

The dimensions are:
E2U (which is the only stable item)
category (e.g. talk or msg as proposed in draft-brandner-enum-categorical-enumservices-00)
service  (e.g. voice, video, fax, ..)
protocol or better URI-scheme (e.g. sip, h323, tel, mailto, ...)
subprotocol etc. (e.g. rtp, G711, ...?)
additional info (e.g. home, office, mobile, ...) 

In draft-stastny-enum-services-analysis I proposed to combine service and protocol, but this is not the issue, they also may be separate.

The two options are:
1) Put everything in the enumservice field:
E.g. "E2U+category+service+URIscheme+subprotocol+addinfo", eventually defining default values if there is no entry. This also raises some questions: is mailto the default of msg, or msg the default of mailto ;-)

2) Put only information in the enumservice field which is NOT in the URI, assuming the the regexp(s) are evaluated before the NAPTR is selected (which I would prefer, because I do not really see the problem doing this)
E.g. "E2U+category+addinfo" ... URIscheme;svc=service

For version 1 it should be kept in mind also, that especially the tel URI may allow multiple categories and/or services:
E.g. "E2U+talk+msg+voice+fax+sms
There should also be a clear definition if this is allowed or if separate NAPTRs have to be used in this case.

BTW, the third option would be, to cancel the whole discussion on enumservices and just use only E2U and define the URIs in such a way, that everything may be expressed with the URI. I think, that has to be done anyway, since an URI may also be used without ENUM (e.g. as a link on a webpage or in an email signature, so a client should be able to do the same it is doing with a NAPTR + URIscheme with the URI alone.

Or put it the other way round, the URI in the NAPTR may contain enough information to be selected by the client, if it is only allowed to look at it. If not, we end up duplicating any possible information in the URI-scheme in the enumservice field (as proposed in option one).

Best regards
Richard

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] 

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Wednesday, June 26, 2002 9:48 PM
> To: Patrik Fältström; [email-masked]
> Subject: Re: [Enum] enumservices in new version of 2916bis
> 
> 
> At 08:59 PM 6/26/2002 +0200, Patrik Fältström wrote:
> >I have been discussing how to define enumservice with 
> Michael Mealling 
> >outside of the list, and he and myself have different opinion, so I 
> >really want/need to know what the consensus of the wg is. I 
> ask Richard 
> >to be the wg chair which sort things out.
> 
> O I have to be neutral now right? :-)
> 
> 
> >The format of the service field in the NAPTR is to be:
> >
> >     E2U+enumservice1+enumservice2+...
> 
> Naming clarification here .... I have usually associated ' 
> enumservice' 
> with all data included in the record.
> 
> maybe it would be better to define things as
> 
> E2U+data1+data2+..
> 
> where dataX is defined as elements that could represent Protocol or 
> Function or now add Transport...see below
> 
> 
> >My personal view is that enumservice1 (etc) is to be defined 
> in a way 
> >so the client know exactly what he needs to know before 
> selecting the 
> >record. Or rather, if the client get two NAPTR records, and 
> those are 
> >like this:
> >
> >     E2U+enumservice1
> >     E2U+enumservice2
> >
> >...then the client must know which one of the two "makes 
> sense" to him.
> >
> >Regarding "makes sense" both Michael and I see two different 
> axis along 
> >which one have to do a selection:
> >
> >   - Protocol (basically, URI scheme and/or final protocol to use)
> >   - Function (talk, fax, chat,...)
> >
> >Michael suggested that one should have the following _two_ 
> attributes:
> >
> >    E2U+function+protocol
> 
> There seemed to be some consensus on this ... I certainly 
> thought that 
> things like
> 
> E2U+FAX+SMTP or
> E2U+FAX+tel
> 
> to be reasonable.
> 
> 
> 
> >This is one after defining an enumservice (as a function), 
> one can say 
> >explicitly if the function (such as "talk") is to be on 
> sip/rtp or h323 
> >or whatever.
> >
> >Once again, my view is that IF the client need to know more than 
> >"talk", for example what URI scheme which will be the 
> result, then that 
> >have to be clear in the registration of the enumservice itself.
> >
> >For example, from my point of view, voice call with the help of SIP 
> >might not be enough for a client. One might want to know also what 
> >resulting protocol is to be used after negotiations inside the SIP 
> >protocol. Is then the protocol according to Michaels idea "sip" or 
> >"rtp" or "sip+rtp"?
> 
> Well my views on the E2U+function+SIP issue is well known  
> but you have 
> brought up something new ... SIP can be transported over different 
> protocols  RTP and RTSP  is this where the hint is given?
> 
> I really hope the SIP people will make their views known.
> 
> 
> >Should "talk" define what protocols are to be used, or do 
> one need two 
> >defnitions, the function and the protocol? A registration of a 
> >protocol, should that be the URI scheme or a separate 
> registration for 
> >ENUM?
> 
> 
> I'm assuming that 2916bis  tests for IANA enumservice field 
> registration 
> are what we discussed in the past ... applicability statement 
> .. security 
> considerations, privacy considerations etc.??
> 
> 
> >Or, should we go down the path I suggest? Where the 
> enumservice is to 
> >define whatever is needed?
> >
> >I need advice. What is the consensus of the group?
> >
> >I think we should discuss this in Yokohama, but, I want to write 
> >something in the draft which is no too far away...
> 
> I think its topic A.  :-)
> 
> 
> >     paf
> >
> >
> >_______________________________________________
> >enum mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/enum
> 
> 
>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 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> 
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> 
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 

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

---

From: "Robert H. Walter" <[email-masked]>
Date: Thu, 27 Jun 2002 11:09:36 -0400

> 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"

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]!" .

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...

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.

Regards,

Bob Walter
NetNumber, Inc.

---

From: Richard Shockey <[email-masked]>
Date: Thu, 27 Jun 2002 11:57:16 -0400

>   "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 ...

>    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

>    protocol     : "smtp" | "sip" | "h323" | "mms" | other

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?

>string that starts with a ":".  Several examples are:

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.

>other extensions should be ignored.

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....

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.

---

From: Richard Shockey <[email-masked]>
Date: Thu, 27 Jun 2002 12:49:52 -0400

At 09:15 AM 6/27/2002 -0700, Jim Reid wrote:
> >>>>> "Richard" == Richard Shockey <[email-masked]> writes:
>
>     Richard> There is a reason for this ... I'm sorry if I continue to
>     Richard> harp on the issue but there are privacy considerations
>     Richard> here that I continue to worry about.  Exposing too much
>     Richard> personal preference data _could_ create problems with
>     Richard> various national governments that are properly looking
>     Richard> into this issue and understand that the DNS is global and
>     Richard> globally accessible.
>
>If my limited understanding of EU data protection law is correct,
>there won't be a problem provided the data subject -- ie the owner of
>the phone number/domain name -- knows what's been entered for them in
>the DNS and what that data gets used for. They get to determine how
>little or how much they reveal about that number. And change that as
>they see fit. Since ENUM will have to be opt-in within the EU because
>of data protection/privacy law -- that pretty much means users will
>get full control over their ENUM data anyway. AFAIK the EU has the
>toughest rules on data protection/privacy. Do you know of anywhere
>with even stricter laws?

Well Ok ..... but I suppose what I'm suggesting is that its worth exploring 
the concept of  _choice_ in how much granularity and preference data is 
actually exposed in the DNS.

So to add to Bob Walters statement ... Id like to suggest some principals 
we need to guide ourselves by here.

First order priorities is to get a grip on the real problem statement here 
which is ...What is the proper and reasonable syntax to describe the N 
squared options in the enumservice field?

What are the guiding principals we should use in coming to rough consensus 
...I suggest for a start

A. Simplicity .. the solution for the enumservice field must be as simple 
as practically possible since it will have to be implemented by C/UA and 
adding complexity to the logic a NAPTR parser must use to determine a 
solution may or may not be  "good thing".

What is absolutely required here ...is it the protocol SIP H323 or it is 
the service voice..fax video IM etc.

Of the two which is the most essential?

What is the proper order?

Can one be mandatory and the other optional ?

B. Choice ... What is the minimum data necessary to successfully describe 
an enumservice or conversely the maximum.  Can I have the option of saying 
[E2U+SIP] only but optionally  [E2U+SIP:voice] [ E2U+SIP:video]

yes you could write this [E2U+voice:SIP] [ E2U+voice:SIP]  depending on 
your preference for ordering

any other thoughts?

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 27 Jun 2002 18:34:17 +0200

> 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.

    paf

---

From: Michael Mealling <[email-masked]>
Date: Thu, 27 Jun 2002 12:59:04 -0400

> IANA, and registration is via the IETF RFC publication process.

Yep! That sounds perfect to me!

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

---

From: "Robert H. Walter" <[email-masked]>
Date: Thu, 27 Jun 2002 13:51:23 -0400

Richard,

> Well said .... that should be a guiding rule as we attempt to come to some 

Thanks, I wish I could take credit for the statement!

> optional or are you thinking the service should be mandatory etc?

ENUM provides an excellent mechanism for discovering and locating
communications services using a telephone number.  The key word is
here is services.  Real-time voice, video-conferencing, voice messaging,
electronic mail are all types of communications services that can be
associated with a telephone number.  IMHO, the ability to differentiate
between communications services is core, hence the service should be
mandatory.

The protocol should be optional.  It is possible to infer the protocol
via the URI scheme, though this may be inefficient.  The proposed approach
is much like how a port is optional when used with a host in a http URL
(e.g. http://www.domain.com is equivalent to http://www.domain.com:80).
I suggest we follow this widely understood idiom and place the optional
protocol string after the mandatory service string.

Regards,

Bob
NetNumber, Inc.

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 27 Jun 2002 19:09:12 +0100

>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
-- 
[email-masked]: +44 1794 833666::<my opinions>:

---

From: "Robert H. Walter" <[email-masked]>
Date: Thu, 27 Jun 2002 16:29:32 -0400

> IANA, and registration is via the IETF RFC publication process.

Much better...

Bob Walter
NetNumber, Inc.

---

From: "Robert H. Walter" <[email-masked]>
Date: Thu, 27 Jun 2002 16:27:51 -0400

Hello Mr. Conroy...

> For a start, what is the "vmail" protocol? This looks like a low

The mnemonic "vmail" represents a voice-mail or voice-messaging
service, not a protocol.

> Similarly, "mms" is not a protocol, it's a service

You are correct, it is a service not a protocol.  The updated EBNF
is:

   enum-service : "E2U" ( function )+
   function     : "+" service [ ":" protocol ]
   service      : "voice" | "video" | "email" | "vmail" | other
   protocol     : "smtp" | "sip" | "h323" | other
   other        : <TOKEN>

and if you don't like the "function" production...

   enum-service : "E2U" ( "+" service [ ":" protocol ] )+
   service      : "voice" | "video" | "email" | "vmail" | other
   protocol     : "smtp" | "sip" | "h323" | other
   other        : <TOKEN>

> What does "other extensions MUST be ignored" mean?

Actually I wrote "... other extensions should be ignored".  As with
many protocols, it is often desirable to provide a mechanism for
supporting parameter extensions without breaking the parsing engine.
It is typically recommended that unrecoginized extensions be
successfully parsed, but simply ignored by the application/UA.

If you don't want to allow support for a service/protocol extension
mechnaism the EBNF gets even simpler...

   enum-service : "E2U" ( "+" service [ ":" protocol ] )+
   service      : "voice" | "video" | "email" | "vmail"
   protocol     : "smtp" | "sip" | "h323"

> (Implementation hat on here); The BNF makes parsing the field a pain

Hmmm... That's a different perspective.

Regards,

Bob Walter
NetNumber, Inc.

> From: Lawrence Conroy [mailto:[email-masked]]
> Sent: Thursday, June 27, 2002 2:09 PM
> To: [email-masked]
> Cc: [email-masked]; Michael; Patrik; Richard; Rich
 (Strictly, if you