Subject: [Enum] enumservices - the story so far

From: Lawrence Conroy <[email-masked]>
Date: Fri, 24 May 2002 01:22:52 +0100

Hi folks,
   to check that I have understood where we are right now, I've been 
trying to summarize this thread.
As I read it...

 From Patrik's message (of Wednesday at 2110Z) he believes that the 
service field should include the URI scheme plus the enumservice 
(such, I guess, as the ones above), in addition to the E2U DDDS 
application tag.

This is reinforced by his message (of Thursday at 0600Z).

I'm not quite sure what Patrik's message (of Thursday at 0648Z) is 
suggesting - I think that the <enumservice> is sipvoice or telvoice, 
and this is followed by another tag, voice, in both cases.

In his message (of Thursday at 0641Z) Michael suggests 
<D3Stag>-<enumservice>+<URIscheme>

Richard agrees with Michael in his message (of Thursday at 0743Z) but 
points out that there may also be service differentiators (e.g. 
svc=fax, svc=sms, ...).

Rich is concerned (in message of Thursday at 1506Z) about different 
NAPTRs based on the capability of endpoint.

This is reinforced in his message (of Thursday at 1911Z) in which he 
restates his concern that too much data may be exposed in DNS 
indicating personal communications capabilities and preferences

Clive (message of Thursday at 1510Z) suggests that carrying all of 
this data in the services field is a duplication and that it is far 
better to parse the NAPTR.

Richard reminds us (in his message of Thursday at 1521Z) that it 
should be simple for trials, and that need for regexp in first phase 
is not clear

I (in my message of Thursday at 1548Z) reiterated my concern over the 
real use for the enumservice sub-field, and agreed that there would 
be a post regexp filtering step.

Andrew suggests (in message on Thursday at 1705Z) that filtering may 
even include URI path parsing for capability hints, and that the 
enumservice sub-field should NOT be representative of the URI scheme.

Patrik responded to my question on use of enumservice sub-field (in 
first message on Thursday at 2025Z) by pointing out that this is up 
to the author of the enumservice registration - this flexibility is 
one change from 2916

Patrik then sent another message (also on Thursday at 2025Z) that I 
don't understand but discusses ENUM chains.

In his message (on Thursday at 2039Z) Andrew agrees, but is concerned 
that we need to crystallise the enumservice schemas

Andrew (in message on Thursday at 2043Z) raises concerns over the 
enumservice RFC process, whether or not there should be an unlimited 
number of such RFCs, and how one ensures that the schema is valid for 
a NAPTR

Patrik responds (in message on Thursday at 2049Z) that these must be 
RFCs and that there is a defined review process for RFCs in the IETF, 
and that the idea of 10-12 entries in a strawman schema set is a good 
one

Rich (in message on Thursday at 2111Z) also highlights the 
enumservice registration procedure in 2916bis, and suggests 5-6 
entries is better for the strawman schemas

Have I got the salient points so far? (If so we can get on to the 
schema set proposals).

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: Fri, 24 May 2002 07:48:50 +0200

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

> service field should include the URI scheme plus the enumservice (such, I
> guess, as the ones above), in addition to the E2U DDDS application tag.

No, that was not what I wrote.

I wrote:
> 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.

You continue:
> real use for the enumservice sub-field, and agreed that there would be a
> post regexp filtering step.

Of course it will be, at least in the cases when you have more than one URI
in the list of possibilities. You have to choose one.

> Patrik responded to my question on use of enumservice sub-field (in first
> message on Thursday at 2025Z) by pointing out that this is up to the
> author of the enumservice registration - this flexibility is one change
> from 2916

Yes.

> Patrik then sent another message (also on Thursday at 2025Z) that I don't
> understand but discusses ENUM chains.

I don't understand where you get the timestamps from, but guess you talk
about this message sent on 2014Z:
> It depends. In some cases you need to do a lookup of NAPTR RRs several
> times and apply the rewrite rule to get the full URI, so, I would like to
> say that an enumservicefield is to give hints which are enough so a client
> resolving the E2U NAPTR chains doesn't have to do too much unnessecary
> work.

