Nabble - w3.org - public-iri

Re: how browsers transform URLs

2009-12-22T16:08:21Z

This is really cool.

I'm assuming that the yellow highlights indicate cases where implementations differ, correct?

AIUI you're testing both IMG tags and HTML forms, but I only see one set of results for each browser/os/test case combination. Did you not see any differentiation?

Also, what about A tags and other means of generating links?

Cheers,

P.S. in the design document under "Test page generation", you have an unescaped <img> tag.

On 26/11/2009, at 6:49 AM, Erik van der Poel wrote:

> We are happy to announce the open source release of Client URL
> Internet Emission Sniffer (CURLIES).
>
> The purpose of this project is to see how browsers and other Web
> clients transform URLs as they access them. This is done by generating
> a number of test cases and having each client load the test files
> while running a packet sniffer to capture the network emissions.
> Reports are then generated from the sniffed packets, highlighting
> differences between the clients. For further details and test results,
> see the project site:
>
> http://code.google.com/p/curlies/
> http://code.google.com/p/curlies/wiki/DesignDocumentForClientURLInternetEmissionSniffer
>
> I have also written some recommendations for browser developers. While
> the HTML5 Web Addresses spec already describes how to parse and
> resolve a URL, I have taken this a step further to include the DOM
> interfaces that can be used to obtain IRIs, URIs and Unicode host
> names.
>
> http://code.google.com/p/curlies/wiki/RecommendationsForBrowserDevelopers
> http://www.w3.org/html/wg/href/draft
>
> Happy Thanksgiving!
>
> Erik
>
> PS Many thanks to Shaopeng Jia (Google), who did most of the actual work.
>

--
Mark Nottingham http://www.mnot.net/

Advice on making IRI document suitable for reference by HTML (and other specs)

2009-12-20T00:21:38Z

One of the goals we wanted to make sure of in the charter was to

(1) insure that the IRI document going forward was suitable for use
by the HTML specification as a normative reference (for certain), and
(2) also try to minimize the difference between how browsers treated URLs
and how all other Internet applications applications treat URLs.

I was hoping that the document already met the goal for (1), and that
(2) was something to work on, but I think there needs to be more work
to get (1) accomplished.

I'd like to ask for some help and discussion around what is in the
HTML working group "Bug database" as a "bug" to change HTML to point
to draft-duerst-iri-bis with some proposed text. However, there remain
some problems.

I'd appreciate it if some other mailing list subscribers had some
ideas for how to fix the document better to accomplish (1) while retaining
the goal for (2). To make progress on (2), I think we'd want to take
some of the things in section 7.2 "HREF preprocessing" and move them
into the main body of what all normative URI processors should do, and
not just the ones in browsers. Things like chopping off initial & final
whitespace, hadling single "%" , deleting or encoding otherwise illegal
characters, etc.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8207

