RE: [Enum] enumservice names

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

Hi all,

I am following this discussion with a blank stare. When it started of, I
thought there was some consensus on generic enumservices like talk, srs,
message (or deliver) etc. The only discussion was about the naming.

Then Patrik stated:
<cit>
No, that is not ok. The enumservice together with the domainname itself MUST
be enough for selecting what record you want. You can not belive the party
looking up a record is to parse and apply the rewrite rules before selecting
the record.

So, this described above is not acceptable. Voicecalls via tel URI and
voicecalls via sip URI need to have different enumservices.
<end cit>

If this is really the case, there is a severe problem in RFC2916bis. Even if
this may be obvious to Patrik, it seems not to be obvious to others, as the
discussion shows.

Further, it is not feasible to create enough enumservices to deal with any
possible combination.

So I fully agree with Michael, that we need at least the following
definition in RFC2916bis:

E2U-enumservice+scheme

where scheme is the URI used 1:1 (e.g. tel or sip). In this case only ONE
enemservice shall be possible.

I am still not sure, if this is sufficient, because the URI may have
additional parameters and if I am not allowed to peek at the URI in advance,
I still may have a problem:

Example:

E2U-message+tel with URI tel:[phone];svc=fax
E2U-message+tel with URI tel:[phone];svc=sms

So we may need something like "E2U-enumservice+scheme?svc"

E.g:
E2U-message+tel?sms

The only other way is to define any possible service as ENUM service:

E.g. Voice, video, fax, mail, sms, mms, ... (a never ending story)

Best regards
Richard


> -----Original Message-----
> From: Patrik Fältström [mailto:[e-mail]] 
> Sent: Thursday, May 23, 2002 8:49 AM
> To: Michael Mealling
> Cc: Michael Mealling; Lawrence Conroy; [e-mail]; 
> [e-mail]; [e-mail]
> Subject: Re: [Enum] enumservice names
> 
> 
> --On 2002-05-23 02.41 -0400 Michael Mealling 
> <[e-mail]> wrote:
> 
> > From your scenario it seems that telvoice and sipvoice both have 
> > different URI schemes. You are using this as a method of allowing 
> > selection of a specific URI during the DDDS Services 
> examination phase 
> > of the algorithm.
> 
> Yes.
> 
> > What I'm after is
> > an enum service that defines 'voice' as allowing multiple 
> URI schemes 
> > (sip, tel, h323, etc). This still leaves you with the inability to 
> > select which URI scheme you want during the algorithm which 
> means you 
> > would need to add that back into the Service field (i.e. 
> "voice+sip", 
> > or something like that).
> 
> Ok.
> 
> > My issue is that I want to specify a higher level of 
> intereoperability 
> > between  what you're calling enumservices but still allow you to 
> > select the  appropriate URI scheme in which to do it. 
> That's why I'm 
> > still suggesting that "E2U+enumservice" isn't sufficient. I 
> personally 
> > would
> > prefer: "E2U-enumservice+scheme" or something like that. 
> That gives us the
> > ability to say something like this:
> > 
> > "E2U-inquire+sip" for a SIP based service where you have to 
> inquire in 
> > order to do anything else. But also "E2U-inquire+ldap" that 
> can do the 
> > same thing but with another URI scheme.
> 
> Let me then take a step back.
> 
> I think one can solve the problem you (and I) are after by 
> registering three different enumservices:
> 
>  - sipvoice
>  - telvoice
>  - voice
> 
> For each one of them it is defined what it does. sipvoice 
> might be "voice using Sip for negotiation, and the outcome 
> will be rtp based voice channel using codec from gips". 
> telvoice can be something else, and voice might be "voice 
> call, random codec, random transpot, random URI scheme".
> 
> The NAPTR records then can have:
> 
>   E2U+sipvoice+voice
>   E2U+telvoice+voice
> 
>       paf
> 
> 
> _______________________________________________
> enum mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/enum
> 

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