Re: Migration of HTTP to the use of IRIs [queryclarify-16]

Martin,

Let me try and express my concerns in a rather more focussed and
condensed way.

Let us just consider a written URI such as:

http://www.example.org/D%C3%BCrst

This is a perfectly valid RFC2396 URI, and is also identifiable as
using one of the schemes defined in RFC 2616.
Neither of these RFCs tell me what decoding to apply to the two
escaped octets, as we have agreed.

Now suppose your IRI document has become an RFC, but nothing else has
changed.

I still don't know what processing, if any, to apply to the above
URI - it could have been written long before your document came into
force.

So let's suppose we define a new HTTP version, say HTTP/1.2, to cope
with this.

HTTP/1.2 cannot simply issue a decree that henceforth the above URI is
to be assumed to have been generated from an IRI, and that the reverse
processing of your section 3.2 should be applied. That would be
inappropriate processing to apply to pre-existing URIs.

So, I conclude that there *must* be some visible indication that the
sequence originated in an IRI, and therefore that the reverse
processing of 3.2 must be applied.

Here's my solution:

Introduce a pair of additional HTTP schemes 'httpi' (defaulting to
port 80) 'and httpis' (defaulting to port 443) in an update to HTTP -
say HTTP/1.2.

Now we write

httpi://www.example.org/D%C3%BCrst

and the new HTTP/1.2 tells us that the reverse processing of your 3.2
*must* be applied to this URI scheme.

Problem solved.

Of course, there could be be different syntactic arrangements serving
the same purpose, but, essentially, my belief is that, at least in in
the context of HTTP, there *must  be* some kind syntactic indication
that IRIs are involved.

There are some interesting details to define when considering what
goes 'down the wire' in HTTP messages, but that can be considered
later - the essential need can be made simply by considering the
printed URI.

My original eMail was really asking what the HTTP community's own
thinking is on this issue.

Maybe there are no such thoughts and this proposal will 'kick-start'
some action on the rapid take-up of IRIs in HTTP - which is what I
want to promote.


I'll be starting my 6-day vacation 8 hours from now, so any dialog
will be interrupted - sorry!

Chris



"Martin Duerst" replied:

