Re: [apps-discuss] APPSDIR review of draft-gregorio-uritemplate-07

[Frank Ellermann <[e-mail]>]

On 7 December 2011 04:18, Jiankang YAO <[e-mail]> wrote:

> Major issues:
> 1) In section 1.5.  Notational Conventions

> There is a repetition of definition of ALPHA, DIGIT, HEXDIG,......

> There is a discussion in IETF: we should not give the repetition of
> definition of ABNF syntax if we can refer it to other documents. The
> reason is that repetition may bring the errors or misunderstanding.

Well, we're not supposed to "redefine" terms unless we really want it,
but I fear that your suggestion misses another important point:

> for example, we just say "ALPHA, DIGIT are imported from RFC5234"

If you write that only in prose Bill's syntax checker would flag the
terms as "undefined".  IMO the best way for imports is something in
the direction of

   ALPHA = <ASCII letters as specified in appendix X of RFC 5234>

Or similar, it's an editorial nit, and not really a major issue here,
after all this draft doesn't try to redefine any STD 68 terms ;-)

> 3)Normative reference [1] points to
> <http://lists.w3.org/Archives/Public/uri/> which is maillist archive
> and can not be Normative.

LOL, yes, that is an xml2rfc artefact, at some point it tries to dump
all pending URI references.  AFAIK the authors intend to add three or
more missing informative references, that should also take care of the
discussion list URI.  Using <eref ... /> might also help to get rid of
this non-normative oddity.

> Discussion issues:
> 1)No IANA actions are required by this document.

> comments or suggestions: I suggest something in the document to be
> added to IANA, for example,the operators in section 2 and 3 of this
> document.
> If we register these operators in IANA, it will help the future use
> of these operators/characters.

IMHO IANA registries should only be created when they are required,
and if they are (supposed to be) helpful.  That's not the case here,
all used operator characters are fully specified, and all remaining
potential operator characters are enumerated:  It is the job of any
later draft to create a registry if the "KISS" approach (= complete
enumeration in one memo) does not more work.

> 1) "after UTF-8 encoding" in the first paragraph In section 1.2
> Levels and Expression Types need a reference to UTF-8

For some reasons major parts of the terminology ended up in 1.5 and
1.6 _after_ some preliminary uses in 1.2 ... 1.4.  Normally the
order of 1.x sections in a draft is no issue, but here 1.2 is rather
long; hopefully the order can be rearranged, or improved by forward
references.

> 3) In the 4th paragraph of section 1.6, Normalization Form C needs
> a reference.

The given reference UAX #15 is good enough for my purposes, this is
no draft where a reference to RFC 5198 would be clearer.  YMMV, and
<http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt>
lists "UTF-8" as a well-known term, but does not yet star "NFC".

-Frank