RE: Last Call: draft-ietf-enum-cnam (IANA Registration for anEnumservice Calling Name Delivery (CNAM) Information and IANARegistration for URI type 'pstndata' URI type 'pstn') toProposed Standard

> -----Original Message-----
> From: Clive D.W. Feather [mailto:[email protected]] 
> Sent: Monday, November 12, 2007 4:27 AM
> To: [email protected]
> Subject: Re: [Enum] Last Call: draft-ietf-enum-cnam (IANA 
> Registration for anEnumservice Calling Name Delivery (CNAM) 
> Information and IANARegistration for URI type 'pstndata' URI 
> type 'pstn') toProposed Standard
> 
> > The IESG has received a request from the Telephone Number Mapping WG
> > (enum) to consider the following document:
> 
> > - 'IANA Registration for an Enumservice Calling Name 
> Delivery (CNAM) 
> >    Information and IANA Registration for URI type 
> 'pstndata' URI type 
> >    'pstn' '
> >    <draft-ietf-enum-cnam-07.txt> as a Proposed Standard
> 
> I don't seem to have seen much discussion on this, but it's 
> clear to me that it is nowhere near ready.
> 
> * Is the URI type 'pstndata' or 'pstn'? Both are used in the document.

I'll have to let one of the other authors answer some of your questions.
I produced the ABNF for the URI scheme, though, so I can answer
questions about that.  In several cases it looks the document editor and
the authors got their lines crossed.

The ENUM service type is "pstn".  The URI scheme name is "pstndata".  It
looks like the examples need to be fixed to correct the service type.

> * Why is there a need for a new URI type rather than just 
> having a data:
> URI with appropriate contents?

The data: URI was the original proposal.  The reviewing AD (Jon)
mandated a change.  Apparently there is some desire within the IESG to
deprecate use of the data: URI.

> * What are the semantics of <telephone-subscriber> in a URI? 
> The examples in section 7 leave it completely confusing.

Section 11.2 describes where it came from.  The ABNF spec in section 5
should probably be removed and replaced with a forward reference to
section 11.

> * I believe the 15 character limit may be a North American 
> one - has anyone checked this specification against ETSI 
> standards? [Don't ask me: I'm not familiar enough with them.]

That's not a North American limit.  It's described in ITU-T spec E.164.

> * Several parts of the document misspell "available" 
> (including, more than once, spelling it "unavailable").

That's not always a misspelling, it's occasionally multi-version
confusion that should be cleared up with a consistency check.  The ABNF
is correct.

[snip]

> * Section 7: the first two examples cannot be generated from the ABNF.

Looking at them again I believe there's a ";" missing:

pstndata:cnam/+15052121111;;charset=us-ascii,Francois%20Audet

should be syntactically valid.  content =
;charset=us-ascii,Francois%20Audet

(mediatype type/subtype is optional and not provided. ;charset=us-ascii
is a parameter, but it needs to be preceded with a ";").

-Scott-