Internationalized Resource Identifiers (IRIs)
RFC 3987

Received changes through RFC Editor sync (changed abstract to 'This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources.

The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.')

[Ballot discuss]
There are many, many ways to represent the same resource.  Which will
  lead to authentication problems.  Consider the case where an IRI is
  placed in a certificate as a subjectAltName, and then a client needs
  to compare the IRI in the certificate and one received via another
  means.  The other means could be a field in a protocol or it could be
  typed by a human.  The client software needs to  compare them to make
  an authentication decision.  Yet, the same resource can be represented
  by several different octet strings.  The discussion in section 5 of the
  document convinces me that there is going to be a huge problem.

  In the "Uniform Resource Identifier (URI): Generic Syntax" document
  (draft-fielding-uri-rfc2396bis-07) there is a long discussion of
  normalization and comparison.  The discussion in that document
  recognizes that comparison is performed in respect to some
  particular purpose, and thus implementations select different
  places in a spectrum of trade-offs with respect to the amount of
  effort that will be spent in reducing aliased identifiers.  In
  security terms, this relates to the probability of false positives
  and the probability of false negatives that are acceptable.

  False positives and false negatives are both bad.  But, I believe that
  the current lack of guidance will make matters much worse.  It will
  lead to inconsistent behavior.  Without more guidance, different
  people employ their own approaches to avoid false positives and false
  negatives.  This will lead to different access decisions when different
  clients are used.  To avoid this situation, I belive that a spectrum
  of normalization and comparison approaches needs to be specified, as
  was done for URIs.  In this way, each specification that makes use of
  IRIs can state the place on the spectrum that is appropriate for the
  context.  We cannot expect each specification that makes use of IRIs
  to define normalization and comparison rules, so I think it needs to
  be added to this document.

[Ballot comment]
Reviewed by Brian Carpenter, Gen-ART

His review:

OK, but should it be PS or Experimental?

This document is trying to solve a very hard problem,
I18N of URIs. I don't know whether there is running code
and early deployment - if not, going straight to PS
without a pause at Experimental might be rather courageous.
There are some very complex issues (normalization, bi-di)
and without running code, it is hard to assert that everything
is correct.

That said, the draft seems to be complete and almost nit-free:

>  There are 187 instances of too long lines in the document,  -- the
> longest one being 1 character in excess of 72.
>  Warnings:
>    Line 795 has weird spacing: '...ace and  stron...'
>    Line 1213 has weird spacing: '...include  non-A...'

[Ballot discuss]
I have what is purely a question-type discuss on this document...

In the representation of IPv6 addresses, I am not sure how/if a scope ID would be included.  A scope ID is typically represented as an integer appended to an IP address with a % used as a delimiter.  An example would be:

fe80::1234%1

How would this be represented in the IRI syntax?

Thanks.

In w3c-IETF conference call, it was agreed that this document depended to heavily on the updated
URI spec to go forward in advance of that spec.  The author recommends that it go forward
concurrently.  An action item to determine the approximate date of the URI spec's advancement was
taken; if this date is very far in the future, more work to determine how to proceed will be needed.