--- Comment #4 from Ian 'Hixie' Hickson <ian@...> 2009-12-16 02:45:15 ---
I looked at doing this, but the IRIbis draft isn't yet in a state where I can
really do this. There's no algorithm that defines how to resolve an arbitrary
string against an absolute base URL, as far as I can tell; in particular,
nothing seems to take into account the HRef-charset so as to encode characters
differently in different parts of the string. There's no definition of "valid
URL" that I can refer to (that takes into account the "HRef-charset"). The
parsing algorithm is destructive (e.g. the <path> of "http://example.com/%X"
is, as far as I can tell, 5 characters long ("/%25X"), not three as required by
Web compat ("/%X"). There's no definition of "absolute URL" that I can use
(mostly because the current parsing algorithms are destructive).

This is all assuming that the split should be as it is now; this may not be a
good assumption. If we should move the interface a bit, that may change
matters. For example, it seems to me we probably what the "HRef-charset"
definition in HTML5, rather than in the IRI spec.

Please advise on how I should proceed.

Re: draft-nottingham-http-link-relation-07 progress

2009-12-16T04:53:26Z

On Mon, Dec 14, 2009 at 9:11 PM, "Martin J. Dürst"
<duerst@...> wrote:

> I agree that RFC 3986 (and RFC 3987) are not of direct use for defining
> anything like a normalization of URIs (or IRIs). The main reason for this is
> that there are different contexts in which you may have different knowledge
> (e.g. of scheme specific default ports) and may prefer aggressive or
> cautionary normalization. The safe side of the normalization range is on
> different ends depending on what you are doing.
>
> As we are working on an update to RFC 3987, what I'm wondering is whether it
> may be possible to improve the text in RFC 3987 (which is mostly a copy of
> the one in RFC 3986, with some additions due to the bigger character
> repertoire) so that it becomes easier for an application such as OAuth to
> define what they need just with a few pointers (e.g. "from Section X of the
> IRI spec, use foo, baz, and frof normalizations but not bar") rather than
> defining everything ab initio.
>
> Would that help? Or does nobody care?
>

I think it would be very useful, partly because it would allow
descriptions of comparison techniques to say "The FOO comparison
starts with the application of the BAR normalization
then applies the following steps". This simplifies the necessary
description of the comparison methods, and it seems likely to improve
the selection among comparison methods by protocol designers as
well.

Just my two cents,

Ted

> Regards, Martin.
>
> On 2009/12/03 3:03, Eran Hammer-Lahav wrote:
>>
>> It's a good start but not enough. The text itself points out the various
>> problems with normalization but does not address all of them with normative
>> language. Normalization must be nothing but a long list of MUSTs and MUST
>> NOTs.
>>
>> When we first pointed developers to 3986 for OAuth normalization needs,
>> nothing worked...
>>
>> EHL
>>
>>> -----Original Message-----
>>> From: Julian Reschke [mailto:julian.reschke@...]
>>> Sent: Wednesday, December 02, 2009 8:43 AM
>>> To: Eran Hammer-Lahav
>>> Cc: Jan Algermissen; John Panzer; Apps Discuss
>>> Subject: Re: draft-nottingham-http-link-relation-07 progress
>>>
>>> Eran Hammer-Lahav wrote:
>>>>
>>>> Unfortunately no. There is no standard way (I'm aware of) to
>>>> canonicalize a
>>>
>>> URI in a consistent way. This is why specs like OAuth have to spell out
>>> how to
>>> perform percent encoding and other transformations to ensure a consistent
>>> string.
>>>>
>>>> ...
>>>
>>> <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.6.2.2.2>?
>>>
>>> BR, Julian
>>
>> _______________________________________________
>> Apps-Discuss mailing list
>> Apps-Discuss@...
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>
> --
> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@...
> _______________________________________________
> Apps-Discuss mailing list
> Apps-Discuss@...
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

Re: draft-nottingham-http-link-relation-07 progress

2009-12-14T21:11:20Z

I agree that RFC 3986 (and RFC 3987) are not of direct use for defining
anything like a normalization of URIs (or IRIs). The main reason for
this is that there are different contexts in which you may have
different knowledge (e.g. of scheme specific default ports) and may
prefer aggressive or cautionary normalization. The safe side of the
normalization range is on different ends depending on what you are doing.

As we are working on an update to RFC 3987, what I'm wondering is
whether it may be possible to improve the text in RFC 3987 (which is
mostly a copy of the one in RFC 3986, with some additions due to the
bigger character repertoire) so that it becomes easier for an
application such as OAuth to define what they need just with a few
pointers (e.g. "from Section X of the IRI spec, use foo, baz, and frof
normalizations but not bar") rather than defining everything ab initio.

Would that help? Or does nobody care?

Regards, Martin.

On 2009/12/03 3:03, Eran Hammer-Lahav wrote:

> It's a good start but not enough. The text itself points out the various problems with normalization but does not address all of them with normative language. Normalization must be nothing but a long list of MUSTs and MUST NOTs.
>
> When we first pointed developers to 3986 for OAuth normalization needs, nothing worked...
>
> EHL
>
>> -----Original Message-----
>> From: Julian Reschke [mailto:julian.reschke@...]
>> Sent: Wednesday, December 02, 2009 8:43 AM
>> To: Eran Hammer-Lahav
>> Cc: Jan Algermissen; John Panzer; Apps Discuss
>> Subject: Re: draft-nottingham-http-link-relation-07 progress
>>
>> Eran Hammer-Lahav wrote:
>>> Unfortunately no. There is no standard way (I'm aware of) to canonicalize a
>> URI in a consistent way. This is why specs like OAuth have to spell out how to
>> perform percent encoding and other transformations to ensure a consistent
>> string.
>>> ...
>>
>> <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.6.2.2.2>?
>>
>> BR, Julian
> _______________________________________________
> Apps-Discuss mailing list
> Apps-Discuss@...
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

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

RE: IRI BOF followup

2009-12-11T11:54:29Z

Certainly we need consistency. The consensus on our end is that the "list" needs to be in a consistent direction. There's a lot of concern that if a.b is reordered b.a, but not other times, then users might be get confused.

I can see where http://microsoft.com might lead someone to expect http://A.B.microsoft.com to render as http://B.A.microsoft.com so that "microsoft.com" stays "the same", but the precedence then becomes very muddy for the rest of it.

Anyway, I don't expect to solve it in this thread, I'd just like a little bit of usability testing done because I think that users find the behavior in the draft fairly confusing. (That's the feedback we've gotton from internal bidi users and the Saudi Government anyway).

So maybe a focus group within the new working group to look at this problem would be good :)

-Shawn

________________________________________
From: "Martin J. Dürst" [duerst@...]
Sent: Friday, December 11, 2009 2:03 AM
To: Shawn Steele
Cc: Larry Masinter; public-iri@...; Matitiahu Allouche
Subject: Re: IRI BOF followup

Hello Shawn,

Many thanks for your feedback on the charter.

On 2009/12/09 8:50, Shawn Steele wrote:
> I guess that covers some of my concerns, but the draft charter isn't clear if this is covered.
>
> Regarding draft-duerst-iri-bis specifically, I think that we need to consciously seek native BIDI speakers.

The current design, both for IDNA(2003) and RFC 3987, was strongly
influenced by Mati Allouche, a top Bidi expert and native Bidi writer
(the term "BIDI speaker" is a bit strange, as bidi only is an issue when
written). I have cc'ed him.

> Some previous IDN work seems to have missed that (don't know about IRI), so it might be good to include that "we will get input from native RTL speakers."
>
> Chatting with Arabic-speaking colleagues and input from the Saudi government would expect very different behavior from what martin proposes. Specifically they native speakers seem to treat the different parts as a list that progresses in a single direction. Eg: http://ab.CDE.FGH/ij/kl/mn/op.html is parsed as a list {http, ab, cde, fgh, ij,kl, mn, op(.html?)} So the expected rendering would be from the one end of the list to the other.

I can tell you that something along these lines would very much be my
expectation, too (even not being native). The real problem with bidi for
IDNs and IRIs is that we are between a rock and a hard place.

It's not too difficult to get input from native speakers on what might
look best. But what's really difficult is to conciliate that input with
the rest of the requirements for bidi IDN or IRI display. There are
mainly two:

1) Bidi IRIs have to be displayed consistently everywhere they appear,
or we get hopeless user confusion and another attack surface for scams.

2) The display chosen has to work in running text, without knowing that
there's an IDN or IRI, or where it starts or ends.

It is very important that we keep these goals (for more details, please
see the IDAN 2008 bidi draft, which spells them out more explicitly in
an IDN context) in mind both for the charter and for our actual work.

Below a few more technical explanations and comments, not directly
relevant to the charter.

> Furthermore, in an RTL/BIDI context, those users seem to prefer that the list be rendered from RTL. In other words:
>
> ???/mn/kl/ij/HGF.EDC.ab//:http

I think that the current requirement of an LTR context for IRIs may be
too strong, and that in particular for absolute IRIs, the potential for
confusion would not be much bigger if we allowed both LTR and RTL
context, but I think we need to be very careful about that. If we went
that way, that would allow

???/ij/kl/mn/HGF.EDC.http//:ab

(not very helpful, but that's as good as it gets if you let the bidi
algorithm do its work), or more importantly,

???/NM/LK/JI/HGF.EDC.AB//:http

> I even got the expectation that in an Arabic browser they'd expect to see:
>
> com.microsoft//:http

What Mati has explained to me is that those users that think mostly
logically and internally (that includes most of us tech guys) and who
know how a domain name and an IRI parses may indeed expect
com.microsoft. However, more visually oriented people with less
understanding of the syntax and what's behind it (which means the
majority of the population) may be better served by seeing
"microsoft.com" as "microsoft.com" independent of context. This is
essentially what the bidi algorithm tries to do for natural running
text, namely to keep sequences of LTR words in an internally LTR
direction, even in an overall RTR context. Thus, you can see something like:

CIBARA CIBARA hello world CIBARA CIBARA

as quite equivalent to:

CIBARA CIBARA microsoft.com CIBARA CIBARA

> The ??? is because I don't know what the expectation of the file "op.html" is. Is it expected to be a single unit, or 2 parts? I didn't ask that question.

What happens with such a thing in places in Arabic/Hebrew (or just any
other) Windows where that's displayed (in particular for OP.html)?

> So I think this needs a serious usability study on the part of the WG.

I don't think IETF WGs are good at doing usability studies. Larry's text
about explicit review is more along the lines of what an IETF WG
typically does, and is fine by me except for the "of ..., of" repetition
and the use of "native speakers", which in this context really has to be
"native writers". But these are details which can be fixed later.

Regards, Martin.

> -Shawn
>
> -----Original Message-----
> From: public-iri-request@... [mailto:public-iri-request@...] On Behalf Of Larry Masinter
> Sent: ??????, ???????? 08, ??? 2009 14:11
> To: Shawn Steele; public-iri@...
> Subject: RE: IRI BOF followup
>
> The current document has extensive work on BIDI in it already.
> Are there particular points or requirements that aren't already in scope by way of already being mentioned in draft-duerst-iri-bis?
>
> Larry
> --
> http://larry.masinter.net
>
>
> -----Original Message-----
> From: Shawn Steele [mailto:Shawn.Steele@...]
> Sent: Tuesday, December 08, 2009 11:53 AM
> To: Larry Masinter; public-iri@...
> Subject: RE: IRI BOF followup
>
> I would like to see BIDI presentation explicitly called out. It seems to be something that isn't working very well and maybe hasn't gotten enough expert attention in the past. It could be part of the Internationalization BCP, but I think it should be called out.
>
> -Shawn
>
> -----Original Message-----
> From: public-iri-request@... [mailto:public-iri-request@...] On Behalf Of Larry Masinter
> Sent: ??????, ???????? 08, ??? 2009 11:42
> To: public-iri@...
> Subject: FW: IRI BOF followup
>
> FYI (should have sent this more broadly); we're trying to prep for the IESG review of forming an IRI working group.
>
> Please review proposed charter ASAP.
>
>
> -----Original Message-----
> From: Larry Masinter
> Sent: Tuesday, December 08, 2009 10:46 AM
> To: '"Martin J. Dürst"'; Alexey Melnikov
> Cc: Pete Resnick; Ted Hardie; Lisa Dusseault
> Subject: RE: IRI BOF followup
>
> I made a pass over the draft charter to update the dates, deliverables, and to tweak Martin's wording. I made it clear that the only purpose of splitting the draft would be to facilitate editing.
>
> Larry
>
>
>
>
>
>
>

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

Re: IRI BOF followup

2009-12-11T02:03:31Z

Hello Shawn,

Many thanks for your feedback on the charter.

On 2009/12/09 8:50, Shawn Steele wrote:
> I guess that covers some of my concerns, but the draft charter isn't clear if this is covered.
>
> Regarding draft-duerst-iri-bis specifically, I think that we need to consciously seek native BIDI speakers.

The current design, both for IDNA(2003) and RFC 3987, was strongly
influenced by Mati Allouche, a top Bidi expert and native Bidi writer
(the term "BIDI speaker" is a bit strange, as bidi only is an issue when
written). I have cc'ed him.

> Some previous IDN work seems to have missed that (don't know about IRI), so it might be good to include that "we will get input from native RTL speakers."
>
> Chatting with Arabic-speaking colleagues and input from the Saudi government would expect very different behavior from what martin proposes. Specifically they native speakers seem to treat the different parts as a list that progresses in a single direction. Eg: http://ab.CDE.FGH/ij/kl/mn/op.html is parsed as a list {http, ab, cde, fgh, ij,kl, mn, op(.html?)} So the expected rendering would be from the one end of the list to the other.

I can tell you that something along these lines would very much be my
expectation, too (even not being native). The real problem with bidi for
IDNs and IRIs is that we are between a rock and a hard place.

It's not too difficult to get input from native speakers on what might
look best. But what's really difficult is to conciliate that input with
the rest of the requirements for bidi IDN or IRI display. There are
mainly two:

1) Bidi IRIs have to be displayed consistently everywhere they appear,
or we get hopeless user confusion and another attack surface for scams.

2) The display chosen has to work in running text, without knowing that
there's an IDN or IRI, or where it starts or ends.

It is very important that we keep these goals (for more details, please
see the IDAN 2008 bidi draft, which spells them out more explicitly in
an IDN context) in mind both for the charter and for our actual work.

Below a few more technical explanations and comments, not directly
relevant to the charter.

> Furthermore, in an RTL/BIDI context, those users seem to prefer that the list be rendered from RTL. In other words:
>
> ???/mn/kl/ij/HGF.EDC.ab//:http

I think that the current requirement of an LTR context for IRIs may be
too strong, and that in particular for absolute IRIs, the potential for
confusion would not be much bigger if we allowed both LTR and RTL
context, but I think we need to be very careful about that. If we went
that way, that would allow

???/ij/kl/mn/HGF.EDC.http//:ab

(not very helpful, but that's as good as it gets if you let the bidi
algorithm do its work), or more importantly,

???/NM/LK/JI/HGF.EDC.AB//:http

> I even got the expectation that in an Arabic browser they'd expect to see:
>
> com.microsoft//:http

What Mati has explained to me is that those users that think mostly
logically and internally (that includes most of us tech guys) and who
know how a domain name and an IRI parses may indeed expect
com.microsoft. However, more visually oriented people with less
understanding of the syntax and what's behind it (which means the
majority of the population) may be better served by seeing
"microsoft.com" as "microsoft.com" independent of context. This is
essentially what the bidi algorithm tries to do for natural running
text, namely to keep sequences of LTR words in an internally LTR
direction, even in an overall RTR context. Thus, you can see something like:

