Subject: [Enum] a bug in RFC 2915 (fixed in draft-ietf-urn-ddds-04.txt)

From: Michael Mealling <[email-masked]>
Date: Mon, 20 Aug 2001 14:44:26 -0400

Hi all,
  James Yu has discovered a bug in the algorithm specification in RFC 2915
that may bite many ENUM implementations. Section 4, paragraph 4 says this:

   The first match MUST be the match that is used.  Once a match is
   found, the Services field is examined for whether or not this rule
   advances toward the desired result.  If so, the rule is applied to
   the target string.  If not, the process halts.  The domain that
   results from the regular expression is then used as the domain of the
   next loop through the NAPTR algorithm.  Note that the same target
   string is used throughout the algorithm.

The sentence "If not, the process halts." is incorrect since this would
mean you can never see alternative records that may match but have
different Services fields. The sentence should read like this:

"If not, then continue with the next record in the existing list of records
and do the match/Service field examiniation step again."

This has been fixed for a while in draft-ietf-urn-ddds-04.txt. I hope
that we can see the DDDS documents out as RFCs soon...

Thanks to James for catching this one!

-MM

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

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

---

From: Richard Shockey <[email-masked]>
Date: Tue, 21 Aug 2001 10:49:40 -0400

>that we can see the DDDS documents out as RFCs soon...

Thanks Mike !  A note to list readers ... when this document is finished it 
will Replace RFC 2915 as the definitive definition of NAPTR 
records.  Documents being developed by our colleagues in ITU Study Group 2 
should reflect this fact.

I'm sure we'll also see a form of IANA registration procedure for the 
protocol element etc aka "SIP+E2U" ?

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 571.434.5651 Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Michael Mealling <[email-masked]>
Date: Tue, 21 Aug 2001 11:25:47 -0400

> protocol element etc aka "SIP+E2U" ?

I think the group will need to define what the difference is between
the 'protocol' in the Service field and the URI scheme. The format
you guys are using gives you the ability to say 1 protocol and n services.
IMHO, the protocol should be the on the wire protocol and the
service should be the class of things the end point exposes.
I.e. "sip+E2IM" would mean this node handles E.164 to Instant Messaging
end point via the SIP protocol. It can also handle a range of services
such as 'sip+E2IM+E2V+E2P+E2EMAIL' where E2V is E.164 number to a 
voice capable end point, E2P could be presence. This allows you to say
things like "this end point is for IM style stuff and it uses SIP" but
"this end point does voice via H.323" and "this end point handles SMTP
email".

As things currently stand you only know the URI scheme. You have no way
to differentiate between two end points as to what actual functions they
can handle....

Its a simple fix, though....

-MM