Re: Transition Request: (2nd) PER Request for XML Base Second Edition

Hello Chris, others,

At 23:05 08/03/13, John Cowan wrote:
>Disclaimer:  I don't speak *for* the Core WG, just as a member of it.
>
>Chris Lilley scripsit:
>
>> What is the timescape for RFC 3987bis? I see its at draft 2
>> http://www.ietf.org/internet-drafts/draft-duerst-iri-bis-02.txt
>> published 18 Dec 2007. When is it expected to become an RFC? I assume
>> (given the wording above) that this is not expected to happen before
>> 30 June, but how long after that?
>
>RFCs are subject to an unpredictable delay between the time they are
>approved and the time they are published with an RFC number, typically
>months.  Nothing can be done about this.

That delay has become a bit shorter recently. There are other delays:
- Time needed for discussion and authoring
- Time needed for review and testing (including IETF last call)
(help with all the above very much appreciated!)

In addition, there are some inponderables with respect to the relationship
between IDNs and IRIs. The IETF is most probably going to form a new IDN
WG. This WG may finish very soon, or not so soon. It affects IRIs at least
with respect to bidi, where there are some obivous fixes needed. If the
current approach is followed, the IRI spec also may need a bit more wording
on what exactly it accepts as a legal IDN and what not.


>> Should specifications that currently use IRI in XML specify LEIRI instead?
>
>No.  The "L" in "LEIRI" stands for "Legacy"; the LEIRI definition
>simply collects under one roof the existing anything-goes definitions
>of URI-like objects in older specs (XML 1.0 system identifiers, XLinks,
>XML Schema anyURIs, etc.)

Very much NO indeed.

The following two conditions both have to be met before you should consider
using LEIRIs:

1) Your spec currently uses a circumscriptive definition of (LE)IRIs such
   as the one used for system identifiers in the current XML spec
   (http://www.w3.org/TR/2006/REC-xml-20060816/#sec-external-ent)
   rather than using a reference to RFC 3987. So there is no need for
   LEIRIs in new specs.

2) Despite the fact that the chance for (LE)IRIs with such characters
   actually existing out there (except for testing or to prove a point)
   is extremely low, you can absolutely, positively not risk the chance
   to exclude them with an erratum or technical fix to your spec.

Also, please note that even if your spec should allow LEIRIs, the definition
of LEIRIs explicitly says that LEIRIs that are not IRIs should not be used.


Most of the points above are summarized in the opening part of
Section 7 of
http://www.ietf.org/internet-drafts/draft-duerst-iri-bis-02.txt:

>>>>>>>>
   For historic reasons, some formats have allowed variants of IRIs that
   are somewhat less restricted in syntax.  This section provides a
   definition and a name (Legacy Extended IRI) for these variants for
   easy reference.  These variants have to be used with care; they
   require further processing before being fully interchangeable as
   IRIs.  New protocols and formats SHOULD NOT use Legacy Extended IRIs.
   Even where Legacy Extended IRIs are allowed, only IRIs fully
   conforming to the syntax definition in Section 2.2 SHOULD be created,
   generated, and used.
>>>>>>>>


Regards,   Martin.


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

Received on Monday, 17 March 2008 04:51:02 UTC