[Enum] Fwd: I-D ACTION:draft-conroy-enum-modestproposal-00.txt
lconroy <lconroy@insensate.co.uk> Thu, 07 July 2005 06:03 UTC
From: lconroy <lconroy@insensate.co.uk>
Date: Thu, 07 Jul 2005 02:03:20 -0400
To: "'enum at ietf.org>"
Subject: [Enum] Fwd: I-D ACTION:draft-conroy-enum-modestproposal-00.txt
Message-ID: <9485a37c1614eca443ad023c6fe945b0@insensate.co.uk>
MIME-Version: 1.0
Content-Type: text/plain
Status: R
Hi Folks, herewith a note about this draft. Background: There has been some confusion over how to interpret RFC3403 section 4.1 (i.e. what fields there are in a NAPTR, and what to do with them). We also have a process issue with Penn & Steve's original proposal, as it suggested defining a non-terminal Enumservice, and we can't do that within the framework of RFC 3761. About this draft: This draft is the first part of a two part fix. This one attempts to clarify whether the Regexp field or the Replacement field should be non-empty in terminals and non-terminals, and how this is signalled (basically, by using the flags field). It SHOULD be "in the spirit of" DDDS, and I do not believe that it breaks ANY DDDS application (it certainly doesn't break ENUM). It will, however, make implementation easier, as the client program doesn't need to guess whether or not to expect the Regexp field to be occupied. In other news: The next step (after this one is through the process) will be to modify 3761 to allow for non-terminal flags, and to extend the template of section 2.4.2.1 and 3.1 to permit a non-terminal Enumservice to be registered for use with the new non-terminal flag. That one will have to wait, however. I believe that this, in conjunction with the to-be-produced RFC3761 enhancement, will solve the confusion and the process problem we have had. all the best, Lawrence Begin forwarded message: From: Internet-Drafts at ietf.org Date: 6 July 2005 20:50:02 BST To: i-d-announce at ietf.org Subject: I-D ACTION:draft-conroy-enum-modestproposal-00.txt Reply-To: internet-drafts at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Non-Terminal NAPTR Processing: A Modest Proposal Author(s) : L. Conroy Filename : draft-conroy-enum-modestproposal-00.txt Pages : 12 Date : 2005-7-6 Recent Discussions within the IETF and in other fora have highlighted differences in interpretation of the set of standards associated with ENUM and DDDS, on which it relies. Specifically, the operation and semantics surrounding support for non-terminal NAPTRs has led to some confusion. This document is an attempt to add clarification to non- terminal NAPTR processing. In this, it clarifies RFC3403. A subsequent document will build on this one to extend RFC3761 further, permitting registration of non-terminal Enumservices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-conroy-enum-modestproposal -00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org 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-conroy-enum-modestproposal-00.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: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-conroy-enum-modestproposal-00.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. Content-Type: text/plain Content-ID: <2005-7-6130827.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-conroy-enum-modestproposal-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum
- [Enum] Fwd: I-D ACTION:draft-conroy-enum-modestpr… lconroy
- [Enum] Fwd: I-D ACTION:draft-conroy-enum-modestpr… Richard Shockey
- [Enum] Fwd: I-D ACTION:draft-conroy-enum-modestpr… Richard Shockey