Subject: RE: [Enum] New version of rfc2916bis

From: "Stastny Richard" <[email-masked]>
Date: Mon, 25 Nov 2002 15:19:25 +0100

Comments inline:

>1.3 Application of local policy

>The priority field in the NAPTR is a request from the holder of the
>E.164 in what order the records are to be used.  It is to be noted
>that the party looking up the records MAY apply a local policy for in
>what order the records are to be used based on a combination of the
>service fields and URI schemes.

As I understand RFC3403, there is an Order and a Preference field,
but no Priority field. Since the order field applies
IMHO only if not-terminal NAPTRs (no U Flag) are used,
here the preference field should be mentioned and the word
order should be avoided eg: ...for the preference of the usage of ...

This also implies, that the example in 4.1 should be
modified accordingly.

> 
> 2.4.2.1 ENUM Services
> 
>An enumservice MUST be registered with the IANA via a description in
>an RFC.  Enumservices specifications contain the functional
>specification (i.e.  what it can be used for), the valid protocols,
>and the URI schemes that may be returned.  Note that there is no
>implicit mapping between the textual string "type" or "subtype" in
>the grammar for the Enumservice and URI schemes or protocols.  The
>mapping, if any, have to be made explicit in the specification for
>the Enumservice itself.  A registration of a specific Type also have
>to specify the Subtypes allowed.

I still have some problems with this: the best way to check
the feasability of a statement is (we just had elections;-)
to consider the opposite or an extreme example:

The above statement would allow to define a service called
sip and to define that the only valid URI-scheme to be returned
is h323:

This obviously does not make sense and therefore will never happen
(I hope;-).

The examples (existing and deleted ones) also show, that there
WILL always be a kind of mapping between the textual string 
"type" and "subtype" and the grammar for the Enumservice and
URI schemes or protocols, and if this is so, it should be 
stated. The only exception I can imagine is that the
below stated requirement for uniqueness in 3.1.2 may require
to chose a different textual string (and also in this
case one would not choose a completely misleading one)

If I consider the following:

> 3.1.1 Functionality Requirement
> 
>An Enumservice registered must be able to function as a selection
>mechanism when choosing one NAPTR resource record from another.  That
>means that the registration MUST specify what is expected when using
>that very NAPTR record, and the URI which is the outcome of the use
>of it.
> 
>Specifically, a registered Enumservice MUST specify the URI scheme(s)
>that may be used for the Enumservice, and, when needed, other
>information which will have to be transfered into the URI resolution
>process itself (LDAP DNs, transferring of the AUS into the resulting
>URI, etc).

and I also consider the discussions we had in ATL: that it is not
allowed to look at the "right" for the URI scheme, it is obvious,
that the "type" or the "subtype" of an enumservices (if it may be
usable with more then one URI scheme and may eventually 
require different selection mechanism when choosing one NAPTR
resource record from the other) needs to indicate the URI scheme.

Anything other then having the "type" or "subtype" different
from the URI scheme would be weird indeed (except if required 
for uniqueness).

> 3.1.2 Naming requirement
> 
>The name of an Enumservice MUST be unique, conform to the ABNF
>specified in Section 2.4.2, and MUST NOT start with the facet "X-"
>which is reserved for experimental, private use.

This is not completely clear to me, especially
in combination with the statement in 2.4.2.1

"A registration of a specific Type also have
to specify the Subtypes allowed."

Of course finally the "type":"subtype" combination
(in this order) has to be unique. I also defer that
a "type" MUST be unique, especially if the "type" is specifying
the "subtypes" (to be used within the type).

I also defer from the discussion in ATL that a 
"type" and a "subtype" need not to be unique, 
e.g. we may have a "type"=sip and a "subtype"=sip.

If now the registration of the "type" specifies
the specific "subtypes" allowed within this "types",
and also the mapping, the "subtypes" need NOT to be unique.

e.g voice:tel and sip:tel is possible to mean something
(not necessarily completely) different and the same holds for 
voice:sip and sip:voice.

