[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] requirements-05
- To: "John C Klensin" <klensin@jck.com>, <idn@ops.ietf.org>,"Zita Wenzel" <zita@isi.edu>
- Subject: Re: [idn] requirements-05
- From: "James Seng/Personal" <James@Seng.cc>
- Date: Tue, 8 May 2001 12:43:00 +0800
- Delivery-date: Mon, 07 May 2001 21:44:48 -0700
- Envelope-to: idn-data@psg.com
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.
>
>
>