Subject: [Enum] NAPTR RS sub-field field and why it's there

From: Lawrence Conroy <[email-masked]>
Date: Thu, 21 Feb 2002 12:03:21 +0000

Hi Folks,
    I am looking at the contents of the NAPTR fields and how they might
be used in an implementation. When the user "fires up" the ENUM
program, passing it an E.164 number, it's pretty obvious that it wants
the program to accept an E.164 number and return a URI (or URIs) - that's
what the program does, extracting information from the DNS as needed.

Thus it seems to me that the RS part of the Services field in a NAPTR only
confirms that this record is intended for use in a program that accepts
E.164 numbers and returns a URI (in short, ENUM). It can be used internally
by the ENUM application to drop any NAPTR record it retrieves that has another
RS value, but there's no earthly reason to pass it back up to the user.

Is this correct, or am I missing something?

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

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

---

From: Michael Mealling <[email-masked]>
Date: Thu, 21 Feb 2002 08:51:52 -0500

> Is this correct, or am I missing something?

I think you would be correct if we kept the Services field as is, e.g. 'E2U'.
But there is some desire among some definition of majority that ENUM's
Service definition is to flat. Thus you could start seeing Services that,
while still discussing the fact that the input is E.164 and the output
is a URI, denote that the Service in question is for Voice Mail while this
other one is for a Voice Call, and that this other one is for a Fax Call.
The other change is that the relationship between the protocol in the
Service field and the URI scheme also needs work. For example, the 
protocol could be 'smtp' while the URI scheme was 'mailto'. Or the
protocol might be 'apex' and the URI scheme would be 'im'.

So, you are correct but possibly only for now. So if I were designing
an API I would plan for this possibility.

-MM

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

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 21 Feb 2002 16:30:34 +0000

Hi Folks,
I reply (rather more warmly than  normal - apologies in advance, 
gentle readers):

>other one is for a Voice Call, and that this other one is for a Fax Call.

Ugly conflation and potentially unnecessary IMHO.
Resolution Service is pretty strange, and with the conflations some folk
have proposed it's just plain confusing. As you suggested a few posts ago,
it can eaasly be used to assert that a NAPTR is for use only with specific
Resolution Service, so if a DDDS application gets a NAPTR back with an
unrecognised RS value, it drops it on the floor - thus it's an Application
Collision Avoidance mechanism. Fine.

However, with the conflation ideas floating up, this makes the job of
writing a sensible application quite hard. Do I have to update all of
the ENUM applications out in the field because someone has invented a
new "service" value of E2BONGOBONGOVIDEOPLUSSURROUND? I fear so.

Without this stuff, I just pass back the URI and protocol/treatment
values and let the caller' system decide what to do with them.

>protocol might be 'apex' and the URI scheme would be 'im'.

Agreed that the names 'Resolution Service' and 'Protocol' are badly
out of whack. However, that is not all.

AFAIK, each DDDS application has to specify the Services field syntax
it will expect (and so is responsible for [re-]defining RS and Protocol
and any other sub-fields). This is not too good - I'd suggest that the
"template" DDDS document defines a default, and allows an application
that needs a different Services field syntax to "opt out" rather than
the current cut-and-paste.

Whilst you're at this, why not re-consider the names of these sub-fields.
I guess that there will be a number of documents that have to specify
and request registration for what we now call RS and protocol sub-fields.
Having these names doesn't help the reader to fathom out what exactly
the purpose for which they're being used, IMHO.

I've already ranted enough on RS. I feel that even protocol is not perfect
- there are times when we don't actually involve an IP-based protocol
to further resolution or use of the URI. We've been having discussions
"in-house" on this, and treatment may be closer to how it may be used.

>an API I would plan for this possibility.

In either case, I understand that a 'protocol' value  may WELL be passed
back to the caller of the ENUM application, so that this, plus the URI,
can be used to decide on further handling. I just don't think that the
RS value has any reason to be passed back.

---

From: Michael Mealling <[email-masked]>
Date: Thu, 21 Feb 2002 11:52:47 -0500

On Thu, Feb 21, 2002 at 04:30:34PM +0000, Lawrence Conroy wrote:
> >> E.164 numbers and returns a URI (in short, ENUM). It can be used 
> >> internally by the ENUM application to drop any NAPTR record it retrieves 
> >> that has another RS value, but there's no earthly reason to pass it back 
> >> up to the user.
> >>
> >I think you would be correct if we kept the Services field as is, e.g. 
> >'E2U'.  But there is some desire among some definition of majority that 
> >ENUM's Service definition is to flat. Thus you could start seeing Services 
> >that, while still discussing the fact that the input is E.164 and the output

For your applications, maybe. The request has been voiced to me at just
about every IETF meeting since RFC 2916 came out...

> values and let the caller' system decide what to do with them.

That might be fine if you had control over them but how does the 
callers system know what to do with a URI of the form:

mailto:[email-masked]

Can you send it voice mail? Is it my regular text email address?
Am I currently listening to it? The point being, a URI by itself
doesn't tell you what its actually supposed to be used _for_.

> the current cut-and-paste.

I could but that makes it to easy for different Applications to start
copying from each other and IMHO that leads to more work doing 
collision avoidance. I would much rather each Application have to 
at least think about it than just hand them a default...

> "in-house" on this, and treatment may be closer to how it may be used.

Sure. Nothing here requires IP. Heck, ENUM could specify another 
database besides DNS eventually and still have the same procedures
apply. But I think 'protocol' is generic enough. I think you may
be giving the word more weight than was intended. I've been working 
on the DDDS documents way to long to rip 'em apart yet again. ;-)

> RS value has any reason to be passed back.

I'm just saying that is still up for discussion. See:
http://search.ietf.org/internet-drafts/draft-walter-ranalli-enum-service-01.txt
for an example...

-MM

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 22 Feb 2002 09:12:34 +0100

> Whilst you're at this, why not re-consider the names of these sub-fields.

We now only talk about "enumservice".

  paf

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 22 Feb 2002 09:42:00 +0000

>We now only talk about "enumservice".
To which I reply
     (as in my 2916bis comments):
Absolutely fine - I'm much happier with enumservice than protocol & rs.

Re. rumour of tel doc. Rudi & I have been trying to put something down
in black & white electrons.
Today we'll re-touch it to fit with the template and ABNF in 2916bis.
Please don't change it back.

Re. CNAME considered harmful, or at least might give a hangover, or
perhaps is not good for the heart, or ...

   DNSOP is the place to be?
     Thanks - Just what I need is registering for another mailing list :(
     SIP/SIPPING/SIP-IMP/... isn't enough traffic already ).

   The issue here is that, if one CAN use CNAME, then it looks like you
   don't need to re-submit a new ENUM query with the content of a tel:
   URI. Unless there's some big reason why this WILL not work, then I
   will put into the tel: spec that re-submission is disrecommended,
   with a warning that looping may be someone else's mistake, but it's
   your problem, as you re-submitted.

br,   Lawrence

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 22 Feb 2002 10:48:09 +0100

>    your problem, as you re-submitted.

Some DNS information: If you have a CNAME for an owner, you can not have
_anything_else_ in the same RR-set.

I.e. if you have a CNAME which is foo.paf.se, you can not also have a NAPTR
for foo.paf.se.

  paf