CIBARA CIBARA hello world CIBARA CIBARA

as quite equivalent to:

CIBARA CIBARA microsoft.com CIBARA CIBARA

> The ??? is because I don't know what the expectation of the file "op.html" is. Is it expected to be a single unit, or 2 parts? I didn't ask that question.

What happens with such a thing in places in Arabic/Hebrew (or just any
other) Windows where that's displayed (in particular for OP.html)?

> So I think this needs a serious usability study on the part of the WG.

I don't think IETF WGs are good at doing usability studies. Larry's text
about explicit review is more along the lines of what an IETF WG
typically does, and is fine by me except for the "of ..., of" repetition
and the use of "native speakers", which in this context really has to be
"native writers". But these are details which can be fixed later.

Regards, Martin.

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

RE: IRI BOF followup

2009-12-09T13:32:40Z

Thank you for considering my quibble :) This looks fine to me.

-Shawn

-----Original Message-----
From: public-iri-request@... [mailto:public-iri-request@...] On Behalf Of Larry Masinter
Sent: ???????, ???????? 09, ??? 2009 12:21
To: Alexey Melnikov
Cc: "Martin J. Dürst"; Pete Resnick; Ted Hardie; Lisa Dusseault; public-iri@...; Peter Saint-Andre
Subject: RE: IRI BOF followup

Sorry for the frequent updates. I added a sentence in response to Shawn's request to call out explicit BIDI review by native speakers.

