comments on mappings

[Andrew Sullivan]

Dear colleagues,

Yesterday I spent some time with the current documents.  I read
carefully everything that's been updated since the last meeting.  This
is the first of the reviews of these documents.  Others will follow
under separate cover.

I'll send nits directly to the appropriate editors.

I have reviewed draft-ietf-idnabis-mappings-01.  

In general, I think the document is in reasonably good shape.  I was
hoping, however, for it to have some advice to registries on what sort
of considerations are worth taking into account when formulating
policies around what will and will not be registered.

In particular, I think it would be very helpful to outline what it
would mean for characters to be possibly mappable, and also to outline
the different strategies that are available for preventing different
alternative mappings from ending up with a different resolution.

The basic advice is that registries should try to detect whether a
candidate label may be expected to be the result of some (plausible)
application of a mapping appropriate in the probable user community,
and similarly that when faced with a candidate IDN, registries should
consider the probable user community and consider the plausible
applications of mappings appropriate to that community.  If the
registry does not have the expertise to evaluate the probable user
community for a given code point, then it should simply reject the
code point outright.  (This is, in effect, the advice that you should
have a policy, it should be a policy based on knowledge of the use
cases, and that it should default closed.)

After the registry has detected whether the candidate label, there
are two basic strategies it might follow:

    1.  Detect and reserve. 

In this case, the registry detects potential mappings, and reserves
other candidate labels that might be the result of such mappings.
This reservation takes the form of preventing registration of that
label.

    2.  Detect and bundle

In this case, the registry detects the potential mappings, and creates
identical entries in the registry conforming to those "alternative
forms" of the candidate label.  There is the potential for a very
large number of these bundled labels.

Thoughts on adding this?

There's also a great deal of material at the end of rationale that
would be more appropriate in this document (or else it should just go
away, I think).

Best regards,

Andrew

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.