Subject: i94, was: Does Reason-Phrase allow LWS?

From: Julian Reschke <[email-masked]>
Date: Thu, 03 Apr 2008 16:10:50 +0200

Frank Ellermann wrote back in December:
> I think what you're looking for is:
> 
>    Reason-Phrase  = *( VCHAR / WSP )

Fine with me.

There's an overlap with issue 74 
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/74>) though -- are 
we ok with taking out the reference to the TEXT rule (with its 
implications on I18N)?

BR, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 3 Apr 2008 17:45:04 +0200

> Fine with me.

<joke> Four months later, RFC 5198 hates HTAB </joke>
Seriously, maybe *( SP / VCHAR ) is now good enough.
 
> There's an overlap with issue 74

I don't understand section 5 in RFC 3987.  Are HTTP
implementors forced to grok IRI comparison ?  What
has this to do with I18N for <Reason-Phrase> ?  For
a say 404 the body can use any language and charset
it likes.

The 2822upd idea of <phrase> is more convoluted, it
is a sequence of <word>s, each word is an <atom> or
a <quoted-string>.

Ignoring <obs-phrase>, <obs-qtext>, and <obs-qp>
the <atom>s and <quoted-string>s are separated by
optional [CFWS].  But the F in CFWS is something we
don't want in <Reason-Phrase>.  

An advantage of the 2822upd <phrase> is that it is
covered by RFC 2047, but that is again designed to
allow folding, not okay for a HTTP <Status-Line>.  

Sanity check, we don't want folding there, right ?

The *TEXT in RFC 2616 is apparently a simplification
of <phrase>, with the twist of allowing Latin-1, or
anything else if 2047-encoded.  

The Latin-1 and MIME mixture in RFC 2616 is strange.
VCHAR is ASCII, for that I know what it means, you
can even throw in =?...?.?...?= constructs.

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Thu, 03 Apr 2008 20:55:11 +0200

Frank Ellermann wrote:
> ...

That's what I'm asking you :-)

> a say 404 the body can use any language and charset

But the Reason-Phrase is not part of the body.

> ...

I don't think so. That's what i94 is about.

 > ...

BR, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 3 Apr 2008 21:29:06 +0200

>> has this to do with I18N for <Reason-Phrase> ?
 
> That's what I'm asking you :-)

LOL.  Okay, then I'd say <Reason-Phrase> used to be a
string of Latin-1 octets carefully avoiding CR and LF.
There could be a Latin-1 IRI in <Reason-Phrase>, but
Latin-1 IRIs are not sexy, unlike KOI8-R IRIs. ;-)

In other words, as long as HTTP headers can't do "raw"
UTF-8 we can ignore IRIs.  Folks wanting them anyway 
find the recipe to transform any IRI into an URI in
RFC 3987.

As soon as it's an URI it's US-ASCII and we can forget
Latin-1 wrt IRIs.  In a <Reason-Phrase> or elsewhere.

Using IRIs or URIs within an in essence unstructured
part of a header field has similar problems as using
IRIs or URIs in text/plain mail or news bodies:  Put
them in angle brackets, maybe use <URL: .. >, or not.

In the case of a header field they could end up in an
2047/2231 <encoded-word>, a seriously bad idea.  But
hopefully not bad enough to talk about it in 2616bis.
I've never seen a 2047/2231 encoded IRI.  

> I don't think so. That's what i94 is about.

Good.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 4 Apr 2008 12:06:44 +1100

The relevance of i74 (at least before that issue got split; the  
relevant issue is now 111) is that it allows RFC2047 encoding  
explicitly.

It'll still match the BNF, of course...

I'm writing a proposal for 111 now; I'll write it in terms of modifying
    Reason-Phrase  = *( VCHAR / WSP )
so that you can proceed with this independently.

Cheers,

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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 4 Apr 2008 12:30:56 +1100

I take that back... from re-reading, it seemed like people were happy  
with just *( VCHAR / WSP ), so I left Reason-Phrase out. If I misread  
this, please respond to my 111 proposal.