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

From: "Stastny Richard" <[email-masked]>
Date: Tue, 28 Feb 2006 22:10:35 +0100

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:[email-masked]]
Gesendet: Di 28.02.2006 19:41
An: Livingood, Jason; [email-masked]
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:[email-masked]]
Sent: Tuesday, February 28, 2006 1:27 PM
To: [email-masked]
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: [email-masked] [mailto:[email-masked]]
> Sent: Monday, February 27, 2006 3:50 PM
> To: [email-masked]
> Cc: [email-masked]
> 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 [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-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:
>       [email-masked].
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

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

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

---

From: lconroy <[email-masked]>
Date: Tue, 28 Feb 2006 23:41:44 +0000

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

---

From: "Pfautz, Penn L, NEO" <[email-masked]>
Date: Tue, 28 Feb 2006 19:35:57 -0500

Lawrence,
I don't want to belabor this as I'm not even sure that *I* wish to go
forward with the non-terminals but I'm not sure the working group came
to a consensus that non-terminals were generally not workable. They
clearly have their limitations with the regard to the specific problem
space I wanted to use them in - mostly because of the POSIX's weak-kneed
string processing capabilities (:-). The (non-binding) hum in Paris
indicated a strong preference for alternate or branching domains for
meeting the carrier ENUM need and I accept that.

If the WG is really ready to ban non-terminals than we should agree
formally and reflect it in the guidelines draft.

Regards,
Penn

-----Original Message-----
From: lconroy [mailto:[email-masked]] 
Sent: Tuesday, February 28, 2006 6:42 PM
To: Stastny Richard
Cc: Pfautz, Penn L, NEO; Livingood, Jason; [email-masked]
Subject: Re: [Enum] RE: Section 3.2 of
draft-ietf-enum-enumservices-guide-00 

Hi Richard, Penn, folks,

----

To recap the situation:

all the best,
   Lawrence

---

From: lconroy <[email-masked]>
Date: Wed, 1 Mar 2006 01:30:23 +0000

Hi Penn, folks,
   OK - I was not clear.
I don't think that Non-terminals are a bad idea. They're just hard to
understand and to test the clients we develop to support them. In fact,
I think that there definitely IS a place for Non-terminals, and would
be very unhappy with any decision to BAN them before we have had a
chance to play with them properly.

The Experiences draft already states that one should not use them for
"prime time" as many clients do not yet support them - that is not at
all the same as saying that they should be banned.

The new ideas we kicked around last year were interesting, and I'm
pretty sure could be added as I listed - it's just not trivial, and
there was a simpler way of solving the Carrier ENUM issue (i.e. one
that does not involve a lot of waiting around for a enhanced and
re-written standard to grind through the process ;).

Personally, I think that it would be a lot of fun to add a new flag.
However, in practice it would take some time - 3761 was not exactly
"fast out of the traps" in replacing 2916. Thus maybe we defer doing
that for the future - It's something to discuss in Dallas.

I suspect that the existing Non-terminal mechanism works for a lot
of different use cases - few have really tried them out yet in ENUM.
They may well be enough for even fairly whacky situations - just
not quite right for User/Carrier splits.

all the best,
   Lawrence