Subject: RE: [Enum] enumservice names

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 22 May 2002 14:33:08 -0600

Lawrence wrote:

> I have a couple of ideas for names that might be appropriate - 'talk' 
> or 'phone' spring to mind, as the erstwhile 'tel' enumservice is 
> intended for use in interactive telephony calls; either seems 
> appropriate.
> 
> Do any folks have a preference?

I actually like 'talk' a lot because underneath it could resolve to a lot of different protocols but the intention of the enum query remains relatively clear nonetheless. 

This means that the srs enumservice could be called something like 'inquire' to express the idea that one is asking about what services are currently available to the originator of the inquiry, given the identity verification, presence knowledge, and application of policy rules associated with the service resolution service in question.

Faxes and voicemail could fall under the 'deliver' service (really hate that name, but 'message' is overloaded and I don't want to confuse with session-oriented IM) or something similar where the operative function is the deposit of a page or snippet of media.

IM and other session-oriented text could be 'chat' though that might be confusing with talk (would need something that is text-centric without being a page-delivery service)

Video could be 'view', but page mode vs. stream mode wouldn't be clear enough ('see' has the same problem) And neither talks to the associated audio much.

Worlkflow and whiteboard applications or other rich, complex interactions could be 'share' (though that might overlap with something else if we're not careful)

Still, I think there may be a usable pattern in here somewhere...

--Andy Zmolek 
    Technology & Standards Engineer 
      CTO Standards 
        Avaya Inc. 

            [email-masked] 
              +1 720 444 4001 
                sip:[email-masked]

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

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 22 May 2002 23:08:49 +0200

--On 2002-05-22 14.33 -0600 "Zmolek, Andrew (Andrew)" <[email-masked]>
wrote:

> I actually like 'talk' a lot because underneath it could resolve to a lot
> of different protocols but the intention of the enum query remains
> relatively clear nonetheless. 

Note that the enumservice must specify a function + a URI scheme. I.e.
given that you know what URI schemes you can take care of, and what
"function" you want to handle, you should be able to (as application) to
know what enumservices you can handle and not.

So, "talk" with the help of a tel: URI scheme should most certainly be a
different enumservicefield than "talk" with the help of a sip: URI scheme.

   paf

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 22 May 2002 23:38:22 +0100

>different enumservicefield than "talk" with the help of a sip: URI scheme.

Hi Patrik, Andrew, folks,
   Couple of points here.
First, please let's not call any enumservice by the "Inquire" tag, or you'll
make half of the English speaking population unhappy (Enquire, maybe :).

Second - a set of NAPTRs all with 'talk' as their enumservice tag, may have
different schemes in their contained URIs. 'tel:' makes sense, bus so does
'sip:' (or even "h323:", if the Typhon people come through :).
The Application knows it wants an interactive (telephony) conversation, and
it also knows what drivers or associated software is available locally. If
it doesn't have a SIP UAS then it has to discard a NAPTR with a sip: URI.
I hope that is what we all expect.

I am a bit confused over the different "enumservicefield" comment, however.
Does this imply that the servicefield definition is going to change again :(
I sure hope not! The current definition seems to work OK, IMHO.

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

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 23 May 2002 07:57:23 +0200

--On 2002-05-22 23.38 +0100 Lawrence Conroy <[email-masked]> wrote:

> Second - a set of NAPTRs all with 'talk' as their enumservice tag, may
> have different schemes in their contained URIs. 'tel:' makes sense, bus
> so does 'sip:' (or even "h323:", if the Typhon people come through :).

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.

Secondly:

> First, please let's not call any enumservice by the "Inquire" tag, or
> you'll make half of the English speaking population unhappy (Enquire,
> maybe :).

I don't understand this sentence.

   paf

---

From: Michael Mealling <[email-masked]>
Date: Thu, 23 May 2002 02:09:53 -0400

> voicecalls via sip URI need to have different enumservices.

So how do you specify the case where an application can handle
both a sip: and tel: URI for a voice call? That was one of the original
reasons for creating the service field: two or more protocols/URI schemes
that were useable for the same type of service. Hence the reason
I had the enumservice and the protocol in the Service field.

> I don't understand this sentence.

British vs American spelling....

-MM

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

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 23 May 2002 08:15:32 +0200

> I had the enumservice and the protocol in the Service field.

If voice with tel is called telvoice and voice with sip is called sipvoice,
then the application pick the two NAPTR which have those enumservices. I.e.
the records have the same owner, so you still get back all of them when you
issue the DNS query.

I.e. you query for NAPTR records for an E.164. Then out of that set of
records, you select records based on the enumservice field. Then, as third
step you start applying the rewrite rules.

You are the one which have tought me this! :-)

  paf

---

From: Michael Mealling <[email-masked]>
Date: Thu, 23 May 2002 02:22:38 -0400

> You are the one which have tought me this! :-)

