[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