Implementation questions (digressing from...)

[John C Klensin]

I basically agree with Andrew, but let me add two observations...

In terms of making requirements, there are actually four
separate things we can do.  As usual, I encourage people to be
clear about what they are talking about.

	(1) Protocol requirements that are verified at lookup
	time.  We can assume that these will be followed
	because, if they are not, the labels will often be
	rejected on lookup.  It is reasonable to assume that no
	one rational will want to put names in the DNS that
	cannot be consistently looked up (unless they have
	nefarious purposes and cooperating software, in which
	case... well, nothing the IETF can do will stop them).
	
	(2) Protocol requirements on registration that show up
	on the wire and that could be verified by examining the
	strings that are registered, even if we do not require
	that.
	
	These first two are inherently global -- we can't
	specify something for one zone, or one implementation or
	application, and not another.
	
	(3) Recommendations to registries/ zone administrators.
	In principle, these can take either the form of "you
	should do things this way unless you have some reason
	not to" or "this is an issue you should consider, with
	some possible alternatives including...".  In practice,
	there may not be much difference.  And, if we don't
	explain why whatever we suggest is important (especially
	if the alternative might be easier or more profitable),
	the odds of being ignored are pretty high.
	
	(4) Recommendations to application implementers.  In
	principle, that issues and options here are identical to
	those above, but the audience is different and may
	behave differently.

Second, if I were a gTLD that had accepted IDNA-based
registrations some of which might have started out as Eszett,
and especially if I had made no effort to record the language in
which the label had supposedly been registered (note that there
would not be even a hint of a requirement for that if the only
non-ASCII character in the original string was the Eszett), I
might seriously consider simply prohibiting registrations of
labels with Eszett in them.  The registry should have that
option; if I remember the note that Marcos sent us about the
DENIC position, part of the intent was precisely to create that
option.  As Rationale tries to explain, a relevant registry
would actually have a whole series of options, including:

	(i) Ban Eszett
	
	(ii) Create a pseudo-sunrise period in which anyone who
	had a Latin-character label with the sequence "ss" in it
	got early priority (and perhaps other preferences) for
	registering the same label with Eszett.
	
	(iii) Try to sort out a variant model for anyone coming
	forward with a proposed registration involving Eszett.
	
	(iv) Punt the problem and not worry about it.

While I'm not enthused about (iv), my impression is that
top-level, and nearly-top-level registries (which are probably
not typical of registries for zones deeper in the tree) have, in
situations that are at least somewhat similar, tended to prefer
(ii) and (iv) to (i) and (i) to (iii).   I hope that changes,
but telling people what they have to do because of my/our
preferences really isn't going to get us anywhere.

   john


--On Tuesday, 23 December, 2008 18:05 -0500 Andrew Sullivan
<ajs at shinkuro.com> wrote:

> On Tue, Dec 23, 2008 at 02:51:05PM -0800, Mark Davis wrote:
>> Half of what the protocol does is impose requirements on
>> registries. Are you saying that we should remove those?
> 
> I don't think I fully understand that claim.  In some trivial
> sense, of course it imposes requirements on registries.  But
> the protocol goes out of its way so far to avoid making any
> policy decisions for registries about which code points they
> should permit from the entire set of allowable ones, and from
> making any policy decisions about which things must be treated
> as equivalent.
>...