Subject: RE: [Enum] enumservice names

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

Wasn't the consensus from IETF 53 that in fact the enumservice name SHOULD be distinct from the protocol used in the URI scheme? The idea being that if the enumservice and protocol are always the same, there isn't much point in having the enumservice to begin with.

The trick seems to be just what deciding what level of granularity or abstraction is most appropriate for what makes up an enumservice. There have been attempts do divide this up by media (voice/im/video), by signaling protocol (sip, etc already captured in the URI), by capability profile (vpim/fax classes/transcoding), and by intent (complete a class of call or communication, find the right place to deposit a message, or find a service resolution service to authenticate you and expose a current snapshot set of options based on rules and presence data).

My own bias is that I would like most to be able to do with the enumservice is distinguish between a URI that can be used to complete a call/transaction/session versus a URI that can iterate one step further into service resolution by giving me a list of options that I can select from or present back to the end user or application to select from. If that distinction can be made just by looking at the URI itself, then that's cool. But using SIP as an example, I have no good way (yet) of doing this, except by separating the 'srs' enumservice from the 'sip' or 'voice' or whatever the alternative is that we choose.

I suspect there are similar arguments to be made for other enumservice "schemas" and am surprised we have not had more debate on this topic since the meeting. I do think there is general agreement that whatever the schema, the number of enumservices should be kept as small as possible so that enum does not become a repository for detailed capability information.

On an unrelated topic, am I remembering right that an update to the new bis with a finalized "template" was going to be forthcoming so we could update our enumservice drafts? Did I just miss this or is this still in the queue?

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

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

> -----Original Message-----
> From: Lawrence Conroy [mailto:[email-masked]]
> Sent: Wednesday, May 22, 2002 2:42 AM
> To: [email-masked]
> Cc: [email-masked]; Rudi
> Subject: [Enum] enumservice names
> 
> 
> Hi Folks,
>    This is a minor point, but from discussions we've had
> I wonder if the name of each enumservice should be DIFFERENT
> from the URI schemes they may use.
> 
> For example, writing about the 'tel' enumservice is
> confusing, as one also needs to write about the "tel:"
> URI scheme (So it's not just confusing to read :).
> 
> Likewise, does one talk about the 'sip' enumservice or
> the "sip:" URI scheme?
> 
> Thus I suggest that we re-name the enumservices.
> 
> BTW, as 'sip' is, AFAICT, a "Service Resolution Service",
> why not call the enumservice just that (well, 'srs', anyway)?
> 
> Comments?
> 
> all the best,
>     Lawrence
> -- 
> [email-masked]: +44 1794 833666::<my opinions>:
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
>

---

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

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

> Wasn't the consensus from IETF 53 that in fact the enumservice name
> SHOULD be distinct from the protocol used in the URI scheme?

The consensus, which I tried to explain in version 00 of 2916bis is that
the URI scheme is one thing, and enumservice another. I.e. two different
things.

I.e. two different namespaces for them.

That means that one enumservice can have the same name (consist of the same
characters) as a URI scheme, without having anything to do with that scheme.

So, my suggestion is that when one enumservice is specified that the name
of that service is chosen wisely.

   paf

---

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

>of that service is chosen wisely.

Hi folks,
   OK, to summarise -
I am easily confused, and asked if we could ensure that the name used 
for an enumservice
is always different from the name used for the URI schemes.

Andrew and Michael think that ensuring that the string value used for 
an enumserevice
should be different from the string value used for any of the URI 
schemes that can be used
with that enumservice.

Patrik highlights that (i) this is not NEEDED as they are separate 
namespaces and
so do not clash, but (ii) the service name should be chosen wisely.

Michael agrees that the 'sip' enumservice could be re-named 'srs'.

So...
Jon - is it OK with you to change the name of the 'sip' enumservice to 'srs'?

I guess the ball is in our court - we will rename the 'tel' enumservice.

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?

all the best,
   Lawrence

---

From: Richard Shockey <[email-masked]>
Date: Wed, 22 May 2002 12:26:39 -0400

A
>Hi folks,
>   OK, to summarise -
>I am easily confused, and asked if we could ensure that the name used for 
>an enumservice
>Andrew and Michael think that ensuring that the string value used for an 
>enumserevice
>should be different from the string value used for any of the URI schemes 
>that can be used
>with that enumservice.
>

yea right ... :-)

>I have a couple of ideas for names that might be appropriate - 'talk' or 
>'phone' spring

It could be foofoo for all it matters so long as  the applicability 
statement in requesting the appropriate enumservice registration defines 1. 
the reason for the registration 2. defines the service 3. the URI scheme 4. 
anticipated context/behavior that the C/UA needs to understand.

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: Wed, 22 May 2002 19:41:50 +0200

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

> namespaces and so do not clash, but (ii) the service name should be
> chosen wisely.

Note, I am the editor of the document, and only explain what is in the
document now. Please suggest changes if you want me to have some wording
which makes this more clear.

As non-editor, I think your suggestion on finding "non-confusing-names"
(especially as I made the "mistake" of having a 1:1 mapping between scheme
and ENUM service in RFC 2916) which means not use the same name as the
scheme is a good idea.

   paf

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 22 May 2002 19:39:40 +0200

--On 2002-05-22 12.26 -0400 Richard Shockey <[email-masked]>
wrote:

> statement in requesting the appropriate enumservice registration defines
> 1. the reason for the registration 2. defines the service 3. the URI
> scheme 4. anticipated context/behavior that the C/UA needs to understand.

5. Approptiate security considerations section

   paf