[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] requirements-05
- To: idn@ops.ietf.org
- Subject: [idn] requirements-05
- From: John C Klensin <klensin@jck.com>
- Date: Tue, 01 May 2001 11:51:16 -0400
- Delivery-date: Tue, 01 May 2001 08:52:35 -0700
- Envelope-to: idn-data@psg.com
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.