IRI: a status report

Dear WG,

Now that we've been chartered and have chairs (plus at least one editor), Marc and I would like to address where we are at, what we expect the WG to accomplish, the timeline, and other details of our working group's business.

Firstly, it is important to read and understand our charter:

   http://tools.ietf.org/wg/iri/charters

This document defines our deliverables and generally functions as a guide to the chairs as to whether some conversation, thread, or activity is in or out of scope. It will also help serve to define success.

It always best to focus working group efforts, to the extent possible, on the documents we wish to produce and the prose inside them, rather than on other topics or "meta-conversations" about our activities. The chairs will use the tracker tool to track issues and emerging consensus.

When corresponding with this WG, such as when replying to this message, please be aware of list etiquette. In particular:

- avoid cross posting to other lists
- re-title when changing topics
- reply to separate issues in separate messages
- user tracker ids wherever possible

We do recognize that there exists some variance in opinion about how best to accomplish our task or what the scope should be, so some "meta-conversation" about URI vs. IRI, about specific tasks or requirements that we might need/want/desire to accomplish, or about things we wish strenuously to NOT accomplish will be permitted. Please strive to relate those conversations to the task at hand and the documents in question.

What is the task at hand?

One might argue that a basic assumption behind our charter (but not stated in it) appears to be:

--
IRIs should replace with URIs as the basic resource identifier syntax for the Internet, even if [some|many] protocols and document formats continue to use URI.
--

Is this a valid assertion?

Some of the issues we must reflect upon include:

- Today, IRIs are generally not suited to direct processing (such as path resolution, comparison, etc.) and are not used directly in protocols; URIs are processed directly. This may mean that there is a requirement that conversion, comparison, and mapping between IRI-URI be well-defined, seamless, and potentially idempotent. This is not the case currently and specifications that use IRI must deal with this imprecision.

- Several flavors of not-quite-IRI-identifiers exist. What should happen with these? How are these mapped to IRI?

- Different aspects of Unicode, such as bidirectional scripts, combining marks, and compatibility characters might affect how IRIs are processed, converted, or displayed and may present various security exploits. How should each of these cases be addressed? Have we enumerated all of the cases?

We have set an aggressive schedule: indeed, we are supposed to be finished. Let us work as rapidly as possible to scope our project and produce the necessary drafts.

(for the chairs)

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.

Received on Saturday, 15 May 2010 20:25:27 UTC