Re: draft-hoeneisen-e164-to-metadata-00

Hi Alfred

Thanks a lot for your extensive feedback. As always, good catches!
It'll be incorporated to revision -01.

cheers,
  Bernie


On Tue, 13 Oct 2009, Alfred H?nes wrote:

> Bernie,
> I have quickly skimmed over your new E2M draft,
> draft-hoeneisen-e164-to-metadata-00, and have a couple of
> comments, mostly editorials / clarifications.
>
> First of all, this seems a reasonable proposal in order to keep
> the ENUM space 'clean' from the perspective of user expectations
> and client software trying to accommodate that.
> Also, the basic ideas seem to already be worked out thoroughly
> and specified in sufficient detail.
>
> Here is a linear walk-through of the text with the details
> I'd like to be addressed:
>
>
> (1)  Section 1, 2nd para (+ ff.) -- clarification, and a word omission
>
> The draft says:
>                         v
> |  Thus, ENUM can be used look up the services associated with an E.164
>   number.  However, it is controversial whether or not the result of an
> |  ENUM lookup should always result in a communications session using
>               !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>   the URI found in the corresponding Naming Authority Pointer (NAPTR)
>   [RFC3403] DNS Resource Record (RR).
>
> The expectation "should always result in a communications session"
> seems to be too strong; it even cannot be fulfilled by 'classical'
> ENUM. I suggest that either here, or in Section 1.2, or in both
> places, the related text is modified to indicate the *intent*,
> not the requirement for *success*.
>
> Also, please add the missing "to" in the 1st line.
>
> Altogether, I propose to modify the above paragraph to say:
>
>                         vvvv
> |  Thus, ENUM can be used to look up the services associated with an
>   E.164 number.  However, it is controversial whether or not the result
> |  of an ENUM lookup should always be suitable for establishing a
>                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   communications session using the URI found in the corresponding
>   Naming Authority Pointer (NAPTR) [RFC3403] DNS Resource Record (RR).
>
>
> (2)  Section 1.2
>
> (2a)  2nd para -- typo
>                                       v
> |  Another issue is that the result of a ENUM (E2U) lookup always needs
>   to be an URI, which makes otherwise simple mappings rather complex.
> ---                                    vv
> |  Another issue is that the result of an ENUM (E2U) lookup always needs
>   to be an URI, which makes otherwise simple mappings rather complex.
>
> (2b)  3rd para -- clarification, and a missing article
>
> As in (1) above, I suggest a clarification of the expectations for
> ENUM, and the addition of a missing article and typographical emphasis
> for the 'data' URI scheme, as follows:
>
>   The authors of such Enumservice proposals tried to circumvent the
> |  issues by introducing data URI scheme or inventing completely new URI
>   schemes, with limited success however.  The main objection that an
> |  ENUM lookup should always result in a communications session
>   remained.
> ---
>   The authors of such Enumservice proposals tried to circumvent the
> |  issues by introducing the 'data' URI scheme or inventing completely
>                         ^^^^^    ^
>   new URI schemes, with limited success however.  The main objection
> |  remained that an ENUM lookup should always result in a URI that can
>   ^^^^^^^^^                                            ^^^^^^^^^^^^^^
> |  be used to establish a communications session.
>   ^^^^^^^^^^^^^^^^^^^^^                        ^
>
> Here, I also have modified the word placement (which resembled German
> style :-) ) for better readability.
>
>
> (3)  Section 1.3
>
> (3a)  1st para -- grammar
>
> I suggest to resolve singular/plural issues and remove a spurious "for":
>
>   This document proposes a new Dynamic Delegation Discovery System
> |  (DDDS) [RFC3401] application E2M, which can be used with DNS NAPTR RR
>   for resolving E.164 numbers into metadata.  The resulting metadata
> |  can be used for (for example) to provide hints about properties of
>   certain ENUM domains or to provide information that can be used as
> |  attribute of an E.164 number.
> ---
>   This document proposes a new Dynamic Delegation Discovery System
>   (DDDS) [RFC3401] application E2M, which can be used with DNS NAPTR
> |  RRs for resolving E.164 numbers into metadata.  The resulting
>     ^                 v
> |  metadata can be used (for example) to provide hints about properties
>   of certain ENUM domains or to provide information that can be used as
> |  attributes of an E.164 number.
>            ^
>
> (3b)  3rd para -- extraneous word
>
> The "and" in the last line should be deleted:
>
>   As there are lots of similarities between E2M and ENUM (E2U), this
>   document generally only outlines the differences to ENUM (E2U)
>   instead of repeating all parts shared between the two.  Therefore a
>   firm understanding of ENUM [I-D.ietf-enum-3761bis] and Enumservices
> |  [I-D.ietf-enum-enumservices-guide] and is required.
> ---                                  ^^^^^
>   As there are lots of similarities between E2M and ENUM (E2U), this
>   document generally only outlines the differences to ENUM (E2U)
>   instead of repeating all parts shared between the two.  Therefore a
>   firm understanding of ENUM [I-D.ietf-enum-3761bis] and Enumservices
> |  [I-D.ietf-enum-enumservices-guide] is required.
>                                     ^
>
> (4)  Section 1.4 -- word omission
>
> Please insert the missing indefinite article in the first line:
>
> |  This is work in progress at early stage.  [...]
> ---                           vvvv
> |  This is work in progress at an early stage.  [...]
>
>
> (5)  Section 3.1 -- I18N considerations
>
> |  o  An ASCII Text string
>
> This needs clarification and justification (with regard to RFC 2277).
>
> I interpret the draft in such way that these strings are intended
> to be machine readable and suitable for consumption by automata,
> not for direct display to users.  In this case, the strings would
> be regarded as a kind of protocol elements, thus waiving the
> RFC 2277 requirements for I18N and UTF-8 support in text elements.
>
> If that perception is true, an explanation to this end should be
> inserted directly below the quoted bullet headline (you may directly
> rephrase the arguments given above).
>
> However, the indication in the 3rd para of Section 4.1.1 does not
> properly match this idea.  See the related discussion below.
>
>
> (6)  Section 3.2, last para -- inconsistency
>
> Since the main part of that section specifies the use of two different
> flags, "t" and "u", plural should be used in the first sentence:
>
> |  If this flag is not present then this rule is non-terminal.  [...]
> ---   vvvvvvvvvvvvvvvvvvvvvvvvvv
> |  If none of the above flags is present then this rule is non-terminal.
>   [...]
>
>
> (7)  Section 3.3, 1st para -- typo
>
> The single quote character in the 1st line is unmatched; please fix:
>
> |  Section '2.4.4.  Services Parameters of [I-D.ietf-enum-3761bis] is
>   replaced as follows:
> ---                                    v
> |  Section '2.4.4.  Services Parameters' of [I-D.ietf-enum-3761bis] is
>   replaced as follows:
>
>
> (8)  Section 4.1.1 -- language improvements
>
> I suggest to user "constrain" in favor of "limit" w.r.t. ABNF.
> The word "limit" is perhaps too much correlated with thinking in
> linear dimensions, number intervals, etc., and not appropriate for
> a syntax rule set expressed in ABNF.
>
> (8a)  1st para
>
> Beyond the above, the wording in the first sentence should be
> improved and "of" should be inserted after every instance of
> "Section 3.2".
>
> Furthermore, in the last sentence a better distinction should be
> made between ABNF rules and the possible instances of text allowed
> (or "produced") by them; "a subset" of the ABNF is very different
> from "a subset of the strings allowed by the ABNF", and the latter
> is indeed meant here (I hope!).
> I try to fix this below, but feel free to find other suitable words.
>
> In total, I suggest to change this paragraph as follows:
>
> |  The ABNF [RFC5234] to limit the ASCII Text string the E2M service
>   resolves.  The 'Substitution Expression Syntax' is specified in
> |  Section 3.2 [RFC3402]).  Any parts of ABNF further specified in an
>   E2M service specification override those parts of ABNF specified in
> |  Section 3.2 [RFC3402]).  However, the resulting ABNF MUST be a subset
> |  of the ABNF specified in Section 3.2 [RFC3402]).
> ---                      vvvvvvvvv                      vvvvvvvvvv
> |  The ABNF [RFC5234] to constrain the ASCII Text string to which the
>   E2M service resolves.  The 'Substitution Expression Syntax' is
> |  specified in Section 3.2 of [RFC3402]).  Any parts of ABNF further
>                           ^^^^
>   specified in an E2M service specification override those parts of
> |  ABNF specified in Section 3.2 of [RFC3402]).  However, the resulting
>                                ^^^^
> |  ABNF MUST produce a subset of the text strings produced by the ABNF
>             ^^^^^^^            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |  specified in Section 3.2 of [RFC3402]).
>                           ^^^^
>
> (8b)  2nd para
>
> Following the reasoning in (8), I recommend to adjust:
>
>   Typically only the 'repl' part of the ABNF needs to be further
>   specified.  However, in rare cases (depending on the application)
> |  also a limitation of the 'delim-char' part may be justified (see also
>   4th example below).
> ---
>   Typically only the 'repl' part of the ABNF needs to be further
>   specified.  However, in rare cases (depending on the application)
> |  also a constraint for the 'delim-char' part may be justified (see
>          ^^^^^^^^^^^^^^
>   also 4th example below).
>
>
> That's all for this moment!
>
> Kind regards,
>  Alfred H?nes.
>
> -- 
>
> +------------------------+--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
> | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
> | D-71254  Ditzingen     |  E-Mail:  [email protected]                     |
> +------------------------+--------------------------------------------+
>
>