[Enum] review of draft-ietf-enum-cnam-02.txt

[Alexander Mayrhofer <alexander.mayrhofer at enum.at>]

[I'm quoting my previous review because a lot of issues still apply to the
02 version - _please_ either fix them or at least comment on them]

Alexander Mayrhofer wrote:
> - 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)

The FQDNs are fixed - however, a lot of non-ASCII characters have been
introduced (´ and `), one of the pages is too long, the pages still don't
break properly. please see the online idnits checker & fix accordingly.
There are a few unused references as well.

The abstract still says "compound subtype", but the Enumservice now uses a
"common" (?) subtype.

The ToC contains two lines without section numbers - looks like a formatting
 problem. There's some "funny numbering": sub-sections "12.1" and "12.2" are
grouped under section "11", and section "12" follows those two sub-sections...

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

still applies to the media type in the abstract. i'm still confused whether
one or both of the dots are part of the media type.

"NAPTR" in the Introduction should be expanded on its first use.

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

is now section 3 and section 4 - the terminology clash still applies.
"Definition of CNAM data" does not fit "Structure of CNAM data" - so, one of
those has to be renamed.

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

still applies, but now section 4.

Section 4:
> ... 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).

The text still says twice "this parameter ..." when it actually talks about
the "options" or "values" 'p' and 'u' to the single "unavailable" URI
parameter.

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

thats still my (strictly personal, of course) opinion.

> - Section 7: [PII] looks like a reference to me, although it's an
> abbreviation, and it's only used once (in the next sentence)

(PII) would be better, since all abbreviations are in round parenthesis.

> - Section 9: Could be renamed to "Example Call Flow". Unsure what the
> "Dialed number" string before the list should mean.

the "dialed number" stuff is still there.

> -- Bullet e) I think the originating users' phone number does not
> neccessarily come from the From: field - P-Asserted-Identity comes to my mind...

still not sure - any SIP gurus?

> -- Bullet f) still talks about "tel-URI containing CNAM data" - remains of
> the first version...

still there. Breaks the whole example & makes it useless. please fix!

> - Section 10. proxy's -> proxies - The only sentence in this section is
> incomplete & confusing.

(now section 7)
still incomplete and 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").

is now section 12.2 (or, whatever). The "unavailable" parameter is still
listed as "Required parameters" in the template, but the text and examples
indicate that the parameter is optional.

The typo in the mail address still persists.

new stuff:

- DNSSEC is never expanded.
- Section 11. refers to section 13 and 14, which don't exist.

cheers

Alex


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