[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] requirements-05



Hi John,

Requirements-06 have just been submitted to incorporate your comments
here.

-James Seng

----- Original Message -----
From: "John C Klensin" <klensin@jck.com>
To: <idn@ops.ietf.org>
Sent: Tuesday, May 01, 2001 11:51 PM
Subject: [idn] requirements-05


> Marc, James, and Zita,
>
> I have just finished giving requirements-05 a careful read.  I
> suggest that it is not yet ready for the IESG, either
> substantively or editorially, although we are arguably getting
> close.  Contrary to normal practice, I'm including editorial
> comments at the bottom of this note, partially to suggest that
> few people have read it carefully.
>
> A few of these issues have already been spotted by others and
> I want to reinforce them and give the editors a more
> consolidated list.  Apologies if I have missed anything already
> noted by others.
>
>     --john
>
> ------------
>
> 1. Substantive.
>
> (i) Section 1, end of first paragraph.  I believe that it
> would be useful if the document made the "assumption" a bit
> more explicit by pointing out that there may not be consensus
> in the IETF community on that assumption and that several
> sections of the document, including the "definitions and
> conventions" are likely to be useful even if the assumption is
> false.
>
> (ii) Section 1.5, third bullet: "ip6.int" should be
> "ip6.arpa".
>
> (iii) Section 2.1, requirement [1], last sentence.  This
> statement appears to me to be inherently false.  Since
> internationalized domain names cannot be resolved (within
> existing protocols) today, it is an impossibility to require
> that any system that exists today must be able to continue
> resolving such names.
>
> (iv) Section 2.2, requirement [14].  It is not clear to me
> what this requirement means.  I believe that some of nameprep
> is intended precisely to reject some characters.  And the
> recent "testbed" introduction of registrations of dingbats and
> other symbols as domain names may call for further
> consideration of some of the related issues.  The requirement
> at least needs clarification.
>
> (v) Requirements [22] and [30] appear to me to be inconsistent
> and contradictory.  Case folding is ultimately just an
> equivalence rule.  [22] says that the equivalence rule must be
> the same globally.   [30] says that equivalence rules may
> differ by zone.  I don't think one can have it both ways.  Or,
> if I misunderstand what is intended, the text is badly in need
> of clarification.
>
> 2. Editorial
>
> (i) Section 1.1, second paragraph.  "trough" should presumably
> be "through"
>
> (ii) Section 1.2, third paragraph, last sentence.  The comma
> after "contexts" probably belongs after "document" or should
> be deleted or the sentence rewritten.
>
> (iii) Section 1.4, second bullet.  There is a missing right
> paranthesis matching the one before "listed".   And the final
> sentence should probably contain "what is being transferred",
> not "what are".
>
> (iv) Section 1.5, fourth bullet.  "who provides" should be
> "who provide" (hosts is plural) and I think "who" should be
> "which" unless those hosts are human.
>
> (v) Section 2.4.  There is no section 2.3, so this should
> probably be renumbered.
>
> (vi) There is certainly precedent for leaving this for the RFC
> Editor, but the references are not consistent about the
> ordering of author, title, rfc reference (where appropriate),
> and date.
>
>
>