Re: Proposal for i111 / i63

Mark Nottingham wrote:
 
> Comments?

You'd bet.

>> New:
>> """
>> Words of *TEXT MUST NOT contain characters from character sets  
>> other than ISO-8859-1 [ISO-8859-1].

>>   TEXT           = %x20-7E | %x80-FF | LWS
>>                  ; any OCTET except CTLs, but including LWS

(1) If you say MUST NOT it implies "I mean it".  And if that is
    the intention permitting %x80-9F is excessively dubious. 
    Therefore you don't mean it, any you can write:

++ Words of *TEXT contain characters from the ISO-8859-1 charset.

No MUSTard, a loophole for "you can try UTF-8, and if it breaks
you own the pieces".

(2) LWS.  This horror will be limited to "FWS minus obs-FWS" in
    ABNF later, is that correct ?  No "apparently empty" lines
    only containing "significant" trailing white space, please.

>> Characters outside of ISO8859-1 MAY be included where the
>> encoded-word rule (as defined in RFC2047, Section 2) is
>> specified.

(3) How about RFC 2231, section 5 ?  It is fine if you say *NO*
    for various reasons (RFC 2231 would be a downref, and nobody
    needs language tags in <encoded-word> for HTTP), but I'd
    like to have that decision on record, just in case.

>> When used in HTTP, encoded-word has no specified length limit.

IMO you could add "and SHOULD NOT be folded".  What do the HTTP
implementation and interop reports say about 65 KB encoded-word,
1 MB, 1 GB, 1 TB ?  Does HTTP offer any header limits at all ?

>> """
>> field-content = <field content>
>> ; the OCTETs making up the field-value,
>> ; according to the syntax specified by the field.

...sneaky :-)

  [no encoded word]
>> 3.3 (Media Types -- parameter values)

That okay ?  I can't tell intuitively.

 Frank

Received on Thursday, 17 April 2008 03:30:07 UTC