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

Chris Weber wrote in <4EC89A29.8070106@lookout.net>:

> 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?

Hi, I failed to figure out what this is about, is it related to
<URL:http://tools.ietf.org/html/draft-weber-iri-guidelines>, to
<URL:http://tools.ietf.org/html/draft-masinter-iri-comparison>,
or is it about something else not yet listed on the IRI WG page?

For the "guidelines" and "comparisons" drafts I'd hope that they
stay here (on this list).  IMHO the "guidelines" are interesting
enough to merge them into 3987bis proper.

BTW, looking in the guidelines I-D I saw that leading and trailing
white space (defined as SP, HT, CR, or LF) is stripped.  Within
the result only SP is considered as "substring split opportunity",
if I understood it correctly.  Is that as it should be?  Why not
stick to one concept of white space SP, HT, CR, or LF everywhere?

Two "arbitrary Unicode strings" I have in mind are:

1: {WSP}http://example.net{WSP}http://example.org{WSP}
2: {WSP}<http://example.net/this{WSP}page>{WSP}

{WSP} is some RFC 5322 folding white space magic used to split a
long IRI (ignoring obs-FWS here), and "this page" should end up
as "this%20page" in HTTP.  The 2nd example uses angle brackets to
delimit one IRI, the 1st example offers no delimiter and contains
two IRIs.

-Frank

Received on Thursday, 24 November 2011 06:52:32 UTC