You might get back an NAPTR which is non terminal when looking it up. The
enumservice then should give you enough information so you know whether you
should chase the chain of NAPTR.

> Patrik responds (in message on Thursday at 2049Z) that these must be RFCs
> and that there is a defined review process for RFCs in the IETF, and that
> the idea of 10-12 entries in a strawman schema set is a good one
> 
> Rich (in message on Thursday at 2111Z) also highlights the enumservice
> registration procedure in 2916bis, and suggests 5-6 entries is better for
> the strawman schemas
> 
> Have I got the salient points so far? (If so we can get on to the schema
> set proposals).

Yes, modulo that I actually have posted a proposal.

  paf

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 24 May 2002 10:15:51 +0100

>>  different enumservicefield than "talk" with the help of a sip: URI scheme.
Apologies for this - my misunderstanding. Function != enumservice always.

>about this message sent on 2014Z:

Sorry - must have missed a Date: header in the email. Yes. exactly.

>should chase the chain of NAPTR.

Many thanks for this. The light dawns.
You mean we must have the services field even for non-terminals, and that's
all the D3S-application has to make its selection.

>Yes, modulo that I actually have posted a proposal.

Understood. Now for these.

>   paf

Apologies for the misrepresentation. Forwards.

all the best,
    Lawrence

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 24 May 2002 11:21:56 +0200

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

> You mean we must have the services field even for non-terminals, and
> that's all the D3S-application has to make its selection.

Exactly!

Michael of course know the details better than myself, but this is where my
mind is.

Note though to everyone: This is more a NAPTR education issue (how NAPTR
work) than ENUM, but very very relevant and important because of
implications.

> Apologies for the misrepresentation. Forwards.

No problem.

As wg chair, and as document editor I really appreciate the extremely
useful discussion, which includes your summaries of course.

Now when SG2 meeting in ITU-T I will create a new version of the I-D of
2916bis, so I am very interested in conclusions on what should be written
in 2916bis.

  paf

---

From: Richard Shockey <[email-masked]>
Date: Fri, 24 May 2002 12:44:31 -0400

>suggesting - I think that the <enumservice> is sipvoice or telvoice, and 
>this is followed by another tag, voice, in both cases.

Broken Record Speaking    IMHO  E2U+SIP is the complete enum service field 
for sip ... now tel could be   E2U+tel+SMS  or E2U+tel+voice or 
E2U+tel+TDD  this is another example of the case wher exposing endpoint 
data that cannot be derived in advance or during the creation of a session 
such as in SIP.  IMHO such enumservice fields might IMHO pass muster.

>restates his concern that too much data may be exposed in DNS indicating 
>personal communications capabilities and preferences

Yes  you can go down the path of service granularity but I hope you'll 
enjoy spending a great deal of time in London, Geneva, Brussels or 
Washington DC in a suit and tie explaining the privacy implications of this 
to regulators.

>Clive (message of Thursday at 1510Z) suggests that carrying all of this 
>data in the services field is a duplication and that it is far better to 
>parse the NAPTR.

I dont agree ..

once the set of records is returned it makes more sense to sort on the 
services field first ..even if similar data is contained in the URI within 
in the regexp

>Richard reminds us (in his message of Thursday at 1521Z) that it should be 
>simple for trials, and that need for regexp in first phase is not clear
>
>I (in my message of Thursday at 1548Z) reiterated my concern over the real 
>use for the enumservice sub-field, and agreed that there would be a post 
>regexp filtering step.

in the case where you might have two identical service fields

>In his message (on Thursday at 2039Z) Andrew agrees, but is concerned that 
>we need to crystallise the enumservice schemas

again a limited subset ...  I think SIP, hopefully we'll see some drafts on 
H.323 before Yokahama  tel and SMTP are a pretty reasonable starting 
point...after that I trust our VPIM colleagues will chime in.

>number of such RFCs, and how one ensures that the schema is valid for a NAPTR

Again this is why each registration will require a separate RFC to permit 
the IESG stringent review. I'm not worried about this.

