RE: [Enum] review of draft-ietf-enum-cnam-01.txt

["Richard Shockey" <richard at shockey.us>]

Excellent ..this is most helpful. I have to admit I'm vacillating on the
compound registration ..I'm thinking PSTN:CNAM is enough. It creates less
confusion.


Now here we go around again on the URI type. I need to do one more consult
on this. I should just ask Klensin .. 


> -----Original Message-----
> From: Alexander Mayrhofer [mailto:alexander.mayrhofer at enum.at]
> Sent: Monday, May 29, 2006 7:25 AM
> To: enum at ietf.org; Richard Shockey; Livingood, Jason;
> kmccandless at verisign.com; mmaharashi at verisign.com
> Subject: [Enum] review of draft-ietf-enum-cnam-01.txt
> 
> 
> I have the impression that this is an interesting service, especially
> considering the recent advances in infrastructure ENUM. However, i think
> that the document still needs some work - comments follow:
> 
> - NITS: the online idnitsw checker reports two problems:
>   - page breaks (pages don't break properly)
>   - usage of FQDNs which are not "example.(com|net.org)"
>   (and a few experimental warnings)
> 
> - Abstract: typo ("compound subtypes subtype" should probably read
> "compound
> subtype")
> 
> [general note: if we start with sub-subtyping, we should definitely add
> some
> text about this to the enumservices-guide. I smell confusion here about
> the
> difference between those "compound subtypes" and "various subtypes per
> type"
> see below for more confusion potential]
> 
> - ToC: The document should be structured a bit more. I think the
> "Structure
> of CNAM data" should be moved before the Enumservice Registration (the ToC
> contains even 2 sections starting with "IANA Enumservice Registration": 3.
> and 5.), and the Examples could be grouped unter one "examples" section.
> 
> - Minor formatting issues: Personally, i'd prefer to have eg. the media
> type
> always surrounded by single quotes (eg. at the end of the first sentence
> of
> the abstract, i got confused whether the first of the two dots is to be
> part
> of the media type...). Same applies to Enumservice types, subtypes,
> parameter names, parameter values
> 
> - Section 3: I disagree with the second sentence of the second paragraph:
> The subtype does not neccessarily define the URI scheme - if it is
> supposed
> to, we should add text to the enumservices guide, again. What's the value
> of
> the second paragraph, anyway? The third sentence is confusing to me -
> could
> probably be changed to "This document specifies the compound subtype
> 'cnam:data' for the 'pstn' Enumservice type, using the 'data:' URI scheme
> as
> specified in RFC 2397" (imho, that does also reflect in a better way that
> there might be more 'pstn' type services than specified in this document).
> 
> - Section 4: This specifies the length of "Caller Display Name" to 15
> digits, and calls it "CNAM Data" in the section title. However, later in
> the
> document, the contents of the data-URI is recommended to be shorter than
> 64
> digits. Therefore, there is a definition clash what "CNAM data" is - is it
> the "Caller Display Name" as defined in the PSTN, or is it the contents of
> the URI? Especially with section 6, which specifies a different format for
> "structure of CNAM data" - probably that should be renamed to "structure
> of
> CNAM data URI" or something like this...
> 
> - Section 5: I'm curious how to handle the "compound" subtyping here.
> That's
> obviously beyond the limit of the RFC3761 template (eg. it's not
> completely
> clear to me whether this registration would allow only
> "E2U+pstn:cnam:data",
> or also "E2U+pstn:data:cnam";, or even just "E2U+pstn:cnam" and
> "E2U+pstn:data"...
> 
> - Section 6: I don't think that the ABNF of the "data:"; URI adds any value
> here (btw, the normative reference to ABNF is missing). However, an ABNF
> of
> a valid "application/cnam" URI would definitely add value here (which
> means
> fixing the media type, and proably add a length limit to the data itself).
> That would also provide a definition of a "CNAM data URI", which could be
> used to distinguish NAPTR payload from the "Caller Name Display" type of
> definition (as mentioned above).
> 
> I'm thinking whether "text/cnam" instead of "application/cnam" would fit
> better, because RFC4288 says:
> 
> ---
> 4.2.1.  Text Media Types
> 
>    The "text" media type is intended for sending material that is
>    principally textual in form.
> ---
> 
> [which would definitely apply to the CNAM data, and would be shorter as
> well]
> 
> - Section 6: There are a couple of "looks like a reference" words in the
> text, like the "[R3-50]" - the "GR-1180" needs to be referenced, at least
> i
> have no clue what that should be.
> 
> - Section 6: The definition of the parameter "unavailable" is confusing.
> It's defined as "required" here, but doesn't show up in the first example
> in
> section 8. In addition, the "options" defined here seem to be "parameter
> values" for the "unavailable" parameter - terminology problem. A sentence
> that no other parameter values for unavailable as well as no other
> parameters are allowed could be added, and the parameter definition could
> be
> provided in ABNF (and referenced in the ABNF above).
> 
> Generally, i'd go for a section like
> 
> x. The 'CNAM' data URI
> x.1 Formal Definition
> (abnf)
> x.2 Media Type Definition 'application/cnam'
> (type)
> x.3 Media Type Parameter 'unavailable'
> (parameter def)
> 
> - Section 7: [PII] looks like a reference to me, although it's an
> abbreviation, and it's only used once (in the next sentence)
> 
> - Section 8: The FQDNs are not recommended example domains
> (example.(com|net|org). I'm well aware that those domain names should
> reflect private DNS trees - however, idnits complains ;) - Unsure what to
> do: probably use "private.example.com"?
> 
> - Section 9: Could be renamed to "Example Call Flow". Unsure what the
> "Dialed number" string before the list should mean.
> -- In bullet c), should the "user=" SIP URI parameter really include
> "SBC.cox.net"? What about the "SBC1.cox.net" in the next line - should be
> removed. Bullet d) again contains the "example." TLD...
> -- Bullet e) I think the originating users' phone number does not
> neccessarily come from the From: field - P-Asserted-Identity comes to my
> mind...
> -- Bullet f) still talks about "tel-URI containing CNAM data" - remains of
> the first version...
> 
> - Section 10. proxy's -> proxies - The only sentence in this section is
> incomplete & confusing.
> 
> - Section 14: the definition of parameters / values is confusing.
> "unavailable" seems to be an optional _parameter_, while "p" and "u" seem
> to
> be _parameter values_ to that parameter. There is a bug around line 6 of
> page 8 - i think that sentence should read "This parameter .... defined as
> data is NOT available for that ..." ("NOT" is missing). Interobability
> considerations: I'm pretty sure that usage of this media type is _not_
> specified in RFC3761 - that should be changed into a placeholder for the
> memo itself (eg. RFC XXXX). There is a typo in the last sentence of the
> section ("enum at ierf.org" should read "enum at ietf.org").
> 
> - Section 15: Add a reference to the media type definition to the last
> sentence.
> 
> There are a lot of Abbreviations in the draft that are never expanded -
> "SIP", "NAPTR", "NS", "VoIP", "SS7", "IPSec". Some are defined, but not on
> their first use (eg. PSTN)
> 
> So far my comments - hope that helps.
> 
> cheers
> 
> Alex
> 
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www1.ietf.org/mailman/listinfo/enum


_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum