[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Enum] draft-hoeneisen-e164-to-metadata-00
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: ah at TR-Sys.de |
+------------------------+--------------------------------------------+