Re: [idn] a few more comments on the last call documents

[Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>]

-- mardi, février 12, 2002 22:59:13 +0000 "Adam M. Costello" 
<idn.amc+0@nicemice.net.RemoveThisWord> wrote/a écrit:
>> Marc Blanchet <Marc.Blanchet@viagenie.qc.ca> wrote:
>
>> I would probably add a sentence just after "Punycode can support ...",
>> something like: "However, it MUST NOT be implemented for IDNA."
>
> A Punycode encoder/decoder that implements mixed-case annotation will
> behave exactly the same as a Punycode encoder/decoder that does not
> implement mixed-case annotation, except that the encoder can accept
> flags and the decoder can return flags.  But those flags don't alter
> the output of the encoder except for the case of ASCII letters (which
> doesn't matter for domain labels), and they don't alter the sequence of
> code points returned by the decoder at all.  So there is no reason to
> forbid the Punycode encoder/decoder from implementing this feature.

To me, we want a spec which defines clearly what has to be implemented and 
not.
This option is an optional behavior that should not be implied as to be 
implemented in order to be conformant.

I would argue again to say clearly that this option should not be 
implemented in IDNA.

>
> I will, however, add explicit language to that effect:
>
>     Mixed-case annotation MUST NOT alter the encoder output as defined
>     in section 6.3 except for affecting the case of ASCII letters, and
>     mixed-case annotation MUST NOT alter the sequence of code points
>     returned by the decoder as defined in section 6.2.
>
>> The version will be freezed with the RFC number. i.e. the version of
>> the code is the RFC number.
>
> It's possible that I might continue to develop the code after the RFC is
> published.

And others will implement the spec. So does the specific versioning of the 
code of a specific author make any sense in the context of multiple source 
codes. No.

>For example, I might make stylistic changes or add comments
> or slightly change the interface.

sure. great.

>  Those later versions of the sample
> code won't appear in an RFC, so they'll need their own version number,
> and it will be nice if the sample code in the RFC has a version number
> that can be compared with the version number in the more recent sample
> code.

again. version number of the code will be the RFC number.

>
>> 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. */
>
> What's wrong with that?  Version 0.4.0 of punycode.c implements version
> 0.3.anything of Punycode.  I can use a wildcard like that because all
> 0.3.x versions are equivalent, with only editorial differences.


I understood that you had internal versioning of your algorithm and this is 
ok.
I don't think it will be of any relevance inside an RFC.

If I implement your spec, I'll say it is compliant with RFC XXXX, not to 
the x.y.z version of your code. So your own versioning is irrelevent to the 
RFC.

>
>> How relevent to a specification is the date you made the code?
>
> It's not, but the the date is relevant to the code itself.  We are
> embedding a file inside a document, and that file contains its version
> number and date stamp.

again. it is not relevent. We are publishing a specification with sample 
code in it.

>
>> I think your version numbering management is all fine for yourself. I
>> don't think it is appropriate for an RFC.
>
> Lots of RFCs have version numbers:
>
> RFC-1950 ZLIB compressed data format specification version 3.3
> RFC-1951 DEFLATE compressed data format specification version 1.3
> RFC-1952 GZIP file format specification version 4.3
> RFC-2060 Internet Message Access Protocol - version 4rev1
> RFC-2246 The TLS protocol version 1.0
> RFC-2437 PKCS #1: RSA cryptography specifications version 2.0
> RFC-2616 Hypertext Transfer Protocol -- HTTP/1.1

yes. it is exactly my point. You could say in the title "Punycode v1.0 ...".
But the code inside it does not need to have a version number.

Marc.