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

["Stastny Richard" <[e-mail]>]

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:[phone]
fax:[phone]
mailto:[e-mail] 

> -----Original Message-----
> From: Richard Shockey [mailto:[e-mail]] 
> Sent: Wednesday, June 26, 2002 9:48 PM
> To: Patrik Fältström; [e-mail]
> 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
> >[e-mail]
> >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: [phone]
> <mailto: [e-mail]> or
> <mailto: [e-mail]>
> <http://www.neustar.biz>
> <http://www.enum.org> 
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> 
> 
> _______________________________________________
> enum mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/enum
> 

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