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

["Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>]

[This message contains responses to Kent Karlsson, Marc Blanchet, and
Paul Hoffman.]

Kent Karlsson <kentk@md.chalmers.se> wrote:

>  "...SHOULD show the name in ACE format... This is to make is to make
>  it easier to transfer the name correctly to other programs"; cut and
>  paste works very well also for strings that contain characters not
>  in the font used at the moment, using an ACE display will be more of
>  problem than help.

It depends on the platform and the GUI.  Sometimes copy/paste retrieves
a string from the application, but sometimes it just retrieves a string
from the GUI corresponding to exactly what is displayed.  Maybe the
language in the draft should be sensitive to this.

> There should be opening for transition to a long-term non-ACE solution
> (probably based on UTF-8).

The draft already says:

    If a signalling system which makes negotiation possible between old
    and new DNS clients and servers is standardized in the future, the
    encoding of the query in the DNS protocol itself can be changed from
    ACE to something else, such as UTF-8.

> The ACE based solution should be explicitly declared to be short-term.

No, because the draft then says:

    The question whether or not this should be used is, however, a
    separate problem and is not discussed in this memo.

Marc Blanchet <Marc.Blanchet@viagenie.qc.ca> wrote:

> > How about "Punycode: An encoding of Unicode for use with IDNA"?
> 
> I would expand the IDNA word (even if it costs extra bits...). 

Okay.

> 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.

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.  For example, I might make stylistic changes or add comments
or slightly change the interface.  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.

> 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.

> 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.

> 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

Paul Hoffman / IMC <phoffman@imc.org> wrote:

> Then you should say next to the version number what that version
> number is for. "This is code version foo, which matches Punycode
> specification version bar."

Okay, I'll make that more clear.

AMC