W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

RE: IRIs, IDNAbis, and HTTP [i74]

From: Brian Smith <brian@briansmith.org>
Date: Sat, 15 Mar 2008 07:19:05 -0700
To: "'Frank Ellermann'" <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, <ietf-http-wg@w3.org>
Message-ID: <000f01c886a7$893c4cf0$4001a8c0@T60>

Frank Ellermann wrote:
> Brian Smith wrote:
> > You cannot derive "token | quoted-string | encoded-word"
> > from "token | quoted-string".

> > RFC 2047 only talks about how to use encoded-string in RFC 2045 
> > messages with RFC 822 headers, not RFC 2616 messages or RFC 2616 
> > headers.
> 
> AFAIK an RFC 2616 message is a variant of message/rfc822, 
> registered as MIME type message/http.  If MIME RFC 2047 etc. 
> is not more good enough for 2616bis this effort is doomed.  
> "Find something better than MIME while claiming that the 
> result is still related to HTTP/1.1" can't fly.

Even if RFC 2616 messages were message/rfc822 messages (which they
aren't, RFC 2616 has a whole section explaining that they are similar
but different), look at RFC 2047:

    * An 'encoded-word' may replace a 'text' token 

    * comment = "(" *(ctext / quoted-pair
              / comment / encoded-word) ")"

    * phrase = 1*( encoded-word / word )

    These are the ONLY locations where an 'encoded-word'
    may appear.

<phrase> is not used at all in RFC 2616. <text> is not used, there is
<TEXT>. However, <TEXT> is only used in three places:

    * In <quoted-string>, where the RFC 2047 mechanism
      is not allowed (according to RFC 2047)
    * In <comment>, where it doesn't matter
    * In reason-phrase
    * In field-content, but its BNF is broken and not
      is not useful for actually parsing HTTP header
      fields.

So, if we interpret everything very liberally, then the RFC 2047
mechanism is allowed in the reason-phrase and in comments *only*. 

> > Finally, none of them reference RFC 2231
> 
> Updating and fixing the references, the numerous errata, and 
> the horrible syntax, is precisely what this WG tries.

Adding a new requirement for implementations to support RFC 2231 in any
existing headers is not a compatible change. 

> >> RFC 2068 clearly says URI
> [...]
> > RFC 2068 uses sgml-name, not URI.
> 
> | Link = "Link" ":" #("<" URI ">" *( ";" link-param )
> ..........................^^^
> 
> > HTML allows anything that doesn't embed spaces.
> 
> | <!ATTLIST LINK
> |  %attrs;                     -- %coreattrs, %i18n, %events --
> |  charset %Charset; #IMPLIED  -- char encoding of linked resource --
> |  href    %URI;     #IMPLIED  -- URI for linked resource --
> ............^^^
> 
> What are you talking about ?  I'm not aware of a DTD allowing 
> IRI in this place apart from my homebrewn XHTML 1 i18n 

Please re-read what I wrote:

   Atom and HTML 5 (will) allow internationalized link
   relation names, and IRIs as link relation names.

I was talking about the "rel" and "rev" link parameters ("link relation
names"), not the <URI> part:

   relationship   = sgml-name
                  | ( <"> sgml-name *( SP sgml-name) <"> )

Regards,
Brian
Received on Saturday, 15 March 2008 14:19:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:37 GMT