>Have I got the salient points so far? (If so we can get on to the schema 

please do ...

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: Michael Mealling <[email-masked]>
Date: Fri, 24 May 2002 14:40:40 -0400

> such as in SIP.  IMHO such enumservice fields might IMHO pass muster.

Ok, I'll ask the question I asked before. Are you suggesting making it
illegal to use SIP in any other enumservice? (I don't think you are
but I'm just checking). If you aren't then what you are describing is
a service where the protocol tells you what the services are. You're
confusing the service with the protocol. The question is this:

Do you want an enumservice that gaurantees that you never see anything
but SIP from beginning to end? Then that's valid. (Limiting, but valid.)
But don't call it 'SIP'. Its just to confusing.

I would prefer an enumservice called 'inquire' that has a protocol
attached to it like this: "inquire+sip" so that other protocols can
be used with that service (e.g. LDAP). It still gives you the ability
to gaurantee that you never see non-SIP stuff (which is what I think
you are after) without creating an enumservice that never allows anything
else latter....

> Washington DC in a suit and tie explaining the privacy implications of this 

That may be the case but that's for them to decide.

> services field first ..even if similar data is contained in the URI within 

Yep. The URI is just the address of the endpoint and that needs to be
divorced from the actual ENUM service description. This is the problem
with many URL schemes these days: they're used as service descriptors when
there really isn't any direct correlation between the address and the service
offered at that address.

-MM

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

---

From: Richard Shockey <[email-masked]>
Date: Fri, 24 May 2002 15:30:04 -0400

>confusing the service with the protocol. The question is this:

now I am getting confused ... this all seemed so simple to me ..you need to 
give me a more concrete example here of what you mean ... what I am saying 
that SIP is SIP and the protocol itself defines "on the wire" what services 
/ capability can be offered.

>But don't call it 'SIP'. Its just to confusing.

duh ... that is what I want,  a enumservice that is SIP period and not 
broken up into E2U+SIP+voice / E2U+SIP+voice+IM etc etc

and why wouldnt I want call the NAPTR enumservice field for SIP , SIP?   I 
think this is what I mean and no I dont necessarily think its limiting. It 
is a view based on a pretty strong understanding of what SIP does and what 
it does not do.

I might say exactly the same thing about H.323 as well .

>you are after) without creating an enumservice that never allows anything

well inquire+sip is not SIP

No ... once the INVITE is sent the response will indicate its willingness 
to begin a session immediately or describe what is capable of 
accepting  SIP is SIP

>That may be the case but that's for them to decide.

NO .... I prefer not to have ENUM killed after the fact. Just as we are 
cognizant of security considerations in IETF protocols we, in this case, 
should be equally vigilant about privacy. Its there it is increasingly 
codified in law and it is in our best interest to

>there really isn't any direct correlation between the address and the service

good .. I was sure this is what we all understood to be the case.

---

From: Michael Mealling <[email-masked]>
Date: Fri, 24 May 2002 15:40:22 -0400

> / capability can be offered.

But I might not want to use SIP that way. I might not be using all of 
SIPs features or my client may be so dumb as to only be able to blast
out hardwired SIP packets. You are assuming a full SIP client and I'm
just suggesting that may not be the case.

> broken up into E2U+SIP+voice / E2U+SIP+voice+IM etc etc

Ok, no problem there... But again, are you suggesting that it be illegal
to use SIP in any other way?

> I might say exactly the same thing about H.323 as well .

But that's a _protocol_ view, not a _functional_ view. I know SIP does
all and that no one should ever use anything else for any reason but I've
also heard the same things about HTTP. What I'm trying to get is that
the function "you have to go ask via the protocol" is a valid service
that multiple protocols will offer (H323, SIP and even LDAP). Here's
an example: let's say someone is running an H323 service and provides
a SIP gateway to it but for contractual/market share reasons they want
to make the H323 service run better or have more features. Both interfaces
provide the "we'll tell you everything there is to know" service but
a client application may want to know that for that service there is
an H323 interface and a SIP interface for that function.

> to begin a session immediately or describe what is capable of 

Ok, how 'bout this: "invite+sip"? SIP maybe SIP but is SIP _everything_?
Is SIP the only protocol to ever be allowed to work this way? It really sounds 
like you're suggesting that SIP is the only thing anyone should be using 
and that you're willing to enforce that with ENUM.

> codified in law and it is in our best interest to

Sure. But you're _still_ looking at this in terms of your services and
policiess. Others may have other solutions and ENUM should be modular
enough so that those things are solved in the correct places, not 
mandated by 2916bis itself.

-MM

---

From: Richard Shockey <[email-masked]>
Date: Fri, 24 May 2002 16:35:30 -0400

>just suggesting that may not be the case.

I'm not willing to totally dismiss your point its just that , I guess, I 
really need to see a specific application requirement here for what you 
suggest.

>to use SIP in any other way?

No .. but you are thinking about something that I'm having serious trouble 
visualizing in my mind.

>an H323 interface and a SIP interface for that function.

Im not sure this is the best example since there are issues of who and what 
actually writes NAPTR records for a specific FQDN ..but I sense the 
direction you want to go but I'm still not convinced of its applicability 
without some other kinds of examples.

> > >you are after) without creating an enumservice that never allows anything

