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

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

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