Subject: [Enum] I-D Action:draft-ietf-enum-3761bis-02.txt

From: [email-masked]
Date: Wed, 13 Feb 2008 16:30:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title           : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
	Author(s)       : S. Bradner, et al.
	Filename        : draft-ietf-enum-3761bis-02.txt
	Pages           : 20
	Date            : 2008-02-13

This document discusses the use of the Domain Name System (DNS) for
the storage of E.164 numbers, and for resolving them into URIs that
can be used for (for example) telephony call setup.  This document
also describes how the DNS can be used to identify the services
associated with an E.164 number.  This document obsoletes RFC 3761.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-3761bis-02.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-enum-3761bis-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-enum-3761bis-02.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
enum mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/enum

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 15 Feb 2008 17:45:26 +0100 (CET)

Dear Authors of RFC3761bis

I briefly went through the I-D and can provide you with the following 
feedback:

* Add "Obsoletes RFC 3761" to the header of the I-D

* ABNF

You have extended the ABNF for type and subtype by a dash "-" character.

       type          = 1*32(ALPHA / DIGIT / "-")
       subtype       = 1*32(ALPHA / DIGIT / "-")

I guess the intension was to allow the "X-", which was somewhat 
inconsistent in RFC 3761.

Do you intend to allow "-" everywhere in the Type and Subtype strings?

I'd rather restrict it to "-" only as the 2nd character and only if the 
prefix containing a "-" as 2nd charater is defined/described in an RFC.

This could be reached by:

- Write some text to permit "-" only as 2nd character, and/or
- Restrict this in the ABNF such as

   [sub]type = ALPHA (ALPHA / DIGIT / "-" )  1*30 ( ALPHA / DIGIT )

   Note: This proposal would also disallow a digit as the 1st character.

What do you think about?

cheers,
  Bernie

---

From: lconroy <[email-masked]>
Date: Fri, 15 Feb 2008 17:19:40 +0000

Hi Bernie, folks,
   As I understand it, it will obsolete RFC 3761 when it's an RFC,
but this draft doesn't obsolete anything. The author of RFC 2026 is
familiar with this draft, so could give you the gory details  :).

The ABNF addition in this form is my fault.
It would be possible to have an Enumservice with a sub-type reflecting
a URI scheme which itself had a "-". I don't say it's a good idea to
define a URI scheme this way (or to have a sub-type string that matches
such a URI scheme), but it is legal => '-' needs to be available in both
type and subtype definitions.

While making the change to permit "X-foo", I realised that it might be
useful to allow some kind of punctuation in the service name to make it
clearer - thus one could imagine something like "real-time-text" as a
service type. I believe that this is a reasonable choice. Why not?

I looked at discouraging Enumservice definitions that are runs of
punctuation, or digits, or something like that. That is NOT easy in
ABNF (if possible), and again, why not, as long as it is unique?
The registration doc should/does suggest that someone gives a useful
Enumservice type name, but that is "not so much a law, more a kind of
guideline".

----

Finally, why *require* an RFC for "X-foo"?
Personally, I would prefer it if some kind of RFC (including  
experimental
or Informational) was required for Enumservices that did NOT start "X-".

In the last ENUM meeting folk said that a simple notification to IANA  
with
a partially populated template would be enough. That is OK-ish, as  
long as
it is CLEAR whether the IETF has seen this spec and it at least has a  
fully
detailed template, or instead it has come out of the blue/IPv16 world
(in which case it MUST start "X-").

all the best,
   Lawrence

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 15 Feb 2008 18:39:25 +0100 (CET)

Hi Lawrence

> familiar with this draft, so could give you the gory details  :).

xml2rfc produces the following header:

  Obsoletes: 3761 (if approved)

> Finally, why *require* an RFC for "X-foo"?

This is not what I meant.

I suggested that any prefix containing a "-" as a 2nd character (e.g. X-, 
P-, A-, Z-, ...) needs to be documented in an RFC (to allow the prefix 
to be used as type or subtype in Enumservice Registrations).
The registration itself would still be just "specification required".

cheers,
  Bernie