how would you express this function?

>Ok, how 'bout this: "invite+sip"? SIP maybe SIP but is SIP _everything_?

OK E2U+SIP+invite  or just E2U+SIP being the general case, plain vanilla, 
one stop SIP shopping. Can you elaborate more on what other options you 
propose.

You see my point about capabilities right?  I don't want SIP+voice 
SIP+video+IM etc.

You seem to be suggesting bonding several protocols and services in a 
single write of a enumservice field that may need multiple URI's in the 
regexp to parse?

I can be open minded ...but I think you are going to have a lot up hill 
work convincing the SIP community of what you are proposing.  And as you 
may know they are not shy about voicing their opinions... :-)

>mandated by 2916bis itself.

Well of course ... not in 2916bis but I would hope both you and Patrik add 
Privacy Considerations to Security Considerations as requirements for 
enumservice field IANA registration process.

I totally agree that the IANA registration process  is the place for the 
IESG to review and enforce that type of requirement.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 27 May 2002 10:48:19 +0100

>> data in the services field is a duplication and that it is far better to 

This over-summarises my position.

> services field first ..even if similar data is contained in the URI within 

What if the NAPTR *doesn't* agree with the services field ? For example, if
services is E2U+tel+SMS but the NAPTR ends up generating a mailto: URL ?

I'm not seeing a clear explanation of what is in the services field and
what is in the URL, why the same information needs to be in both, and what
happens if they disagree. As such, it feels like bad design.

-- 
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: Mon, 27 May 2002 11:10:30 +0100

>happens if they disagree. As such, it feels like bad design.
To which I reply:
Hi Clive, folks,
   first, sorry about over-summarising you position.

Further to your point above, it gets better if we have non-terminals.
What if one round of non-terminal processing reports one URI-scheme
and/or enumservice, and the next round of D3S lookup gives a NAPTR set
with different (disjoint) URI-schemes and/or enumservices?

How the heck do I run the admin system (to check on consistency of URI
or enumservice data in non-terminal NAPTRs), so that a mere mortal will
understand the error messages it sends them (Ignoring the performance
requirements for chasing D3S "links" when doing this)?

That's the case even if we only have enumservice sub-fields (leaving
the regexp-reconstructed URI to hold its own data).

all the best,
   Lawrence

---

From: Richard Shockey <[email-masked]>
Date: Mon, 27 May 2002 11:22:06 -0400

>services is E2U+tel+SMS but the NAPTR ends up generating a mailto: URL ?

What is the conflict with this  .. this is actually a really good example 
of a very creative service !!  The only way I prefer you to reach my mobile 
SMS end point is to use a SMTP gateway where I could a apply a spam filter 
...I like this one !!  I'll buy this!!!

---

From: Richard Shockey <[email-masked]>
Date: Mon, 27 May 2002 13:29:43 -0400

So to summarize what I'm beginning to hear is a distinct set of principals 
governing the definition of the enumservice field.

1. One registration per service.

2. The '+'  should only be used to separate distinct services.