(also updated http://trac.tools.ietf.org/area/app/trac/wiki/DraftIriCharter)

DRAFT IRI Working Group Charter
==============================
See also:
* Goals for IRI work in IETF
http://trac.tools.ietf.org/area/app/trak/wiki/IriWorkGoals

Overview
========
This working group will produce
* A new version of RFC 3987: "Internationalized Resource
Identifiers (IRIs)"
* A new version of RFC 4395: "Guidelines and Registration
Procedures for New URI Schemes"

The new version of RFC 3987 may be split into separate documents, if, in the opinion of the chair(s), it would facilitate distribution of the workload and allow more focused reviews. For example, the following breakdown has been suggested:

* Handling of Internationalized domain names in IRIs (BCP)
* Internationalization Considerations in IRIs (guidelines
for BIDI, character ranges to avoid, special considerations) (BCP)
* Syntax, parsing, comparison of IRIs (Standards track)

The working group starts with a relatively mature update to RFC 3987 in preparation; the primary focus of the group is to resolve conflicting uses, requirements and best practices for internationalized URLs/URIs/IRIs and various other forms, among many specifications and committees, while moving toward consistent use of IRIs among the wide range of Internet applications that use them. In particular:

* The IRI specification(s) must (continue to) be suitable
for normative reference with Web and XML standards from W3C
specifications. The group should coordinate with the W3C working
groups on HTML, XML Core, and Internationalization to ensure
acceptability (see HTML Editor requirements at end of referenced
'goals' list).
* The IRI specification(s) should be follow best practices
for domain names. The group should coordinate with the IETF
IDNA working group to assure acceptability.
* Explicit review by experts on (and native speakers) of RTL
languages, of the recommendations for BIDI languages,
is required.

The Working Group will examine at least one and possibly more URI/IRI schemes to check that the new specification(s) are appropriate for existing schemes. Schemes suggested for review include http:, pop:, imap:, xmpp:, mailto:, and sip:.

Changes to RFC 3986 ("Uniform Resource Identifier (URI):
Generic Syntax") are explicitly out of scope of this charter, and may only be considered with a charter update.

Current Internet Drafts
=======================
* draft-duerst-iri-bis

Administrative
==============
BOF Chairs: Ted Hardie and Pete Resnick
Mailing list: public-iri@...
Responsible AD: Alexey Melnikov

Schedule
========
January 2010
Additional update of Internet drafts by editor(s) February 2010
Review of Internet Drafts, directions during W3C
and IETF
May 2010
Working group Last Call of all documents June 2010
Publish IRI documents as RFCs (BCP, standards
track, as appropriate)

Additional documents for review and groups for liaison ======================================================
For this working group to succeed, agreement of the affected communities, including the following, is required:

IDNA requirements for domain names in identifiers
Specifications:
* http://tools.ietf.org/html/draft-ietf-idnabis-defs
Being prepared by:
* IETF IDNABIS working group
http://www.ietf.org/dyn/wg/charter/idnabis-charter.html

HTTPBIS definition of http: URI scheme
Specification:
* http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging,
section 9.2 on HTTP URI scheme
Being prepared by:
* HTTPBIS working group tools.ietf.org/wg/httpbis/charters

Unicode Consortium Work on IDNA, TR 46.
* http://www.unicode.org/reports/tr46/
Draft of Unicode consortium report on IDNA

HTML5 definition of "URLs"
Specification:
* HTML5 definition of URL
http://dev.w3.org/html5/spec/Overview.html#urls
o See Issue 56 http://www.w3.org/html/wg/tracker/issues/56
Being prepared by:
* W3C HTML Working Group http://www.w3.org/html/wg/
* WHATWG http://www.whatwg.org/

W3C Internationalization Core Working Group
* http://www.w3.org/International/core/
Sponsor and coordinating body for W3C activity on IRIs

RE: IRI BOF followup

2009-12-09T12:21:25Z

Sorry for the frequent updates. I added a sentence in response to
Shawn's request to call out explicit BIDI review by native speakers.

(also updated http://trac.tools.ietf.org/area/app/trac/wiki/DraftIriCharter)

DRAFT IRI Working Group Charter
==============================
See also:
* Goals for IRI work in IETF
http://trac.tools.ietf.org/area/app/trak/wiki/IriWorkGoals

Overview
========
This working group will produce
* A new version of RFC 3987: "Internationalized Resource
Identifiers (IRIs)"
* A new version of RFC 4395: "Guidelines and Registration
Procedures for New URI Schemes"

The new version of RFC 3987 may be split into separate documents,
if, in the opinion of the chair(s), it would facilitate distribution
of the workload and allow more focused reviews. For example, the
following breakdown has been suggested:

* Handling of Internationalized domain names in IRIs (BCP)
* Internationalization Considerations in IRIs (guidelines
for BIDI, character ranges to avoid, special considerations) (BCP)
* Syntax, parsing, comparison of IRIs (Standards track)

The working group starts with a relatively mature update to
RFC 3987 in preparation; the primary focus of the group
is to resolve conflicting uses, requirements and best practices
for internationalized URLs/URIs/IRIs and various other forms,
among many specifications and committees, while moving toward
consistent use of IRIs among the wide range of Internet
applications that use them. In particular:

* The IRI specification(s) must (continue to) be suitable
for normative reference with Web and XML standards from W3C
specifications. The group should coordinate with the W3C working
groups on HTML, XML Core, and Internationalization to ensure
acceptability (see HTML Editor requirements at end of referenced
'goals' list).
* The IRI specification(s) should be follow best practices
for domain names. The group should coordinate with the IETF
IDNA working group to assure acceptability.
* Explicit review by experts on (and native speakers) of RTL
languages, of the recommendations for BIDI languages,
is required.

The Working Group will examine at least one and possibly more
URI/IRI schemes to check that the new specification(s) are
appropriate for existing schemes. Schemes suggested for
review include http:, pop:, imap:, xmpp:, mailto:, and sip:.

Changes to RFC 3986 ("Uniform Resource Identifier (URI):
Generic Syntax") are explicitly out of scope of this charter,
and may only be considered with a charter update.

Current Internet Drafts
=======================
* draft-duerst-iri-bis

Administrative
==============
BOF Chairs: Ted Hardie and Pete Resnick
Mailing list: public-iri@...
Responsible AD: Alexey Melnikov

Schedule
========
January 2010
Additional update of Internet drafts by editor(s)
February 2010
Review of Internet Drafts, directions during W3C
and IETF
May 2010
Working group Last Call of all documents
June 2010
Publish IRI documents as RFCs (BCP, standards
track, as appropriate)

Additional documents for review and groups for liaison
======================================================
For this working group to succeed, agreement of the
affected communities, including the following, is required:

IDNA requirements for domain names in identifiers
Specifications:
* http://tools.ietf.org/html/draft-ietf-idnabis-defs
Being prepared by:
* IETF IDNABIS working group
http://www.ietf.org/dyn/wg/charter/idnabis-charter.html

HTTPBIS definition of http: URI scheme
Specification:
* http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging,
section 9.2 on HTTP URI scheme
Being prepared by:
* HTTPBIS working group tools.ietf.org/wg/httpbis/charters

Unicode Consortium Work on IDNA, TR 46.
* http://www.unicode.org/reports/tr46/
Draft of Unicode consortium report on IDNA

HTML5 definition of "URLs"
Specification:
* HTML5 definition of URL
http://dev.w3.org/html5/spec/Overview.html#urls
o See Issue 56 http://www.w3.org/html/wg/tracker/issues/56
Being prepared by:
* W3C HTML Working Group http://www.w3.org/html/wg/
* WHATWG http://www.whatwg.org/

W3C Internationalization Core Working Group
* http://www.w3.org/International/core/
Sponsor and coordinating body for W3C activity on IRIs

RE: IRI BOF followup

2009-12-09T07:51:42Z

With updates from Peter Saint-Andre (also updated
http://trac.tools.ietf.org/area/app/trac/wiki/DraftIriCharter)

DRAFT IRI Working Group Charter
==============================
See also:
* Goals for IRI work in IETF
http://trac.tools.ietf.org/area/app/trak/wiki/IriWorkGoals

Overview
========
This working group will produce
* A new version of RFC 3987: "Internationalized Resource
Identifiers (IRIs)"
* A new version of RFC 4395: "Guidelines and Registration
Procedures for New URI Schemes"

The new version of RFC 3987 may be split into separate documents,
if, in the opinion of the chair(s), it would facilitate distribution
of the workload and allow more focused reviews. For example, the
following breakdown has been suggested:

* Handling of Internationalized domain names in IRIs (BCP)
* Internationalization Considerations in IRIs (guidelines
for BIDI, character ranges to avoid, special considerations) (BCP)
* Syntax, parsing, comparison of IRIs (Standards track)

The working group starts with a relatively mature update to
RFC 3987 in preparation; the primary focus of the group
is to resolve conflicting uses, requirements and best practices
for internationalized URLs/URIs/IRIs and various other forms,
among many specifications and committees, while moving toward
consistent use of IRIs among the wide range of Internet
applications that use them. In particular:

* The IRI specification(s) must (continue to) be suitable
for normative reference with Web and XML standards from W3C
specifications. The group should coordinate with the W3C working
groups on HTML, XML Core, and Internationalization to ensure
acceptability (see HTML Editor requirements at end of referenced
'goals' list).
* The IRI specification(s) should be follow best practices
for domain names. The group should coordinate with the IETF
IDNA working group to assure acceptability.

The Working Group will examine at least one and possibly more
URI/IRI schemes to check that the new specification(s) are
appropriate for existing schemes. Schemes suggested for
review include http:, pop:, imap:, xmpp:, mailto:, and sip:.

Changes to RFC 3986 ("Uniform Resource Identifier (URI):
Generic Syntax") are explicitly out of scope of this charter,
and may only be considered with a charter update.

Current Internet Drafts
=======================
* draft-duerst-iri-bis

Administrative
==============
BOF Chairs: Ted Hardie and Pete Resnick
Mailing list: public-iri@...
Responsible AD: Alexey Melnikov

Schedule
========
January 2010
Additional update of Internet drafts by editor(s)
February 2010
Review of Internet Drafts, directions during W3C
and IETF
May 2010
Working group Last Call of all documents
June 2010
Publish IRI documents as RFCs (BCP, standards
track, as appropriate)

Additional documents for review and groups for liaison
======================================================
For this working group to succeed, agreement of the
affected communities, including the following, is required:

IDNA requirements for domain names in identifiers
Specifications:
* http://tools.ietf.org/html/draft-ietf-idnabis-defs
Being prepared by:
* IETF IDNABIS working group
http://www.ietf.org/dyn/wg/charter/idnabis-charter.html

HTTPBIS definition of http: URI scheme
Specification:
* http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging,
section 9.2 on HTTP URI scheme
Being prepared by:
* HTTPBIS working group tools.ietf.org/wg/httpbis/charters

Unicode Consortium Work on IDNA, TR 46.
* http://www.unicode.org/reports/tr46/
Draft of Unicode consortium report on IDNA

HTML5 definition of "URLs"
Specification:
* HTML5 definition of URL
http://dev.w3.org/html5/spec/Overview.html#urls
o See Issue 56 http://www.w3.org/html/wg/tracker/issues/56
Being prepared by:
* W3C HTML Working Group http://www.w3.org/html/wg/
* WHATWG http://www.whatwg.org/

W3C Internationalization Core Working Group
* http://www.w3.org/International/core/
Sponsor and coordinating body for W3C activity on IRIs

RE: IRI BOF followup

2009-12-08T18:08:38Z

Yet another update to make this read OK in a standalone document (From: http://trac.tools.ietf.org/area/app/trac/wiki/DraftIriCharter)

DRAFT IRI Working Group Charter
==============================

See also:
* Goals for IRI work in IETF http://trac.tools.ietf.org/aera/app/trak/wiki/IriWorkGoals

Overview:
=========
This working group will produce

* A new version of RFC 3987: "Internationalized Resource Identifiers (IRIs)"
* A new version of RFC 4395: "Guidelines and Registration Procedures for New URI Schemes"

The new version of RFC 3987 may be split into separate documents, if, in the opinion of the chair(s), it would facilitate distributing editing workload and focus review. For example, the following breakdown has been suggested:

* Handling of Internationalized domain names in IRIs (BCP)
* Internationalization Considerations in IRIs (guidelines for BIDI, character ranges to avoid, special considerations) (BCP)
* Syntax, parsing, comparison of IRIs (Standards track)

The working group starts with a relatively mature update to RFC 3987 in preparation; the primary focus of the group is to resolve conflicting uses, requirements and best practices for internationalized URLs/URIs/IRIs and various other forms, among many specifications and committees, while moving toward consistent use of IRIs among the wide range of Internet applications that use them. In particular:

* The IRI specification(s) must (continue to) be suitable for normative reference with Web and XML standards from W3C specifications. The group should liaison with the W3C working groups on HTML, XML Core, and Internationalization to insure acceptability (see HTML Editor requirements at end of referenced 'goals' list).
* The IRI specification(s) should be follow best practices for domain names. The group should liaison with the IETF IDNA working group to assure acceptability.

The Working Group will examine at least one and possibly more URI/IRI schemes to check that the new specification(s) are appropriate for existing schemes. Schemes suggested for review include http:, pop:, imap:, xmpp:, mailto:, and sip:.

Changes to RFC 3986 ("Uniform Resource Identifier (URI): Generic Syntax") are explicitly out of scope of this charter, and may only be considered with a charter update.

Current Internet Drafts:
========================

* draft-duerst-iri-bis

Administrative:
===============
BOF Chairs: Ted Hardie and Pete Resnick
Mailing list: public-iri@...
Responsible AD: Alexey Melnikov

Schedule:
=========
January 2010
Additional update of Internet drafts by editor(s)
February 2010
Review of Internet Drafts, directions during W3C and IETF
May 2010
Working group Last Call of all documents
June 2010
Publish IRI documents as RFCs (BCP, standards track, as appropriate)

Additional documents for review and groups for liaison:
=======================================================
For this working group to succeed, agreement of the affected communities, including the following, is required:

IDNA (requirements for domain names in identifiers)
Specifications:
* http://tools.ietf.org/html/draft-ietf-idnabis-defs
Being prepared by:
* IETF IDNABIS working group http://www.ietf.org/dyn/wg/charter/idnabis-charter.html

HTTPBIS definition of http: URI scheme
Specification:
* http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging, section 9.2 on HTTP URI scheme
Being prepared by:
* HTTPBIS working group tools.ietf.org/wg/httpbis/charters

Unicode Consortium
Work on IDNA, TR 46.
* http://www.unicode.org/reports/tr46/ Draft of Unicode consortium report on IDNA

HTML5 definition of "URLs"
Specification:
* HTML5 definition of URL http://dev.w3.org/html5/spec/Overview.html#urls
o See Issue 56 http://www.w3.org/html/wg/tracker/issues/56
Being prepared by:
* W3C HTML Working Group http://www.w3.org/html/wg/
* WHATWG http://www.whatwg.org/

W3C Internationalization Core Working Group
* http://www.w3.org/International/core/
Sponsor and coordinating body for W3C activity on IRIs

RE: IRI BOF followup

2009-12-08T15:50:31Z

I guess that covers some of my concerns, but the draft charter isn't clear if this is covered.

Regarding draft-duerst-iri-bis specifically, I think that we need to consciously seek native BIDI speakers. Some previous IDN work seems to have missed that (don't know about IRI), so it might be good to include that "we will get input from native RTL speakers."

Chatting with Arabic-speaking colleagues and input from the Saudi government would expect very different behavior from what martin proposes. Specifically they native speakers seem to treat the different parts as a list that progresses in a single direction. Eg: http://ab.CDE.FGH/ij/kl/mn/op.html is parsed as a list {http, ab, cde, fgh, ij,kl, mn, op(.html?)} So the expected rendering would be from the one end of the list to the other.

Furthermore, in an RTL/BIDI context, those users seem to prefer that the list be rendered from RTL. In other words:

???/mn/kl/ij/HGF.EDC.ab//:http

I even got the expectation that in an Arabic browser they'd expect to see:

com.microsoft//:http

The ??? is because I don't know what the expectation of the file "op.html" is. Is it expected to be a single unit, or 2 parts? I didn't ask that question.

So I think this needs a serious usability study on the part of the WG.

-Shawn

-----Original Message-----
From: public-iri-request@... [mailto:public-iri-request@...] On Behalf Of Larry Masinter
Sent: ??????, ???????? 08, ??? 2009 14:11
To: Shawn Steele; public-iri@...
Subject: RE: IRI BOF followup

The current document has extensive work on BIDI in it already.
Are there particular points or requirements that aren't already in scope by way of already being mentioned in draft-duerst-iri-bis?

Larry
--
http://larry.masinter.net

-----Original Message-----
From: Shawn Steele [mailto:Shawn.Steele@...]
Sent: Tuesday, December 08, 2009 11:53 AM
To: Larry Masinter; public-iri@...
Subject: RE: IRI BOF followup

I would like to see BIDI presentation explicitly called out. It seems to be something that isn't working very well and maybe hasn't gotten enough expert attention in the past. It could be part of the Internationalization BCP, but I think it should be called out.

-Shawn

-----Original Message-----
From: public-iri-request@... [mailto:public-iri-request@...] On Behalf Of Larry Masinter
Sent: ??????, ???????? 08, ??? 2009 11:42
To: public-iri@...
Subject: FW: IRI BOF followup

FYI (should have sent this more broadly); we're trying to prep for the IESG review of forming an IRI working group.

Please review proposed charter ASAP.

-----Original Message-----
From: Larry Masinter
Sent: Tuesday, December 08, 2009 10:46 AM
To: '"Martin J. Dürst"'; Alexey Melnikov
Cc: Pete Resnick; Ted Hardie; Lisa Dusseault
Subject: RE: IRI BOF followup

I made a pass over the draft charter to update the dates, deliverables, and to tweak Martin's wording. I made it clear that the only purpose of splitting the draft would be to facilitate editing.

Larry

RE: IRI BOF followup

2009-12-08T14:10:30Z

The current document has extensive work on BIDI in it already.
Are there particular points or requirements that aren't already
in scope by way of already being mentioned in draft-duerst-iri-bis?

Larry
--
http://larry.masinter.net

-----Original Message-----
From: Shawn Steele [mailto:Shawn.Steele@...]
Sent: Tuesday, December 08, 2009 11:53 AM
To: Larry Masinter; public-iri@...
Subject: RE: IRI BOF followup

I would like to see BIDI presentation explicitly called out. It seems to be something that isn't working very well and maybe hasn't gotten enough expert attention in the past. It could be part of the Internationalization BCP, but I think it should be called out.

-Shawn

-----Original Message-----
From: public-iri-request@... [mailto:public-iri-request@...] On Behalf Of Larry Masinter
Sent: ??????, ???????? 08, ??? 2009 11:42
To: public-iri@...
Subject: FW: IRI BOF followup

FYI (should have sent this more broadly); we're trying to prep for the IESG review of forming an IRI working group.

Please review proposed charter ASAP.

-----Original Message-----
From: Larry Masinter
Sent: Tuesday, December 08, 2009 10:46 AM
To: '"Martin J. Dürst"'; Alexey Melnikov
Cc: Pete Resnick; Ted Hardie; Lisa Dusseault
Subject: RE: IRI BOF followup

I made a pass over the draft charter to update the dates, deliverables, and to tweak Martin's wording. I made it clear that the only purpose of splitting the draft would be to facilitate editing.

Larry

RE: IRI BOF followup

2009-12-08T11:53:18Z

I would like to see BIDI presentation explicitly called out. It seems to be something that isn't working very well and maybe hasn't gotten enough expert attention in the past. It could be part of the Internationalization BCP, but I think it should be called out.

-Shawn

-----Original Message-----
From: public-iri-request@... [mailto:public-iri-request@...] On Behalf Of Larry Masinter
Sent: ??????, ???????? 08, ??? 2009 11:42
To: public-iri@...
Subject: FW: IRI BOF followup

FYI (should have sent this more broadly); we're trying to prep for the IESG review of forming an IRI working group.

Please review proposed charter ASAP.

-----Original Message-----
From: Larry Masinter
Sent: Tuesday, December 08, 2009 10:46 AM
To: '"Martin J. Dürst"'; Alexey Melnikov
Cc: Pete Resnick; Ted Hardie; Lisa Dusseault
Subject: RE: IRI BOF followup

I made a pass over the draft charter to update the dates, deliverables, and to tweak Martin's wording. I made it clear that the only purpose of splitting the draft would be to facilitate editing.

Larry

FW: IRI BOF followup

2009-12-08T11:41:56Z

FYI (should have sent this more broadly); we're trying to
prep for the IESG review of forming an IRI working group.

Please review proposed charter ASAP.

-----Original Message-----
From: Larry Masinter
Sent: Tuesday, December 08, 2009 10:46 AM
To: '"Martin J. Dürst"'; Alexey Melnikov
Cc: Pete Resnick; Ted Hardie; Lisa Dusseault
Subject: RE: IRI BOF followup

I made a pass over the draft charter to update the dates,
deliverables, and to tweak Martin's wording. I made it clear
that the only purpose of splitting the draft would be to
facilitate editing.

Larry

Re: Percent encoding normalization v. mapping URIs to IRIs

2009-12-02T03:45:09Z

Martin J. Dürst wrote:

> Many thanks for your comment.
>
> I think intent of saying that percent encoding normalization MUST only
> be done locally was to protect against changes that would lead to
> problems for uses such as XML Namespaces and RDF, where equality is
> defined character-by-character on the surface representation (i.e. '%'
> equals '%',...).
>
> However, I agree that this seems to be too strong, and in some way out
> of place, because such a provision would have to be in each and every
> subsection of the comparison ladder. I think it is better to only talk
> about this point in Simple String Comparison (currently
> http://tools.ietf.org/html/draft-duerst-iri-bis-07#section-5.3.2).

Indeed, it would need to be present everywhere: it also ends up not
making not overly much sense, as you could end up with HTTP clients
making requests for /foo/bar/.././myfile for example. Just because XML
Namespaces and RDF define URI comparison as being done on a
character-by-character basis doesn't seem like a good enough reason to
restrict all normalization to internal use. It seems to be sensible
enough to try and normalize any IRI regardless of whether it'll be
passed on or not (and in the XML Namespaces and RDF cases you are almost
always better off treating the IRI as an opaque string).

The present state (in 3987) of disallowing some normalization for that
reason but not other normalization rather makes the fact that some is
disallowed pointless. I'd rather there weren't any restrictions on
normalization.

--
Geoffrey Sneddon — Opera Software
<http://gsnedders.com/>
<http://www.opera.com/>

RE: Percent encoding normalization v. mapping URIs to IRIs

2009-12-02T03:08:48Z

# Given something that is both a URI and an IRI that contains a
# pct-encoded unreserved character, such as http://example.com/%41, you
# may apply percent-encoding normalization to end up with
# http://example.com/A, however, this MUST only be used for local
# comparison (currently section 5.3.2.3) and not passed along anywhere
# else. However, if you follow the steps for converting the URI to an IRI
# you will likewise end up with http://example.com/A, but with no such
# restriction on use of the converted string.

Yes, I think this is an error in "convert a URI to an IRI". The
goal of the conversion is

The conversion described in this section, if given a valid URI, will
result in an IRI that maps back to the URI used as an input for the
conversion (except for potential case differences in percent-encoding
and for potential percent-encoded unreserved characters).

I think the exception for "potential percent-encoded unreserved characters"
is inappropriate, and that the hex for percent-encoded but otherwise
allowed characters should not be decoded; in this case, converting an
IRI with "%41" in it should *not* translate to an IRI with an "A".

This error has been in the IRI draft all along -- it's not a new
error. There may be some kind of other conversions which also
normalize, but I think the goal should be

URI -> IRI will produce an IRI which will map back (exactly) to the
given URI.

Larry
--
http://larry.masinter.net

Re: More percent encoding normalization v. IRI -> URI -> IRI mapping differences

2009-12-02T03:07:22Z

Hello Geoffrey,

Many thanks for your comment. I think this is a good catch, and I'll try
to come up with some wording when I get around to work on the document.

Regards, Martin.

On 2009/12/02 18:21, Geoffrey Sneddon wrote:

> Beyond my previous email about the contradiction in conformance
> requirements (i.e., circumventing the MUST in 5.3.2.3 by mapping the IRI
> to a URI and back to an IRI), the IRI -> URI -> IRI mapping decodes all
> percent-encoded iunreserved and iprivate (where allowed) characters (at
> least if I'm understanding what it is doing correctly), whereas the
> percent-encoding normalization only decodes unreserved characters.
>
> As far as I can tell, changing the percent-encoding normalization to
> decode all iunreserved characters and iprivate where allowed would
> resolve this difference.
>

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

Re: Percent encoding normalization v. mapping URIs to IRIs

2009-12-02T03:04:11Z

Hello Geoffrey,

Many thanks for your comment.

I think intent of saying that percent encoding normalization MUST only
be done locally was to protect against changes that would lead to
problems for uses such as XML Namespaces and RDF, where equality is
defined character-by-character on the surface representation (i.e. '%'
equals '%',...).

However, I agree that this seems to be too strong, and in some way out
of place, because such a provision would have to be in each and every
subsection of the comparison ladder. I think it is better to only talk
about this point in Simple String Comparison (currently
http://tools.ietf.org/html/draft-duerst-iri-bis-07#section-5.3.2).

Regards, Martin.

On 2009/12/02 18:07, Geoffrey Sneddon wrote:

> Given something that is both a URI and an IRI that contains a
> pct-encoded unreserved character, such as http://example.com/%41, you
> may apply percent-encoding normalization to end up with
> http://example.com/A, however, this MUST only be used for local
> comparison (currently section 5.3.2.3) and not passed along anywhere
> else. However, if you follow the steps for converting the URI to an IRI
> you will likewise end up with http://example.com/A, but with no such
> restriction on use of the converted string.
>
> As far as I can tell, this is an effective contradiction in the spec, as
> either converting pct-encoded unreserved characters matters or it does
> not. If I really wanted to circumvent the restriction on pct-encoding
> normalization, I could just convert the URI to an IRI and back again, a
> procedure that would effectively do the same.
>

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

Re: Apparent cutting of sentence

2009-12-02T02:53:38Z

Hello Geoffrey,

Many thanks for your comments. Please note that several parts of the
current document are not yet really worked out and fully polished, as
you have noted. So at this point, it may be better to concentrate your
comments on the bigger issues.

As for your specific point, my guess is that Larry (who was working on
that part) wanted to finish the sentence with something like
"and in general there is therefore no need to convert URIs to IRIs." or
some such. But I'll defer to Larry to explain what he had in mind.

Regrads, Martin.

On 2009/12/02 17:35, Geoffrey Sneddon wrote:
> Within section 3.7 (Converting URIs to IRIs), appears the following:
> "and in general there This section". This makes it look as if the end of
> the sentence at the start of that quote has been cut, and it makes it
> fail to make sense (I also can't work out what should be there).
>

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

More percent encoding normalization v. IRI -> URI -> IRI mapping differences

2009-12-02T01:21:31Z

Beyond my previous email about the contradiction in conformance
requirements (i.e., circumventing the MUST in 5.3.2.3 by mapping the IRI
to a URI and back to an IRI), the IRI -> URI -> IRI mapping decodes all
percent-encoded iunreserved and iprivate (where allowed) characters (at
least if I'm understanding what it is doing correctly), whereas the
percent-encoding normalization only decodes unreserved characters.

As far as I can tell, changing the percent-encoding normalization to
decode all iunreserved characters and iprivate where allowed would
resolve this difference.

--
Geoffrey Sneddon — Opera Software
<http://gsnedders.com/>
<http://www.opera.com/>

Re: Apparent cutting of sentence

2009-12-02T01:08:30Z

Geoffrey Sneddon wrote:
> Within section 3.7 (Converting URIs to IRIs), appears the following:
> "and in general there This section". This makes it look as if the end of
> the sentence at the start of that quote has been cut, and it makes it
> fail to make sense (I also can't work out what should be there).

Apologies for sending this twice: I meant to resend the next email I
sent to the list (in which I had originally misspelt the list address).

--
Geoffrey Sneddon — Opera Software
<http://gsnedders.com/>
<http://www.opera.com/>

Percent encoding normalization v. mapping URIs to IRIs

2009-12-02T01:07:29Z

Given something that is both a URI and an IRI that contains a
pct-encoded unreserved character, such as http://example.com/%41, you
may apply percent-encoding normalization to end up with
http://example.com/A, however, this MUST only be used for local
comparison (currently section 5.3.2.3) and not passed along anywhere
else. However, if you follow the steps for converting the URI to an IRI
you will likewise end up with http://example.com/A, but with no such
restriction on use of the converted string.

As far as I can tell, this is an effective contradiction in the spec, as
either converting pct-encoded unreserved characters matters or it does
not. If I really wanted to circumvent the restriction on pct-encoding
normalization, I could just convert the URI to an IRI and back again, a
procedure that would effectively do the same.

--
Geoffrey Sneddon — Opera Software
<http://gsnedders.com/>
<http://www.opera.com/>

Apparent cutting of sentence

2009-12-02T01:06:45Z

Within section 3.7 (Converting URIs to IRIs), appears the following:
"and in general there This section". This makes it look as if the end of
the sentence at the start of that quote has been cut, and it makes it
fail to make sense (I also can't work out what should be there).

--
Geoffrey Sneddon — Opera Software
<http://gsnedders.com/>
<http://www.opera.com/>

Apparent cutting of sentence

2009-12-02T00:35:08Z

RE: Valid Characters in a [UI]R[LI] query string...

2009-12-01T17:34:54Z

In RFC 3986, "[" and "]" are not allowed in the 'query' component.

So "scheme://host/people?foo%5B%5D=bar" is valid and
"scheme://host/people?foo[]=bar" is not

The HTML5 document originally allowed [] in query components,
and "patched" them in the "Web Address" fixup.

This got lost in translation. There are two possibilities:

(a) Patch up "[" and "]" in section 7.2 Web Address processing
(b) make "[" and "]" legal in the query part by changing the
BNF to be:

iquery = *( ipchar / iprivate / "/" / "?" / "[" / "]" )

I'm in favor of trying to move as much of 7.2's "patchup"
behavior into the main line of IRIs as possible.

Larry
--
http://larry.masinter.net

==================
In response to:
==================

> For context, Ruby on Rails is built on top of a component called Rack.
> Both can construct what people colloquially call URLs, but do so
> differently. I'm looking for an expert opinion on which way is "right".
> Any thoughts?

Rails

> app.people_path(:foo => ["bar"])
=> "/people?foo%5B%5D=bar"

Rack

> Rack::Utils.build_nested_query(:foo => ["bar"])
=> "foo[]=bar"

- Sam Ruby

Re: HTML CHANGE PROPOSAL; change definition of URL to normative reference to IRIBIS

2009-12-01T12:12:56Z

Thanks for providing a Change Proposal for this issue! The chairs are
reviewing Change Proposals to ensure that they meet the required
structure. Here is our feedback on this Change Proposal:

1) Including the subsequently sent draft text, it seems to include
sufficient summary, details and impact. The subject line seems like a
fine one-sentence summary in fact.

2) There does not appear to be a rationale. Please provide a Rationale
section.

We suggest updating the Change Proposal to reflect the feedback in
point (2).

Regards,
Maciej

On Nov 5, 2009, at 12:20 PM, Larry Masinter wrote:

> I have updated the proposed draft charter for IRI work in IETF:
>
> http://trac.tools.ietf.org/area/app/trac/wiki/DraftIriCharter
>
> to explicitly calls for the resulting document as being
> suitable as a normative reference from HTML, and points
> to a draft of HTML Editor Requirements at the end of
> http://trac.tools.ietf.org/area/app/trac/wiki/IriWorkGoals.
>
> Please review, accept, or update as necessary, the "HTML
> Editor Requirements" prior to IETF chartering of the
> working group next Tuesday Nov 10.
>
> Assuming the liaison and requirements are acceptable as
> part of the IETF IRI working group charter and we find
> sufficient volunteers for editing, reviewing nad chairing,
>
> I offer a (vague, but I think workable)
>
> CHANGE PROPOSAL FOR HTML:
>
> Based on assuming
> that those requirements are met: please replace the
> definition of URL in the HTML5 specification and all
> descriptions of URL processing in the HTML5 specification
> with specific references to the [IRIBIS] document.
>
>
> I think this includes sections such as
>
> * Determine whether a string best matches Relative
> or Absolute, e.g., one might say:
> "Determine whether Absolute or Relative as per [IRIBIS]"
>
> * Determine whether a string is or isn't valid an IRI
> "Determine whether valid as per [IRIBIS]"
>
> * Offer heuristics for interpreting a user input
> or other unvalidated string as an IRI
> "User agents MAY interpret invalid strings as if
> they were valid in cases where the input is
> not otherwise validated, as per [IRIBIS]"
>
> * Resolve a relative IRI against a base
>
> As far as timing goes:
>
> Whenever you have a normative specification to another
> specification which is, itself, under development,
> there is some coordination necessary, but this request
> is based on the assumption that it isn't necessary
> to wait for the IRIBIS process to complete in order
> for HTML5 to go to last call prior to its publication
> as Proposed Recommendation.
>
> If there is not an IETF working group to update these
> documents such that they are suitable for reference
> by the HTML working group, then an appropriate change
> proposal would be to put back in the HTML5-only
> URL parsing algorithm that was there before the
> [WEBADDRESS] specification was split out.
>
> Larry
> --
> http://larry.masinter.net
>
>

RE: phishing in IRIs

2009-11-30T18:15:40Z

I don't mind helping with a BCP or something regarding security, however as Martin says there're several approaches, so it's hard to say "do this...", it seems like it would have to be more of "things to watch out for".

Although I'm aware of several concerns with IRI security, others probably know more about actual exploits and problems with IRIs/URLs. I'm more concerned with moderating the fear around IDN & homographs.

-Shawn

-----Original Message-----
From: "Martin J. Dürst" [mailto:duerst@...]
Sent: ???????, ???????? 27, ??? 2009 2:57
To: Larry Masinter
Cc: Shawn Steele; PUBLIC-IRI@...; Pete Resnick; Ted Hardie
Subject: Re: phishing in IRIs

Hello Shawn, Larry,

On 2009/11/27 5:45, Larry Masinter wrote:
> I would support a separate, longer document addressing phishing in
> particular; it would be great if this could be referenced by the IRI
> document itself.

I don't have anything against documents on phishing at all, but it may be difficult to reference it from the IRI document because the IRI spec is supposed to be finished very soon.

Because of this and because of arguments given earlier, I agree with Shawn that spoofing/phishing should be essentially outside the WG charter.

> Perhaps
> it could be a BCP. This might be a way of getting specific review of
> the broader security issues.
>
> Shawn, are you interested in editing such a document?
>
>
> I'd also suggest some coordination with the HTTPBIS security section:
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-08#section-
> 11
>
> "Phishers abuse domain name certainly, but they still use all-ASCII."
>
> The concern is that once IRIs with IDN are deployed that this will
> create an entirely new, rich attack surface. Putting in preventative
> measures before deployment rather than after-the-fact would be
> prudent.

I agree that we cannot just say that IRI or IDN spoofing is a non-issue because it's currently a very small issue. However, my understanding is that the mechanisms currently in place against spoofing in Web browsers would easily extend to IDNs, so IDN spoofing or IRI spoofing doesn't have to be treated as an issue separate from domain name spoofing or URI spoofing.

[In my understanding, the two main measures against spoofing are trademark violation and related claims that make the registry remove the domain name in question, and "check-back-home" schemes implemented in various browsers that check against a known blacklist and warn users.
But I might be wrong on this, I'm not an expert in this area.]

Regards, Martin.

> Larry
> --
> http://larry.masinter.net
>
>
> -----Original Message-----
> From: Shawn Steele [mailto:Shawn.Steele@...]
> Sent: Wednesday, November 25, 2009 12:12 PM
> To: "Martin J. Dürst"
> Cc: Larry Masinter; PUBLIC-IRI@...; Pete Resnick; Ted Hardie
> Subject: RE: phishing in IRIs
>
>> What I am saying is that spoofing of IRIs with the domain name part is a much greater problem than spoofing with IRIs in the rest of the IRI.
>
> I don't disagree with that :) But you extended it (I thought) to "the IDNs in the IRIs", which I don't see any evidence of. Phishers abuse domain name certainly, but they still use all-ASCII.
>
>> The IETF has a tradition of putting security considerations in the main document, not as a separate document.
>
> I'm concerned that to fully address the issues of security considerations in IRIs would take quite a bit of space. I'm also concerned that some aspects might be lead to a lot of discussion, as there probably isn't one "right" way to handle IRI security. An effective security document for IRIs IMO would be comparable to trying to address how to handle spam in email. So maybe the WG could consider mentioning some security concerns in the main document and provide a further document that describes security in more detail? For example, I think the discussion of safe-yourbank.com IRIs is interesting, but I'm not sure the main document is the right place for all of that discussion.
>
> -Shawn
>
>

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

Re: phishing in IRIs

2009-11-27T02:56:58Z

Hello Shawn, Larry,

On 2009/11/27 5:45, Larry Masinter wrote:
> I would support a separate, longer document addressing
> phishing in particular; it would be great if this
> could be referenced by the IRI document itself.

I don't have anything against documents on phishing at all, but it may
be difficult to reference it from the IRI document because the IRI spec
is supposed to be finished very soon.

Because of this and because of arguments given earlier, I agree with
Shawn that spoofing/phishing should be essentially outside the WG charter.

> Perhaps
> it could be a BCP. This might be a way of getting
> specific review of the broader security issues.
>
> Shawn, are you interested in editing such a document?
>
>
> I'd also suggest some coordination with the HTTPBIS
> security section:
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-08#section-11
>
> "Phishers abuse domain name certainly, but they still use all-ASCII."
>
> The concern is that once IRIs with IDN are deployed
> that this will create an entirely new, rich attack
> surface. Putting in preventative measures
> before deployment rather than after-the-fact
> would be prudent.

I agree that we cannot just say that IRI or IDN spoofing is a non-issue
because it's currently a very small issue. However, my understanding is
that the mechanisms currently in place against spoofing in Web browsers
would easily extend to IDNs, so IDN spoofing or IRI spoofing doesn't
have to be treated as an issue separate from domain name spoofing or URI
spoofing.

[In my understanding, the two main measures against spoofing are
trademark violation and related claims that make the registry remove the
domain name in question, and "check-back-home" schemes implemented in
various browsers that check against a known blacklist and warn users.
But I might be wrong on this, I'm not an expert in this area.]

Regards, Martin.

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

RE: phishing in IRIs

2009-11-26T12:45:48Z

I would support a separate, longer document addressing
phishing in particular; it would be great if this
could be referenced by the IRI document itself. Perhaps
it could be a BCP. This might be a way of getting
specific review of the broader security issues.

Shawn, are you interested in editing such a document?

I'd also suggest some coordination with the HTTPBIS
security section:
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-08#section-11

"Phishers abuse domain name certainly, but they still use all-ASCII."

The concern is that once IRIs with IDN are deployed
that this will create an entirely new, rich attack
surface. Putting in preventative measures
before deployment rather than after-the-fact
would be prudent.

Larry
--
http://larry.masinter.net

-----Original Message-----
From: Shawn Steele [mailto:Shawn.Steele@...]
Sent: Wednesday, November 25, 2009 12:12 PM
To: "Martin J. Dürst"
Cc: Larry Masinter; PUBLIC-IRI@...; Pete Resnick; Ted Hardie
Subject: RE: phishing in IRIs

> What I am saying is that spoofing of IRIs with the domain name part is a much greater problem than spoofing with IRIs in the rest of the IRI.

I don't disagree with that :) But you extended it (I thought) to "the IDNs in the IRIs", which I don't see any evidence of. Phishers abuse domain name certainly, but they still use all-ASCII.

> The IETF has a tradition of putting security considerations in the main document, not as a separate document.

I'm concerned that to fully address the issues of security considerations in IRIs would take quite a bit of space. I'm also concerned that some aspects might be lead to a lot of discussion, as there probably isn't one "right" way to handle IRI security. An effective security document for IRIs IMO would be comparable to trying to address how to handle spam in email. So maybe the WG could consider mentioning some security concerns in the main document and provide a further document that describes security in more detail? For example, I think the discussion of safe-yourbank.com IRIs is interesting, but I'm not sure the main document is the right place for all of that discussion.

-Shawn

RE: [Uri-review] Fwd: [Fwd: Registration of 'oid:' as a URI/IRI scheme]

2009-11-26T11:25:20Z

The new IRI-bis draft proposes reserving the "authority" field in IRIs for internationalized domain names, and using punicode (rather than hex-encoded UTF8) in the transation of IRIs to URIs. This is to prevent alternative paths which sometimes would wind up presenting percent-encoded UTF8 of original host names to DNS.

A review of existing registered URI schemes didn't find any where this would be a problem, but if "oid:" were to use "//" for a non-DNS "authority" field (which it does not currently) it would cause problems.

(Discussion of policy on public-iri@..., please)

Larry
--
http://larry.masinter.net

-----Original Message-----
From: Graham Klyne [mailto:GK@...]
Sent: Wednesday, November 25, 2009 11:18 PM
To: j.larmouth@...
Cc: "Martin J. Dürst"; Lisa Dusseault; Martin Duerst; uri-review@...; larmouth@...; Larry Masinter
Subject: Re: [Uri-review] Fwd: [Fwd: Registration of 'oid:' as a URI/IRI scheme]

John Larmouth wrote:
> I am sure we understand the issues and implications of comparison, and
> for our purposes they are acceptable. On the // issue, we have
> oscillated on that over the production process, and our latest advice is
> as recorded in 03 - we use only "oid:/Alerting/....." for example.
> There *is* a use for relative OIDs (and they *are* defined in the
> Recommendations | International Standards), but we were *not* planning
> on allowing those in the IRI scheme, as establishing the context for the
> relative OID/IRI is more difficult than in a controlled protocol
> environment.

(Scheme reviewer hat OFF...)

I would say that if you use a URI form with '/'s, you cannot prevent others from
using relative forms in ways defined generally for URIs, which may or may not be
the same as (or isomorphic with) relative forms defined by the OID
Recommendations. I think it could be confusing if two different ways of doing
relative OIDs were potentially available (even if not actually blessed by the
specification).

The URI spec provides some guidelines for establishing the context for relative
URIs, but these are necessarily partial for the reasons you indicate.

My comment about using '//' was because the first path-segment of your OID URI
seemed to perform the same function as the "authority" in a URI. I can't tell
if it truly does.

Martin: from my recollection of when I looked into this previously, I think
it's OK for a URI scheme using the relative path constructs to *not* have an
authority component, hence is not *required* to start with '//'. My take would
be that the leading '//' should be used if[f] the following element is an
authority in the (loosely defined) sense of RDF 3986.

#g

Re: HTML CHANGE PROPOSAL; change definition of URL to normative reference to IRIBIS

2009-11-25T13:13:01Z

On Nov 25, 2009, at 6:42 AM, Larry Masinter wrote:

>> I'm assuming this is intended as a Change Proposal for ISSUE-56 urls-
>> webarch (mentioning that so the tracker finds it).
>
> Yes, the "HTML CHANGE PROPOSAL" was addressed to
> http://www.w3.org/html/wg/tracker/issues/56
>
>
>> My understanding of this proposal is that you'd like the proposed
>> changes to be made once the IRI Working Group forms and has a draft
>> with all the necessary definitions. If that understanding is correct,
>> then I think we should take up this proposal once those preconditions
>> have been met. If I have misunderstood, then please clarify.
>
> No. Waiting for preconditions would create an unfortunate and
> unnecessary deadlock.

When you say "deadlock", do you mean the formation of the IRI WG or
the drafting of the IRI spec are somehow blocked on changes to HTML5?

> The current internet draft
> http://tools.ietf.org/html/draft-duerst-iri-bis-07
>
> is sufficient to consider the HTML WG proposal now. Any definition
> thought "necessary" and not contained in -07 should be treated
> as an issue/change proposal to it.

I'm glad to hear the IRIbis draft is ready to be referenced. I'll put
your Change Proposal on the tracking list. However, I think that to
fully meet the requirements for a Change Proposal it may require a
little bit more detail.

HTML5 has, as far as I can tell, exactly 4 references to
[WEADDRESSES], all in this section: <http://dev.w3.org/html5/spec/Overview.html#terminology-0
>. All URL processing is based on those 4 references. It should be
simple to state what specifically should replace them. Specifically,
the HTML5 draft references the definition for a "valid Web Address",
the definition for an "absolute Web Address", the algorithm to "parse
a Web Address" into components, and the algorithm to "resolve a Web
Address" relative to a base. Can you please update the Change Proposal
to mention the specific references to draft-duerst-iri-bis-07 that
should replace these references? Ideally these would refer to specific
defined terms, algorithms or grammar productions in the IRIbis draft.

Providing specific details for the requested change is a required part
of a Change Proposal, as stated here: <http://dev.w3.org/html5/decision-policy/decision-policy.html#change-proposal
>.

> draft-duerst-iri-bis-07 is the proposed starting point of the IRI
> working group, and changes or additions should be made as the
> result of participation, discussion and consensus on the
> public-iri@... mailing list, including the participation
> of members of the browser vendor and broader HTML community.

Sounds good.

Thanks,
Maciej

RE: phishing in IRIs

2009-11-25T12:12:29Z

> What I am saying is that spoofing of IRIs with the domain name part is a much greater problem than spoofing with IRIs in the rest of the IRI.

I don't disagree with that :) But you extended it (I thought) to "the IDNs in the IRIs", which I don't see any evidence of. Phishers abuse domain name certainly, but they still use all-ASCII.

> The IETF has a tradition of putting security considerations in the main document, not as a separate document.

I'm concerned that to fully address the issues of security considerations in IRIs would take quite a bit of space. I'm also concerned that some aspects might be lead to a lot of discussion, as there probably isn't one "right" way to handle IRI security. An effective security document for IRIs IMO would be comparable to trying to address how to handle spam in email. So maybe the WG could consider mentioning some security concerns in the main document and provide a further document that describes security in more detail? For example, I think the discussion of safe-yourbank.com IRIs is interesting, but I'm not sure the main document is the right place for all of that discussion.

-Shawn

how browsers transform URLs

2009-11-25T11:49:36Z

We are happy to announce the open source release of Client URL
Internet Emission Sniffer (CURLIES).

The purpose of this project is to see how browsers and other Web
clients transform URLs as they access them. This is done by generating
a number of test cases and having each client load the test files
while running a packet sniffer to capture the network emissions.
Reports are then generated from the sniffed packets, highlighting
differences between the clients. For further details and test results,
see the project site:

http://code.google.com/p/curlies/
http://code.google.com/p/curlies/wiki/DesignDocumentForClientURLInternetEmissionSniffer

I have also written some recommendations for browser developers. While
the HTML5 Web Addresses spec already describes how to parse and
resolve a URL, I have taken this a step further to include the DOM
interfaces that can be used to obtain IRIs, URIs and Unicode host
names.

http://code.google.com/p/curlies/wiki/RecommendationsForBrowserDevelopers
http://www.w3.org/html/wg/href/draft

Happy Thanksgiving!

Erik

PS Many thanks to Shaopeng Jia (Google), who did most of the actual work.

Re: phishing in IRIs

2009-11-25T07:55:12Z

> What I am saying is that spoofing of IRIs with the domain name part is a much greater problem than spoofing with IRIs in the rest of the IRI.

Agreed, but even that statement doesn't really convey the relative frequency of problems. In terms of spoofs:

In the vast majority of the cases, people just don't look at IRIs at all.
In the vast majority of the remainder, average people don't understand the syntax enough to find problems -- and can't be expected to. (http://safe-wellsfargo.com, or http://secure.ru/amazon.com, or the other examples Shawn gave, or the papers found on Stephane's posting)
In a relatively small number of cases there are problems with visually confusables... and a smaller number yet of those with IDNs: spoofs with "rn" vs "m" are much more common than those with Cyrillic 'a', and those are much more common than esoteric symbols.

Mark

On Wed, Nov 25, 2009 at 02:25, "Martin J. Dürst" <duerst@...> wrote:

Hello Shawn,

On 2009/11/25 4:44, Shawn Steele wrote:

We're getting WAY off topic.

I agree.

Is there a BCP for IRI security?

No. The IETF has a tradition of putting security considerations in the main document, not as a separate document.

So trying to spoof the path is indeed another technique, but in most
cases, it doesn't work because there is a single authority in control of
all the paths on the same domain. So that's why I'm saying that the main
place where spoofing can happen in IRIs is the IDN part.

But that only works for you because you know how paths work!

Yes. I don't think we actually disagree.

What you are saying is that spoofing because people don't look at IRIs/URIs at all is a much greater problem than spoofing with lookalikes and the like. I fully agree.

What I am saying is that spoofing of IRIs with the domain name part is a much greater problem than spoofing with IRIs in the rest of the IRI.

Overall, it's like you saying that one kilometer is bigger than one meter, and me saying that one millimeter is greater than one micrometer.
(sorry I don't have a non-metric equivalent for these examples)

Regards, Martin.

It's been pretty well demonstrated that the average user doesn't know those things, and, indeed, LEGITIMATE businesses even (mis?)use the system for their convenience or to outsource ads or mail lists or whatnot.

Those of us with kids in this country are likely to know about a place called "Check E Cheese's". And it's a lot cheaper with a coupon. If I visit http://www.chuckecheese.com/, then I'll have the opportunity to subscribe to an email list and get spammed with coupons periodically. Those coupons are sent from "Chuck E. Cheese's [cecmail@...]". There's absolutely no way to verify that these are connected. Ruby's is worse. Rubys.com sends mail from rubys.fbmta.com with links to the same (rubys.fbmta.com). Toysrus.com gets you to toyrus.shoplocal.com. I've also seen them in the form client.adfirm.com or adfirm.com/client, no clue if the client/adfirm relationship is legitimate. Lots of online stores use a 3rd party for checkout. At least I can recognize yahoo or paypal, but for others I'd have to make a leap of faith.

Heck, I got an internal survey about Microsoft which some team had contracted out to an external vendor. No clue if it was a legitimate internal survey or someone phishing for intelligence about Microsoft. The mail didn't even come from an internal address. (Yea, I contacted the group to find out if it was legit, but they were surprised I even bothered).

Do you ever follow those links? I often do. Of course if it's a bank or its going to end up asking for payment or other info I usually end up retyping the original URL (toysrus.com instead of toysrus.shoplocal.com) and follow links from there, but would the average person bother?

When users are trained that any sort of weird variation in the URL is OK, so long as it says my vendor in their somewhere, then there's not much we can do about it, and IDN is completely irrelevant so far as changing security goes.

I used to try to contact marketing departments when I noticed that they sent customers to URLs that weren't obviously in their control, but they don't seem to care. Until that's fixed IDN homographs don't even come close to being interesting. I don't even think we can fix it because clearly they don't seem to care enough to follow a BCP for IRIs even if one existed. If I can't even get Microsoft security to be interested in this problem, how do we expect every retailer to bother?

Note that in every one of these cases the domain could've been fixed. Instead of toysrus.shoplocal.com, there's no reason they couldn't have pointed shoplocal.toysus.com to their vendor's server and used that instead. Similarly the mail could be from vendor.client.com. My internal survey could've redirected from a trusted internal server to the external one.

-Shawn

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

RE: HTML CHANGE PROPOSAL; change definition of URL to normative reference to IRIBIS

2009-11-25T06:42:44Z

> I'm assuming this is intended as a Change Proposal for ISSUE-56 urls-
> webarch (mentioning that so the tracker finds it).

Yes, the "HTML CHANGE PROPOSAL" was addressed to
http://www.w3.org/html/wg/tracker/issues/56

> My understanding of this proposal is that you'd like the proposed
> changes to be made once the IRI Working Group forms and has a draft
> with all the necessary definitions. If that understanding is correct,
> then I think we should take up this proposal once those preconditions
> have been met. If I have misunderstood, then please clarify.

No. Waiting for preconditions would create an unfortunate and
unnecessary deadlock. The current internet draft
http://tools.ietf.org/html/draft-duerst-iri-bis-07

is sufficient to consider the HTML WG proposal now. Any definition
thought "necessary" and not contained in -07 should be treated
as an issue/change proposal to it.

draft-duerst-iri-bis-07 is the proposed starting point of the IRI
working group, and changes or additions should be made as the
result of participation, discussion and consensus on the
public-iri@... mailing list, including the participation
of members of the browser vendor and broader HTML community.

Larry
--
http://larry.masinter.net