>
> Hello Chris,
>
> Many thanks for your comments on the IRI spec.
>
> I have noted your issue as:
> http://www.w3.org/International/iri-edit#queryclarify-16
>
> More explanations below.
>
> At 23:21 03/06/26 +0100, Chris Haynes wrote:
>
> >Dear Martin / Michel,
> >
> >I'm looking at draft-duerst-iri-04 from the viewpoint of a provider
of
> >web server technology. I'm trying to understand the likely
migration
> >path to the use of IRIs, and I'm concerned that there's a gap I
don't
> >see being filled.
> >
> >It may well be that filling the gap is outside the scope of your
> >Internet Draft, but unless the gap is filled, I fear there may be a
> >_long_ delay before IRIs are adopted where they are most needed.
> >
> >Your section 7.8, Upgrading Strategy, contains some useful thoughts
/
> >advice, which I have summarised to myself as "Don't put in an
> >IRI-aware server until all the resources on the site(s) you serve
are
> >published in IRI".
> >
> >However that's not the problem that concerns me.
> >
> >I'm concerned about the encoding of HTTP GET query strings,
typically
> >carrying text inserted by a user into a browser's form.
>
> You are right that section 7.8 does not address query strings,
> and that it doesn't say so clearly, and that there is otherwise
> not too much about how query strings are supposed to work.
> I have noted this specific aspect of your mail as an issue,
> and will try to update the draft accordingly.
>
>
> >Assume below that "I" am the developer of a web server. (I'm not,
but
> >I advise someone who is).
> >
> >I want to support IRIs as soon as possible. I know that 'out there'
> >are many different makes and releases of browsers; I have no
control
> >over them.
> >
> >As is well known, there is no mechanism in RFCs 2396 / 2616 for
> >indicating the encoding associated with any %hh octet-triplets in
> >URIs.
>
> Agreed.
>
>
> >Unless I've missed something, your draft implies that user agents
> >(browsers) may perform IRI to URI conversion, so that 'my' server
sees
> >an RFC 2396-conformant URI.
>
> Well, they actually have to do this conversion, because HTTP
> does not allow anything else than an URI in the request.
>
>
> >How do I know it is was originally an IRI and that I should apply
the
> >reverse conversions of your section 3.2 before extracting the query
> >name-value pairs?
>
> You don't. Equally well, you don't know whether the name/value
> pairs were in iso-8859-1 (Latin-1), or shift-jis, or whatever.
> HTTP does not help you there at all.
>
>
> >The problem is not 'academic', the vast majority of browser
requests
> >received today which have %hh triplets used encodings other than
> >UTF-8, and these will continue to arrive for the next 20-or-more
> >years.
>
> Well, for query parts, you actually have quite some control over
> what encoding you get the query part back. Already since a few
years,
> browsers send back the query part in the encoding that they received
> the page in. This works quite well. So if you want to have any
> idea of what you get back from a browser, you have to know how
> you send out your pages. And if you use UTF-8 for your pages,
> then you get three main benefits when compared to other encodings:
> - UTF-8 can handle the widest range of characters
> - UTF-8 will bring your GET request in line with IRIs
> - UTF-8 can be checked with very high reliability
>
> For more information, please also see the Q&A page that we put up
> recently:
> http://www.w3.org/International/questions/qa-forms-utf-8.html
>
>
> >You may well answer that the way IRIs are to be applied is to be
> >scheme-dependent; the problem/opportunity  is for the HTTP
RFC2616++
> >community to address.
>
> Well, part of it could be addressed scheme-by-scheme. For example,
> a new scheme could require that only UTF-8 be used in the query
> part. It can also be addressed by other technologies, for example,
> XForms, which requires the use of UTF-8 in the query part of GET
> requests (see
http://www.w3.org/TR/xforms/slice11.html#serialize-urlencode).
>
>
> >I would feel *far* more comfortable if I knew that they were aware
of
> >this and if there were draft proposals visible on this list and
being
> >checked for feasibility and for 'compatibility' with your drafts.
> >I've seen no evidence for this, and you don't appear to
> >cross-reference any related HTTP activity in your draft.
> >
> >
> >It is not beyond the bounds of possibility, for example, that the
HTTP
> >community might conclude that they cannot provide IRI support
unless
> >your RFC-to-be  includes some kind of marker or syntactic
construction
> >within "URIs which were converted from IRIs" which explicitly
> >identifies them as such.
> >
> >In other words it might be found that all IRIs MUST be mapped into
> >some character sequence which IS NOT a 'legal'  URI (by the current
> >RFC2396), so that the receiver knows that the reverse process of
your
> >section 3.2 MUST be applied.
>
> This would mean choosing a different escape convention.
> We considered this years ago, but decided against it.
> Using something that is illegal in an URI would not have
> worked, and would still not work, with the current infra-
> structure.
>
>
> >There are other approaches the HTTP community could take, which
> >_would_ be compatible with your current draft, (and I have my own
> >candidate solution), but surely there should at least be some kind
of
> >'existence proof' or 'feasibility study' by which they agree that
they
> >_can_ work with your proposals before they are finalized?
>
> I hope what I have explained above is enough of an 'existence
proof'.
>
> Please tell me if you don't think so.
>
> Regards,    Martin.
>
>
> >Without some kind of 'roadmap' for HTTP use of IRIs I don't see how
> >anyone can pass final judgement on your draft.
> >
> >Please reassure me by telling me I'm an idiot for not knowing about
> >XXX or not reading YYY.
> >
> >Regards,
> >
> >Chris Haynes
> >
>
>
>

Received on Friday, 27 June 2003 21:24:50 UTC