New versions of Protocol (-04) and Rationale (-02)

Erik van der Poel erikv at google.com
Sat Sep 13 02:26:36 CEST 2008


Hi John,

Thanks for posting the new Protocol and Rationale.

5.4.  A-label Input

   If the input to this procedure appears to be an A-label (i.e., it
   starts in "xn--"), the lookup application MAY attempt to convert it
   to a U-label and apply the tests of Section 5.5 and, of course, the
   conversion of Section 5.6 to that form.  If the A-label is converted
   to a U-label then the processing specified in those two sections MUST
   yield an A-label identical to the original one.

It might be a bit clearer if the final sentence is changed to: "If the
label is converted to Unicode using the Punycode decoding algorithm,
then the processing specified in those two sections MUST be performed,
and the label MUST be rejected if the resulting label is not identical
to the original."

   Putative labels with any of the following
   characteristics MUST BE rejected prior to DNS lookup:
   [...]
   o  Labels containing code points that are shown in the permitted
      character table as requiring a contextual rule and that are
      flagged as requiring exceptional special processing on lookup
      ("CONTEXTJ" in the Tables) MUST conform to the rule, which MUST be
      present.

This item is not worded as a "characteristic" that "MUST BE rejected"
(as the introductory text says above). How about rewording it to:

Labels containing code points that are shown in the permitted
character table as requiring a contextual rule and that are flagged as
requiring exceptional special processing on lookup ("CONTEXTJ" in the
Tables) but do not conform to that rule.

One more question inline below:

On Fri, Sep 12, 2008 at 3:07 PM, John C Klensin <klensin at jck.com> wrote:
> Hi.
>
> I have concluded that I'm unlikely to see any further response
> to the questions I posed in the Issues lists on 18 August.
> There have also been no comments or discussion that indicates to
> me that the list disagrees with conclusions reached in Dublin.
> I have therefore posted new versions of Protocol and Rationale
> (these should be announced soon if not already).
>
> I ask that Vint review the discussions (or lack thereof) and
> either conclude the silence about issues on the lists with
> proposed solutions that are reflected in this drafts indicates
> that we have rough consensus or that he devise another way to
> reach and announce conclusions about rough consensus.  Once that
> is done, and any changes the process dictates have been
> identified, I will issue new (and much shorter) versions of the
> Issues lists.
>
> Two comments about things that have not been done in these
> versions of the drafts:
>
> (1) While I was initially as attracted to Andrew's
> "pre-resolution" and "post-resolution" terminology as others
> have been, I'm less happy with it upon seeing how it fits with
> the documents.  The problem is, once again, that domain names
> are used in many contexts in which there is no immediate
> expectation that they will  be resolved, so "pre-processing" and
> "post-processing" made sense but "pre-resolution" may convey the
> wrong intent.   More broadly, there is a separate discussion
> going on ("separate" as in "not on this WG's task list") about
> the proper role of alternative forms of URIs.  The bottom line
> in that discussion is that we have all sorts of URIs that are
> not expected to be resolved and that cannot be compared by
> examining targets.  If they are to be compared at all, we need
> to be thinking about canonical forms... and that means either
> A-labels or U-labels, but little or no processing that might
> involve mapping.   That discussion further reinforces the view
> in these documents: where possible, preprocessing should be
> carried out as close to the user input as possible, that
> non-canonical forms should not be passed across the network or
> stored in files, that the "A" in IDNA really means what it says,
> and so on.  (For those of you who have seen that other document,
> expect a considerably rewritten version soon.)

Is the old (current) version of that document available?

Thanks,

Erik

> (2) I have not tried to reorganize documents to try to move
> normative and definitional material out of Rationale except
> insofar as that happened as a consequence of resolving the
> Rationale/ Protocol boundary.   I've sent a note to Vint with
> recommendations as to how we might resolve those issues (one is
> the suggestion to move the definitional material into a new
> document), but am not going to start moving text, or raising
> questions on the list about what we really want to move, until
> we decide what we want to do.
>
>    --john
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>


More information about the Idna-update mailing list