Subject: Re: [Enum] Last Call: draft-ietf-enum-cnam (IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for URI type 'pstndata' URI type 'pstn') to Proposed Standard

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 12 Nov 2007 09:26:58 +0000

> 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.

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

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

* 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.]

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

* Normative reference required to RFC 4234.

* In 5.1, cnam is not a media type.

* Section 6 paragraph 2: delete the words "in such a way that it may not
pass over that country's national borders". That is just one example of a
restriction and is not worthy of being separated out.

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

* The examples use an unregistered enumservice type.

* Do you have permission from the assignee of +1 505 212 1111 to use it in
these documents? [Not a petty comment: see the document's own discussions
of privacy.]

* Section 8 paragraph 1: this is a North-American-centric comment. Such
data is delivered before the first ring. [Plus: "first silent interval" is
an ambiguous term with ringing cadences other than those used in NA.]

* Sections 6 and 9 are inconsistent in their treatment of e164.arpa. In the
former case, should "should not" be "SHOULD NOT"?

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 12 Nov 2007 07:58:07 -0500

> -----Original Message-----
> From: Clive D.W. Feather [mailto:[email-masked]] 
> Sent: Monday, November 12, 2007 4:27 AM
> To: [email-masked]
> 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
> 
> I don't seem to have seen much discussion on this, but it's 
> clear to me that it is nowhere near ready.
> 

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.

> 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-

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 12 Nov 2007 17:04:57 +0000

> deprecate use of the data: URI.

Hmm. Can you point me at any documentation for this? [I've been looking at
the data: URI in other contexts.]

> Section 11.2 describes where it came from.

That gives me the syntax. But why would I provide one? Why is the caller
name for +1 703 555 0100 tied to a URI mentioning +1 505 212 1111? What is
going on?

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

Um, aren't you confusing it with the 15 digit limit for numbers (excluding
the international access code)?

> ;charset=us-ascii,Francois%20Audet

Yes, that would seem to be correct.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 12 Nov 2007 12:38:08 -0500

> Sent: Monday, November 12, 2007 12:05 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Hmm. Can you point me at any documentation for this? [I've 
> been looking at the data: URI in other contexts.]

Rich had the exchange with Jon.  He'll have to provide that info.  Older
versions of the ID (available in the usual places) will confirm the
change over time, though.

> That gives me the syntax. But why would I provide one? Why is 
> the caller name for +1 703 555 0100 tied to a URI mentioning 
> +1 505 212 1111? What is going on?

More for Rich et al.  I just devised the syntax. ;-)

> one - has 
> >> anyone checked this specification against ETSI standards? 
> [Don't ask 
> >> me: I'm not familiar enough with them.]
> Um, aren't you confusing it with the 15 digit limit for 
> numbers (excluding the international access code)?

Could be.  I always thought that the text in section 5 was referring to
E.164's limit, but I could be wrong.

-Scott-

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Nov 2007 13:48:18 -0500

> the data: URI in other contexts.]

Yes, I would also like info on that. What is the story?

	Thanks,
	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 13 Nov 2007 13:31:41 -0500

Don't ask us, ask the AD's we are just poor working stiffs doing what we're
told...

The new URI scheme was the path of least resistance for everyone concerned.

>  From: Paul Kyzivat [mailto:[email-masked]]
>  Sent: Monday, November 12, 2007 1:48 PM
>  To: Clive D.W. Feather
>  Cc: [email-masked]; Hollenbeck, Scott; Jon Peterson
>  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
>  
>  
>