[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Few comments on idna
-- mardi, février 12, 2002 06:47:24 +0000 "Adam M. Costello"
<idn.amc+0@nicemice.net.RemoveThisWord> wrote/a écrit:
> Marc Blanchet <Marc.Blanchet@viagenie.qc.ca> wrote:
>
>> here is few comments on idna.
>>
>> - 3. 2). "When requirements 1 and 2 both apply, requirement 1 takes
>> precedence".
>> + My understanding is the inverse: i.e. requirement 2 takes precedence.
>> I might be wrong.
>
> You are wrong. :)
>
> The ASCII form might be ugly, but software won't choke on it. The
> non-ASCII form is pretty, but some software will choke on it, and that's
> more important. So requirement 1 takes precedence. It basically says
> don't pass non-ASCII domain names to software that might choke on it.
Well, I had a hard time to clearly understand those two paragraphs.
I'll try to come up with a suggestion on writing.
>
>> - 4.1 ToASCII and 4.2 ToUnicode
>> + the algorithm should more clearly state what happens when the "Verify
>> actions" result to fail.
>
> Section 4.1 says "ToASCII fails if any step of it fails. Failure
> means that the original sequence cannot be used as a label in an IDN."
> Section 4.2 says "ToUnicode never fails. If any step fails, then the
> original input sequence is returned immediately in that step." How can
> we be any clearer?
I read those statements. But the way the steps are written, it is not clear
what to do if verification fails. There is an implicit rule in what you
wrote about the fact that you continue to the next step. I would add at the
end of all verify steps a simple sentence to make it clearer. Something
like: "If verification fails, exit".
>
>> - 6.1 Entry and display in applications.
>> "if it does, rendering the ACE SHOULD NOT be the default."
>> + we should make it clear that the prefix MUST be shown if the ACE
>> version is shown. This is probably obvious for us, but the document
>> is not clear about the fact that when "ACE" is used, it means with
>> or without the prefix.
>
> Section 2 says "The 'ACE prefix' is defined in this document to be
> a string of ASCII characters that appears at the beginning of every
> ACE label." and "The conversion of labels to and from the ACE form is
> specified in section 4.", and in section 4 ToASCII is defined in such a
> way that ACE labels always begin with the ACE prefix. Section 5 "ACE
> prefix" even gives an example:
>
> For example, the eventual ACE prefix might be the string "jk--".
> In this case, an ACE label might be "jk--r3c2a-qc902xs", where
> "r3c2a-qc902xs" is the part of the ACE label that is generated by
> the encoding steps in [PUNYCODE].
>
> I have a hard time imagining what would lead someone to think that "ACE"
> refers to the part after the prefix. But if Patrik or Paul wants to
> make an editorial change emphasizing that, I don't see what harm it
> would cause.
I tried to "forget" about my "involvement" in idn and then read the drafts
with an implementor perspective new to idn. With this twist, I found not
clear where the prefix was implied, when it was not.
>
>> - title: Punycode version 0.3.3.
>> + the title should be changed to something like punycode version 1.0.
>
> Agreed. In the next revision it will be 1.0.0.
>
>> I would also argue to have a more descriptive name in the title,
>> something like: "Punycode: an encoding designed for use iwth
>> Internationalized Domain Names (idn)."
>
> Agreed. How about "Punycode: An encoding of Unicode for use with IDNA"?
> (I think it's significant that it's for use with IDNA as opposed to IDN.
> I could expand IDNA if you like, but that would get very long.)
That would be much better at least than the current title.
I'm fine with your proposal.
However, I would expand the IDNA word (even if it costs extra bits...).
Make things more clearer.
>
>> - Annex B.
>> + to me, this is not clear if it is mandatory to implement or not. We
>> should put a clear statement about this.
>
> The introduction says "Punycode can support an optional feature
> described in appendix B", and the third (== last) paragraph of appendix
> B is "Punycode encoders and decoders are not required to support these
> annotations, and higher layers need not use them." Is that not clear
> enough? Should I add a third such statement at the beginning of the
> appendix? Or move the last paragraph to the beginning of the appendix
> (which means it would contain forward references)?
I don't know. I would probably add a sentence just after "Punycode can
support ...", something like: "However, it MUST NOT be implemented for
IDNA."
>
>> = Annex D.
>> + I would erase the first 8 lines in comments. The author is already
>> identified in the draft (author section).
>
> You would, but I wouldn't. :) The first thing most people are going to
> do with the sample code is save it to a .c file, and I want the version
> information to be kept with it, along with the URL pointing at possibly
> newer versions of the sample code.
The version will be freezed with the RFC number. i.e. the version of the
code is the RFC number.
>
>> Also the numbering of the versions is inconsistent!!!.
>
> The sample code has its own version number.
well, the draft was more interesting than that: See:
title of the draft: "Punycode version 0.3.3"
then annex D:
/*
punycode.c 0.4.0 (2001-Nov-17-Sat)
/* This is ANSI C code (C89) implementing Punycode version 0.3.x. */
How relevent to a specification is the date you made the code?
> The version numbers of both
> the spec and the sample code will become 1.0.0 in the next revision,
> but they could diverge after that. Editorial changes to the spec don't
> cause changes in the sample code. Also, an interface change in the
> sample code could cause a large jump in the sample code version (to
> 1.1.0 or 2.0.0) while causing only a small jump in the spec version (to
> 1.0.1).
Again, the version now will be the RFC number.
I think your version numbering management is all fine for yourself. I don't
think it is appropriate for an RFC.
I would suggest that you refer between your new versions of the code to the
"Punycode version RFCXXXX". And leave the RFC "clean" of your internal
numbering schemes. For example, we don't put CVS tags in RFCs, even if
they are useful for document management.
Marc.
>
> AMC
>
------------------------------------------
Marc Blanchet
Viagénie
tel: +1-418-656-9254x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------
http://www.normos.org: IETF(RFC,draft),
IANA,W3C,... standards.
------------------------------------------