Yes. But I'm after something different. I want to be able to define
telvoice and sipvoice to be the same class of service (voice) but
just handled by different transport services so that devices can handle
both transports if needed. In your scenario above the two services
are disjoint and appear to be non-interoperable.

-MM

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 23 May 2002 08:28:35 +0200

--On 2002-05-23 02.22 -0400 Michael Mealling <[email-masked]> wrote:

> I want to be able to define

Yes, they are disjoint, but different URI schemes (only).

They might not use different transport services for the voice call. It is
only two different URI schemes which are used to set up the call.

   paf

---

From: Michael Mealling <[email-masked]>
Date: Thu, 23 May 2002 02:41:11 -0400

> only two different URI schemes which are used to set up the call.

Ok, sorry. I wasn't precise enough:

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.
This is fine if that's what you are after. 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).

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.

-MM

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 23 May 2002 08:48:32 +0200

> a specific URI during the DDDS Services examination phase of the

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 23 May 2002 16:07:09 +0100

> IM and other session-oriented text could be 'chat' though that might be confusing with talk (would need something that is text-centric without being a page-delivery service)

"texttalk" ? This could then also cover the things that deaf people use
whose name I've forgotten, with a "tel:" URI.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <[email-masked]>  | Fax:  +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            | NOTE: fax number change

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 23 May 2002 16:48:31 +0100

At 11:06 am -0400 23/5/02, Richard Shockey wrote:
>A
>AND .. I might add .. here we go again going into granularity in 
>enumservice definitions. This is a very very slippery slope that I 
>thought we had over come.
>
>I dont like this and frankly I never will, except in those unique 
>cases such as SMTP where due to the store and forward nature of the 
>protocol it is impossible to determine end point capability in 
>advance of session creation.  This covers the email vs voice mail vs 
>fax mail issue.
>
>I think there is common agreement that upon query first process the 
>NAPTR records based on the enumservice field ... then and only then 
>once the C/UA or whatever finds what it wants, if there are more 
>than one enumservice field matching the requirements then use 
>preference to sort them out then apply the rewrite rules.
>
>I think there is still going to be a huge problem convincing the SIP 
>community that there needs to be multiple definitions of SIP based 
>on the capabilities of the endpoint. Negotiation or discovery of 
>capability should occur during the INVITE and not potentially 
>exposed in the global DNS.
>
Hi Rich, folks,
   OK, so the last meeting was not successful in clearing out
why we have URI *and* enumservice *and* D3S application, or we
wouldn't be here.

The  steps as listed above - [implied D3S application process],
winnow NAPTR RRset returned based on enumservice sub-field
   (and preference for tie breaking),
Then process re-write.

I don't think anyone disagrees with these steps.

But...
In addition to the above items, some URIs have parameters
or qualifiers - e.g. tel: has phone-context to act as a filter
on the origination context within which it is valid.

So there may be some post filtering AFTER the re-write has
constructed a URI (or URIs).

Now, if the enumservice sub-field is merely reflecting the URI
scheme "out" into the NAPTR service field, then life is easy.
I don't need to write an enumservice registration as some kind
folk have already registered the URIs with which I'm going to
populate my DNS. I can just put in references to the URI scheme
as defined in some RFC - in fact, I don't even need to put the
references in any document - it's just the scheme tag copied
from the URI. It doesn't even get obsolete with new URI schemes.
Works for me, even if it does make the NAPTR larger.

However...If the enumservice sub-field is supposed to be used
for something else, then what?

all the best,
   Lawrence

---

From: Richard Shockey <[email-masked]>
Date: Thu, 23 May 2002 11:06:05 -0400

A

AND .. I might add .. here we go again going into granularity in 
enumservice definitions. This is a very very slippery slope that I thought 
we had over come.

I dont like this and frankly I never will, except in those unique cases 
such as SMTP where due to the store and forward nature of the protocol it 
is impossible to determine end point capability in advance of session 
creation.  This covers the email vs voice mail vs fax mail issue.

I think there is common agreement that upon query first process the NAPTR 
records based on the enumservice field ... then and only then once the C/UA 
or whatever finds what it wants, if there are more than one enumservice 
field matching the requirements then use preference to sort them out then 
apply the rewrite rules.

I think there is still going to be a huge problem convincing the SIP 
community that there needs to be multiple definitions of SIP based on the 
capabilities of the endpoint. Negotiation or discovery of capability should 
occur during the INVITE and not potentially exposed in the global DNS.

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: Patrik Fältström <[email-masked]>
Date: Thu, 23 May 2002 22:11:22 +0200

> for something else, then what?

Up to the one registering an enumservice being different from the URI
scheme.

I.e. 2916bis doesn't prohibit people from writing documents about
enumservicefields which are "foo", "bar" and "baz". In 2916, it could only
be the URI scheme, and only one such scheme per NAPTR.

I heard that that was not enough, so 2916bis is more flexible.

  paf