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

[lconroy <[e-mail]>]

Hi Richard, Penn, folks,
  Like he said. Sub-types are good.
Even with SIP, the type is typically the kind of thing you do (all
that wonderful negotiation, rendezvous, and stuff), whilst SIP is
also the protocol you use to carry the exchanges to do it. In that
particular case, the two are and always will be synonymous.
For pretty much everything else, that you can't always be so sure.

As we should not "look right" (to the RegExpfield) in the NAPTR, the
sub-type is a good place to indicate the protocol used.
RFC 4355 is a good example, as MMS is the thing to do, whilst this
can be done via mailto: or tel:. Likewise for Web, via http: or https:.
Personally, I would *always* like a sub-type holding the protocol,
even if it is a duplicate. It also makes parsing the Services field
easier :)

----
Re. Non-Terminals (again).
This was discussed on this list last year. Indeed, IIRC, Penn raised it.
The conclusion then was that it is not possible with RFC 3761 to do this
- it isn't just the sub-type that's the problem, it's the whole thing.
This is already mentioned in the Experiences draft.

To recap the situation:
Any Enumservice registration MUST specify the "something" it does,
as well as the protocol it uses to do it; That's tied (in ENUM) to
the 'u' flag, indicating that the result is a URI.
A Non-terminal does not generate a URI to do something, it holds a
domain name in which to search. Thus the 'u' flag (and an Enumservice
registration) is inappropriate.

At present, ENUM only specifies the 'u' flag or no flag (an empty
flags field). It states that this lack of a flag means that this NAPTR
is non-terminal (and by implication, uses the replacement field to hold
the domain name). Note that other DDDS applications make this  
assumption,
so we can't just re-interpret an empty flags field without causing a
potential collision with searches being carried out with other DDDS
applications (not to mention confusing the poor developers further :).

New idea, new work - If we want to do something else in ENUM, then (as
I said last time this came up):
(i) we need to add a new flag, specifying that this flag is non- 
terminal,
and whether it uses the replacement field or the regexp field to hold or
generate its domain name (i.e. the key to be used in the next query on
the only rule store defined for use with ENUM -> DNS).
(ii) We need to define a new "Non-terminal Enumservice" registration
process that is tied to that flag (in the same way that there is now
the current Enumservice registration process tied to the 'u' flag).
(iii) IF this new flag indicates that the RegExp field is to be used to
construct a domain name, then we will need to specify quite how it is  
used.

This can be done, it could even be a neat idea, but it is not trivial.
I suspect that (iii) will take some effort to define in enough detail to
be usable/possible to implement securely. It will be fun. Perhaps we
can discuss this at the upcoming "high bandwidth exchange" in Dallas?

However, any such new work has nothing at all to do with the existing
(terminal, tied to the 'u' flag) Enumservice registration process as
specified in RFC 3761. Gaining consistency in THAT process is what the
template draft is trying to clear up, and does well, IMHO.
----

all the best,
   Lawrence

On 28 Feb 2006, at 21:10, Stastny Richard wrote:
> 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


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