Re: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices-guide-00

["Stastny Richard" <[e-mail]>]

My (our) opinion is well known: I prefer
3.  There should be a separate sub-type for each URI scheme.

Re to Penns question:

Lets not mix up this with Enumservices and non-terminal
NAPTRs. IMHO we should dicuss the issue of non-terminal NAPTRs
separate, i.e if non-terminals should contain an Enumservice or
may not contain an Enumservice at all, and if they should contain subtypes

see Otmars I-D
http://www.ietf.org/internet-drafts/draft-lendl-domain-policy-ddds-00.txt

on policy NAPTRs:

 An empty (non-existent) flag means that this rule is non-terminal and
   the client MUST use the key resulting from this rule as the input
   into a new DDDS loop.  Such non-terminal NAPTRs MUST NOT contain a
   policy-type element in the service-field.

I do not suggest yet any answer, but we should have a
statement in an eventual RFC3761bis, to make this clear.

regards

Richard







________________________________

Von: Pfautz, Penn L, NEO [mailto:[e-mail]]
Gesendet: Di 28.02.2006 19:41
An: Livingood, Jason; [e-mail]
Betreff: RE: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices-guide-00 



Jason:
Actually, one the things that I like about the current draft was the
indication (in the XML template) that sub-type was not always required
("use N/A if none") as this accommodates non-terminal NAPTRs. Thus, the
guideline,

1.  A sub-type should always be specified.

Needs to be reworded to make clear when subtypes are or aren't required.

Penn
-----Original Message-----
From: Livingood, Jason [mailto:[e-mail]]
Sent: Tuesday, February 28, 2006 1:27 PM
To: [e-mail]
Subject: [Enum] RE: Section 3.2 of draft-ietf-enum-enumservices-guide-00


I would like to point out section 3.2 and ask for some specific WG
feedback.  Here is the text:

   This section MUST be included in an Enumservice registration.  In
   addition, where a given registration type has multiple subtypes,
   there MUST be a separate registration section for each subtype.  The
   following lists the sections and order of an Enumservice Registration
   section.  All types and subtypes SHOULD be listed in lower-case.

This took into account WG feedback to have a separate Enumservice
registration section for each sub-type (a given I-D could therefore have
several registrations). 

The question we now have is...  What about when there are multiple URI
schemes for a given sub-types? 

This is, for example, what was done in RFC 4002, where the URIs http and
https each had separate registrations, as each URI was tied to a
specific sub-type that matched the URI scheme.  (URI=http,
sub-type=http, and URI=https, sub-type=https)

In contrast, RFC 3764, has multiple URIs given type (no sub-type is
registered).

Our tendency is to assert that these may be guiding principles:
1.  A sub-type should always be specified.
2.  There should be a separate registration for each sub-type.
3.  There should be a separate sub-type for each URI scheme.

Thanks for your feedback,
Jason



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Monday, February 27, 2006 3:50 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [Enum] I-D ACTION:draft-ietf-enum-enumservices-guide-00.txt
>
> 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           : Guide and Template for IANA
> Registrations of Enumervices
>       Author(s)       : J. Livingood, B. Hoeneisen
>       Filename        : draft-ietf-enum-enumservices-guide-00.txt
>       Pages           : 12
>       Date            : 2006-2-27
>      
>    This document provides a guide to and template for the creation of
>    new IANA registration of ENUM services.  It is also to be used for
>    updates of existing IANA registrations.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservic
> es-guide-00.txt
>
> To remove yourself from the I-D Announcement list, send a
> message to [e-mail] 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-enumservices-guide-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:
>       [e-mail].
> In the body type:
>       "FILE
> /internet-drafts/draft-ietf-enum-enumservices-guide-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.
>

_______________________________________________
enum mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/enum




_______________________________________________
enum mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/enum