3. There is no need to distinguish protocol from service in the enumservice 
field, by that if you want define 'smptfaxs'  there is no need to express 
that as smtp+fax+s. The registration document for 'smtpfaxs' will in 
addition to a applicability statement ...
         a .define the service.
         b. protocols used (referencing appropriate RFC's etc)
         c. anticipated behavior
         d. security concerns
         e. privacy concerns

4. There is no need to define distinct services in the case of protocols 
like SIP or FAX where there is "on the wire" negotiation of capabilities or 
preferences.

I'm still waiting to hear exactly what Mike Mealling has in mind here for 
his specific cases where there might be such a construct as 
"E2U+SIP+SIPLDAPthing" where the definition of 'SIPLDAPthing' is directly 
defined as operation to be used in conjunction with or in parallel with SIP 
itself...   ???? Is this what you are saying?

am I missing something?

---

From: Lawrence Conroy <[email-masked]>
Date: Mon, 27 May 2002 18:42:32 +0100

At 1:29 pm -0400 27/5/02, Richard Shockey wrote:
>So to summarize what I'm beginning to hear is a distinct set of 
>principals governing the definition of the enumservice field.
>
>3. There is no need to distinguish protocol from service in the 
>enumservice field, by that if you want define 'smptfaxs'  there is 
>no need to express that as smtp+fax+s. The registration document for 
>'smtpfaxs' will in addition to a applicability statement ...
>         a .define the service.
>4. There is no need to define distinct services in the case of 
>protocols like SIP or FAX where there is "on the wire" negotiation 
>of capabilities or preferences.
>
>
>I'm still waiting to hear exactly what Mike Mealling has in mind 
>here for his specific cases where there might be such a construct as 
>"E2U+SIP+SIPLDAPthing" where the definition of 'SIPLDAPthing' is 
>directly defined as operation to be used in conjunction with or in 
>parallel with SIP itself...   ???? Is this what you are saying?
>
>am I missing something?

To which I reply:
  Yes, you are missing something.
Yes, you are hearing (3) from Patrik and yourself exactly as you have 
defined above.
No, you are not hearing this from me (or others, AFAICT) - I can 
re-send the postings from
this last week if there was a communications failure.

Yes - include the URI-scheme in the services field, if you want this 
to be available before regexp processing.
No - IMHO there should NOT be a conflation of "higher level" function 
with the URI-scheme. That way lies combinatorial nightmare, and gives 
NO benefit that anyone has explained. Hence I'm strongly a'gin 
smtpfaxs or sipvoice or their ilk.

  Lawrence

---

From: Richard Shockey <[email-masked]>
Date: Mon, 27 May 2002 14:37:57 -0400

At 06:42 PM 5/27/2002 +0100, Lawrence Conroy wrote:
>>enumservice field, by that if you want define 'smptfaxs'  there is no 
>>need to express that as smtp+fax+s. The registration document for 
>>like SIP or FAX where there is "on the wire" negotiation of capabilities 
>>or preferences.
>>
>>
>>defined as operation to be used in conjunction with or in parallel with 
>>SIP itself...   ???? Is this what you are saying?
>>
>>am I missing something?
>
>To which I reply:
>No, you are not hearing this from me (or others, AFAICT) - I can re-send 
>the postings from

no thank you .. I have read the mail ..

>Yes - include the URI-scheme in the services field, if you want this to be 
>available before regexp processing.

I dont think this is absolutely necessary ... so tell me what is the 
difference between 'smptfax' and 'foofoofax' so long as it is properly 
defined in a RFC  and application programmers read the RFC and understand 
that foofoofax is defined in RFC2503?

I think what Patrik and I are getting at is that the NAPTR enumservice 
field is really just the
  [ 'translation technique for the regexp' (E2U)+ 'a _label_ for something 
defined in a RFC' ]

>No - IMHO there should NOT be a conflation of "higher level" function with 
>the URI-scheme. That way lies combinatorial nightmare, and gives NO 
>benefit that anyone has explained. Hence I'm strongly a'gin smtpfaxs or 
>sipvoice or their ilk.

OK?