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

John C Klensin klensin at jck.com
Sat Sep 13 00:07:00 CEST 2008


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

(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



More information about the Idna-update mailing list