Therefore "subtypes" tel and sip for enumservice(s)
voice:tel and voice:sip are defined with "type" voice

and
"subtypes" tel and voice for enumservice(s)
sip:tel and sip:voice are defined with "type" sip.

> 4. Examples
> 
>The examples below use theoretical services which uses Enumservices
>which might not make sense, but they are still used for educational
>purposes.  For example, the protocol used is in some cases exactly
>the the same string as the URI scheme.  That was the specification in
>RFC 2916, but this default specification of a Enumservice is no
>longer allowed.  All Enumservices need to be registered explicitly by
>the procedure specified in section Section 3N.
> 
> 4.1 Example
> 
>     $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
>       IN NAPTR 100 10 "u" "E2U+sip"            
> "!^.*$!sip:[email-masked]!"     .
>       IN NAPTR 101 10 "u" "E2U+h323:voice"     
> "!^.*$!h323:[email-masked]!"    .
>       IN NAPTR 102 10 "u" "E2U+message:mailto" 
> "!^.*$!mailto:[email-masked]!"  .
 
Even if it is stated above that the examples might not make sense,
IMHO they should, and also referring to the discussion in ATL
and the search for a compromise between the proposals I would prefer
to have the following example:

>     $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
>       IN NAPTR 100 10 "u" "E2U+sip"            
> "!^.*$!sip:[email-masked]!"     .
>       IN NAPTR 100 20 "u" "E2U+voice:h323"     
> "!^.*$!h323:[email-masked]!"    .
>       IN NAPTR 100 30 "u" "E2U+message:mailto" 
> "!^.*$!mailto:[email-masked]!"  .

See also the same order and different preference as mentioned above.

>This describes that the domain 4.3.2.1.6.7.9.8.6.4.e164.arpa is
>preferably contacted by SIP, secondly via H.323 for voice, and
>thirdly by SMTP for messaging.  

ok, but:

>Note that the tokens "sip",
>"message", "h323", "voice" and "mailto" are Types and Subtypes
>registered with IANA, and they have no implicit 
>connection with the
>protocols or URI schemes with the same names.
> 

First, in the example they HAVE an implicit connection with the
same names, so one comes either up with an example showing that
there is no explicit connection or the paragraph is reworded e.g.:

Note that the tokens "sip", Voice" and "message" are Types registered
with IANA, "Voice" and "message" with their resp. Subtypes "h323" and "mailto", and they MAY have no implicit connection with the protocols 
or URI schemes with the same names.

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

---

From: Michael Mealling <[email-masked]>
Date: 25 Nov 2002 09:58:09 -0500

> This also implies, that the example in 4.1 should be

Incorrect. The term 'Priority' is from the DDDS algorithm. It is
equivalent to the Preference field in the NAPTR (Preference is used in
deference to DNS experts language preferences). Also, DNS returns
records in what ever order the nameserver likes with no gaurantees to
the querier that the order will make any sense. I would strongly object
to any wording being in the document that suggests any implementation
should ignore the Order field or that the ordering step be optional.
As an example shows below, records of different order accomlishes one
thing while records of the same Order and different Priority/Preference
does something completely different.

> sip and to define that the only valid URI-scheme to be returned

Yes it would.

> This obviously does not make sense and therefore will never happen

It might make sense. You'd have to read the document that defines what
the 'sip' service definition was and why it decided to only allow 'h323'
URIs. 

> case one would not choose a completely misleading one)

Let's make sure we're clear here: there is no relationship between a
string in the enumservice field and the URI scheme in the regexp field
other than what is defined to be allowed in the enumservice registration
document.

> resource record from the other) needs to indicate the URI scheme.

Incorrect. An enumservice defines what URIs can and might appear in the
regexp field. If a particular enumservice limits itself to only allow
one particular URI scheme then it must say so. But, IMNSHO, it MUST not
replicate the URI scheme directly into the Services field. Those two
concepts are not equivalent. A URI identifies a Resource within the
systems of URIs. An Enumservice defines a set of inputs, outputs and
processes using E.164 numbers and URIs. Those two things are orthogonal
and thus REQUIRES an explicitly types mapping function between the two.

