Re: Proposed resolution of HRRI/IRI discussion

Hello Henry, others,

I'm extremely sorry for the long delay in answering your message.

As Addison has already told you, I think that your proposal goes
exactly in the right direction and I have been working
on integrating it into the iri-bis draft.

Please note that I'm cc'ing the public-iri list because
that's where the technical discussion should go.

I just have submitted draft-duerst-iri-bis-01.txt, which is available
e.g. at http://www.ietf.org/internet-drafts/draft-duerst-iri-bis-01.txt.

I created a whole new section for "Legacy Extended IRIs", Section 7.
I adopted your name, which is fine with me, and much of your text.
However, I reorganized the material a bit, creating a section
that deals strictly with the syntax definition (7.1), a short
section on conversion (7.2), and rather long section discussing each
of the character groups that are allowed in Legacy Extended IRIs,
but not in IRIs, including the problems these characters may create.
(I just noticed that the bullet points for that list are missing,
I'll fix that the next time round).

I'd appreciate any and all comments, from the XML Core WG and otherwise,
on this new section and otherwise. Please note that the more comments
we get, the sooner we can be sure that the updates we did are about right.

I'll also meet my co-author, Michel Suignard, at the Internationalization
and Unicode Conference this Wednesday, so we will be able to discuss
and hopefully incorporate any comments that we get by Wednesday.

Regards,   Martni.


At 01:36 07/08/30, Henry S. Thompson wrote:
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>We would like to suggest that the best way to move forward with our
>effort to reconcile the differences between the way in which various
>specifications in the XML family allow a superset of IRIs, and the
>IRI spec. itself, would be to incorporate a new section in the
>revision of the IRI spec. that you are currently working on, which
>would name and define a single concept to be referenced from all
>those XML specs, along the following lines:
>
>Name (negotiable): Legacy Extended IRIs (LEIRIs)
>
>Definition (based on [1], with subsequent additions):
>
> A Legacy Extended International Resource Identifier (LEIRI) is a
> sequence of Unicode characters that can be converted into an IRI by
> the application of a few simple encoding rules.
>
> To convert a Legacy Extended International Resource Identifier to
> an IRI reference, the following characters MUST be percent encoded
> by applying steps 2.1 to 2.3 of Section 3.1:
>
>  * space #x20
>  * the delimiters "<" #x3C, ">" #x3E, and '"' #x22
>  * the unwise characters "{" #x7B, "}" #x7D, "|" #x7C, "\" #x5C,
>    "^" #x5E, and "`" #x60
>  * The 'unreasonable' characters:
>
>               #x0  - #x1F |         /* C0 controls */
>               #x7F - #x9F |         /* DEL and C1 controls */
>               #x200E | #x200F | #x202A-E /* Bidi formatting characters */
>               #xE000 - #xF8FF |     /* private use */
>               #xFDD0 - #xFDEF |     /* non-characters */
>               #x1FFFE - #x1FFFF |   /* non-characters */
>               [similar lines for every planes from 2 -- F]
>               #x10FFFE - #x10FFFF | /* non-characters */
>               #xE0000 - #xE0FFF |   /* tags - I don't understand these */
>               #xF0000 - #xFFFFD |   /* private use */
>               #x100000 - #x10FFFD   /* private use */
>
>Health Warning: We would be happy to see some text added to warn
> against creating new LEIRIs using most or indeed almost all of the
> characters allowed by this, perhaps expanding on what is already
> present in [1]: "[A]uthors of [LEIRI]s are advised to percent
> encode space characters themselves, rather than rely on the
> processor to do so, because spaces are often used to separate
> [LEIRI]s in a sequence."
>
>Security considerations, to be added to section 8:
>
> Additional risks resulting from the additional characters allowed
> in LEIRIs include:
>
>  - Some characters may not be permitted by the context.  For
>  example, NUL characters are not allowed XML documents.
>
>  - The use of control characters and bidirectional formatting
>  characters may allow malicious users to manipulate the displayed
>  version of an LEIRI.
>
>  - Control characters and non-characters, or LEIRIs containing them,
>  may be filtered out by receivers.
>
>  - Private use characters are not interoperable and may have
>  unpredictable effects.
>
>  - Whitespace characters may be subject to normalization in certain
>  contexts.  For example, line endings in XML are normalized to LF;
>  tabs in XML attributes are converted to spaces; and sequences of
>  spaces are collapsed in tokenized XML attributes.
>
>  - Some characters may be treated as delimiters in some contexts.
>  For example, spaces are often used to separate resource
>  identifiers in a sequence, and angle brackets are often used to
>  delimit resource identifiers in text.
>
> Legacy Extended International Resource Identifiers are often converted
> to IRIs or URIs and subsequently used to provide a compact set of
> instructions for access to network resources, care must be taken to
> properly interpret the data within a Legacy Extended International
> Resource Identifier, to prevent that data from causing unintended
> access, and to avoid including data that should not be revealed in
> plain text. [this para. probably overlaps somewhat with material
> already present in section 8, it's here just as a starting point]
>
>- ---------
>
>We would expect to go ahead and publish several specs. which are
>waiting for a resolution of this issue, e.g. XML Base 2e and XLink
>1.1, once there is a stable and agreed-final Internet Draft of a new
>edition of 3987 including agreed prose along the lines given above,
>leaving the insertion of the final RFC number to subsequent errata.
>
>Please let us know what you think.
>
>Henry S. Thompson
>Richard Tobin
>on behalf of the XML Core Working Group
>
>[1] http://www.w3.org/XML/2007/04/hrri/draft-walsh-tobin-hrri-01c.html


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp     mailto:duerst@it.aoyama.ac.jp

Received on Sunday, 14 October 2007 01:23:33 UTC