Re: Agreement on IRI "processing spec" moving to W3C

--On Saturday, November 19, 2011 22:11 -0800 Chris Weber
<chris@lookout.net> wrote:

> During IETF 82 an announcement was made that the IRI
> "processing spec" would move to the W3C for creation as a
> self-contained document.  See
> <http://trac.tools.ietf.org/wg/iri/> for the minutes.
> 
> Are IRI WG members in agreement on this decision?

For whatever it is worth, I object to this decision.  

It became clear in the WG meeting (not that it wasn't before)
that one of the problems with IRIs and "the specification" is
that it becomes more and more complicated as we try to deal with
different (sometimes conflicting) objectives and assumptions
about what the specs are about.   Drawing a few examples from
the meeting discussion,...

	(i)  Are IRIs protocol elements or presentation/ display
	elements or halfway in between.  Does a real
	presentation element need to be localized sufficiently
	that it is not confusing to users who haven't been
	carefully educated about subtle rules? Do we try to
	answer that question with separate specs? 
	
	(ii) Should the domain part of a conversion to URI form
	be required to be converted to A-labels? Note that, in
	addition to the "will it work on lookup" question asked
	several times during the meeting discussion, there is an
	issue about whether it will convert, not just because of
	the mapping question (to require that IRIs use only
	unmapped or post-mapping forms, RFC 5985 with or without
	some profile, UTR 46 with or without some profile, or
	something else), there is the matter that RFC 5891/5892
	prohibits some characters and character sequences that
	are allowed by some private namespaces (and probably
	vice versa).
	
	(iii) Or should the domain part be required to be
	converted only to %-encoding-of-UTF-8 form, noting that
	those encodings freeze a particular normalization (or
	lack thereof) and _that_ can cause lookups to fail in
	environments that make different assumptions.

And, of course, none of those decisions really affect domain
names embedded in URI tails because they can be detected to be
domain names only heuristically.

While I normally believe in modularizing problems and breaking
things up into separate work items, the apparent level of the
unresolved problems, and problems still being discovered, in
this area create a serious risk that we are modularizing without
a sufficient understanding of the issues to define really clear
boundaries among modules.  By spitting the issues up into
separate documents, separate working groups, and separate
organizations, we vastly increase the odds of coming up with an
overall collection of specifications that don't quite fit
together, have serious gaps, or are otherwise inherently
non-interoperable.  I therefore believe that some fundamental
reconsideration is needed, not just additional ways to try to
slice and dice the problem.

    john

Received on Sunday, 20 November 2011 15:30:01 UTC