> and also the mapping, the "subtypes" need NOT to be unique.

Sure... hence the discussion about transitive subtypes. 

> sip:tel and sip:voice are defined with "type" sip.

Correct. That's what the document says. The enumservice is unique. It
never says that subtypes are unique....

> > "!^.*$!mailto:[email-masked]!"  .

I actually like the previous version of the example. I would like some
text discussing the fact that the h323 service subtypes based on
function class while the last record defines function classes as
services and then subtypes based on how that service is expressed.

> See also the same order and different preference as mentioned above.

Can you elaborate on that statement? The two examples above are actually
doing very different things. The example in the document is saying that
you have to match explicitly on each group's service field and you can
only use the one that matches first. The second is saying that each
service is 'equivalent' and the client gets to pick. That's two very
different things.

> or URI schemes with the same names.

No they don't. The only implicit connection exists in the fact that you
are making an incorrect assumption about the coincedence between two
fields containting the same characters. The three characters 's', 'i'
and 'p' that happen to appear in the Enumservice field are nothing more
than a pointer into a database managed by the IANA that contains a
document which explains rather explicitly what those three letters mean
when found in that field. By inserting 'MAY' in there you are suggesting
that there is a relationship between the characters found in the
enumservice field and something else that is defined outside the
enumservice registration documents.

-MM

-- 
Michael Mealling <[email-masked]>
HHI, Inc.

---

From: Richard Shockey <[email-masked]>
Date: Tue, 26 Nov 2002 15:34:59 -0500

>On Mon, 2002-11-25 at 09:19, Stastny Richard wrote:

OK my two cents worth....

>does something completely different.

ack... priority=preference ... I think Richard understands that now.

>other than what is defined to be allowed in the enumservice registration

yes Mike ... as you say ..you could define a enumservice field 'voice' and 
the only valid URI scheme would be SIP ... and another enumservice field 
'barf" and the only valid URI scheme would be h323. Also ... you can define 
a enumservice field 'sip' and the only valid URI is scheme is sip

Now that is a extreme example :-) but I think illustrative of what your 
point is. Though some of us accept that the logical ordering is 
type=sip  subtype=voice et.al. and not the other way around.

Richard ..now dont get started.. :-)

But if a enumservice field 'voice' is established with subtypes sip and 
h323 then IMHO that there is functional equivalency between

E2U+voice:sip    and
E2U+sip:voice

am I making sense here?

That many of us would like to use sip and h323 as enumservices has to do 
with how the NAPTR records are processed by client user agents and that is 
where we still need clarification.

This is a old problem that goes back quite a while and Richard is entirely 
correct is wanting a more concrete explanation. Jon James Yu and I brought 
this up a long time ago.

I have always understood the parsing of the NAPTR records upon receipt to 
occur FIRST on the enumservice field to find the service(s) desired.  There 
is NO look ahead to the URI's in the regexp. Once those records for a 
enumservice are chosen a further selection can be made on the order field 
as you have in the example so that if a CU/A sees two sip enumservices it 
can properly select which one to process first.

I thought we were agreeing that two similar services should maintain the 
same preference value.

The clarification as I see it is what is the proper relationship to order 
and preference (priority) in processing.

We definitely need better text here.

>and thus REQUIRES an explicitly types mapping function between the two.

Mike I'm lost with this comment. Could you elaborate?

> > (not necessarily completely) different and the same holds for

well this is the problem I have ... this could be very very confusing to 
implementers if it is held that these two could actually define different 
things assuming that a CU/A is going to look at these fields first.

unless,as you point out, that in the registration document for 'voice' it 
is explicitly understood that these MUST be treated as equivalent.

>service is 'equivalent' and the client gets to pick. That's two very

exactly

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
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>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<