Re: Feedback to draft-ietf-enum-3761bis-02.txt

Hi Bernie, folks,
   As I understand it, it will obsolete RFC 3761 when it's an RFC,
but this draft doesn't obsolete anything. The author of RFC 2026 is
familiar with this draft, so could give you the gory details  :).

The ABNF addition in this form is my fault.
It would be possible to have an Enumservice with a sub-type reflecting
a URI scheme which itself had a "-". I don't say it's a good idea to
define a URI scheme this way (or to have a sub-type string that matches
such a URI scheme), but it is legal => '-' needs to be available in both
type and subtype definitions.

While making the change to permit "X-foo", I realised that it might be
useful to allow some kind of punctuation in the service name to make it
clearer - thus one could imagine something like "real-time-text" as a
service type. I believe that this is a reasonable choice. Why not?

I looked at discouraging Enumservice definitions that are runs of
punctuation, or digits, or something like that. That is NOT easy in
ABNF (if possible), and again, why not, as long as it is unique?
The registration doc should/does suggest that someone gives a useful
Enumservice type name, but that is "not so much a law, more a kind of
guideline".

----

Finally, why *require* an RFC for "X-foo"?
Personally, I would prefer it if some kind of RFC (including  
experimental
or Informational) was required for Enumservices that did NOT start "X-".

In the last ENUM meeting folk said that a simple notification to IANA  
with
a partially populated template would be enough. That is OK-ish, as  
long as
it is CLEAR whether the IETF has seen this spec and it at least has a  
fully
detailed template, or instead it has come out of the blue/IPv16 world
(in which case it MUST start "X-").

all the best,
   Lawrence


On 15 Feb 2008, at 16:45, Bernie Hoeneisen wrote:
> Dear Authors of RFC3761bis
>
> I briefly went through the I-D and can provide you with the following
> feedback:
>
>
> * Add "Obsoletes RFC 3761" to the header of the I-D
>
>
> * ABNF
>
> You have extended the ABNF for type and subtype by a dash "-"  
> character.
>
>        type          = 1*32(ALPHA / DIGIT / "-")
>        subtype       = 1*32(ALPHA / DIGIT / "-")
>
> I guess the intension was to allow the "X-", which was somewhat
> inconsistent in RFC 3761.
>
> Do you intend to allow "-" everywhere in the Type and Subtype strings?
>
> I'd rather restrict it to "-" only as the 2nd character and only if  
> the
> prefix containing a "-" as 2nd charater is defined/described in an  
> RFC.
>
> This could be reached by:
>
> - Write some text to permit "-" only as 2nd character, and/or
> - Restrict this in the ABNF such as
>
>    [sub]type = ALPHA (ALPHA / DIGIT / "-" )  1*30 ( ALPHA / DIGIT )
>
>    Note: This proposal would also disallow a digit as the 1st  
> character.
>
>
> What do you think about?
>
> cheers,
>   Bernie
> _______________________________________________
> enum mailing list
> [email protected]
> http://www.ietf.org/mailman/listinfo/enum