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

Martin,

Thanks for the reply.
I'm afraid my concerns are still present.

Brief comments embedded below...

Chris

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

Thanks, but not that I'm not just concerned about query strings. They
were the most obvious example of the need for IRIs which are not coped
with by the proposed Upgrading Strategy.

In other words I find the Upgrading Strategy interesting, but no
substitute for formal specifications which guarantee unambiguous
interworking ;-))


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

That's today, and begs the answer to the question I'm asking.
It is _possible_ that HTTP 1.n (N>1) will be needed to handle IRIs and
that they will have to be distinct from URIs.


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


Agreed. In my view this makes the current escaping useless / dangerous
(see below).



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


I beg to differ.

I just set up a test in which I have a simple form sent using POST.
I use MSIE6 as the client. MSIE has a menu control View-Encoding.

By changing this from "AutoSelect" to one of the specific ones, I can
change the way the data in the form is encoded.

I test it by using the Windows Character Map to select an A-acute.
With auto-select on (and nothing specified in the HTML source), I get
a URL sent which includes
....?data=%C2

If I, the user, manually select UTF-8 in the Encoding menu the browser
sends  ?data=%C3%82

So the encoding used can be modified by the user, so it is not safe.


>
> >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'm not suggesting separate treatment of the query part, I just use
this to highlight part of the IRI which is not under the 'control' of
the site publishing the resource IRIs.  My concern is about the whole
of the IRI/URI process.

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


OK, so someone has to show how my question "How do you know it was
originally an IRI?" is to be answered when there are also 'classic'
URIs around.


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

Sorry, no. reasons above.

>
> 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 17:17:49 UTC