0.26: Bug in text of button

0.26: Bug in text of button

[Jean-Yves Perrier]

I've just got the following button:
[application/msword (PV =?iso-8859-1?Q?r=E9union?= 18-8-98.doc)]

I suppose that the function call to decode =?iso-8859-1?Q?...
is missing

Regards,
-- 
Jean-Yves

Re: 0.26: Bug in text of button

[Lars Magne Ingebrigtsen]

Jean-Yves Perrier <perrier@nagra-kudelski.ch> writes:

> I've just got the following button:
> [application/msword (PV =?iso-8859-1?Q?r=E9union?= 18-8-98.doc)]
> 
> I suppose that the function call to decode =?iso-8859-1?Q?...
> is missing

Nope.  This is malformed.  Quoth RFC2047:

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

   + An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'.

   + An 'encoded-word' MUST NOT appear within a 'quoted-string'.

   + An 'encoded-word' MUST NOT be used in a Received header field.

   + An 'encoded-word' MUST NOT be used in parameter of a MIME
     Content-Type or Content-Disposition field, or in any structured
     field body except within a 'comment' or 'phrase'.

So decoding this would be naughty.

Although I don't understand how one is supposed to use non-ascii chars 
in the C-T header, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: 0.26: Bug in text of button

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>    + An 'encoded-word' MUST NOT be used in parameter of a MIME
>      Content-Type or Content-Disposition field, or in any structured
>      field body except within a 'comment' or 'phrase'.
> 
> So decoding this would be naughty.
> 
> Although I don't understand how one is supposed to use non-ascii
> chars in the C-T header, then.

What is C-T?  Content-Type?  Why would you want to use non-ascii
there?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Thou Who might be our Father Who perhaps may be in Heaven...
                                                -- Roger Zelazny

Re: 0.26: Bug in text of button

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> What is C-T?  Content-Type?

Yes.

> Why would you want to use non-ascii there?

In the parameters.

The button in question was

> [application/msword (PV =?iso-8859-1?Q?r=E9union?= 18-8-98.doc)]

which must be the result of a C-T header reading

Content-Type: application/msword; name="PV =?iso-8859-1?Q?r=E9union?= 18-8-98.doc"

And I think this is invalid.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: 0.26: Bug in text of button

[Jean-Yves Perrier]

Lars wrote:

>> [application/msword (PV =?iso-8859-1?Q?r=E9union?= 18-8-98.doc)]

>Content-Type: application/msword; name="PV =?iso-8859-1?Q?r=E9union?= 18-8-98.doc"

>And I think this is invalid.

It is surely not invalid, but that does not mean
"PV réunion 18-8-98.doc" according the spec,
but really "PV =?iso-8859-1?Q?r=E9union?= 18-8-98.doc"
(+ An 'encoded-word' MUST NOT appear within a 'quoted-string'.)

That is only the way that Outlook encodes filenames with accents in C-T.
And that meaning is given by Outlook.

Therefore that is not a bug in Gnus which is behaving correctly there.

Lars is right, once more :-)
-- 
Jean-Yves

Re: 0.26: Bug in text of button

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> which must be the result of a C-T header reading
> 
> Content-Type: application/msword; name="PV =?iso-8859-1?Q?r=E9union?= 18-8-98.doc"
> 
> And I think this is invalid.

Does this perhaps come under the `phrase' in the context you quoted:

   + An 'encoded-word' MUST NOT be used in parameter of a MIME
     Content-Type or Content-Disposition field, or in any structured
     field body except within a 'comment' or 'phrase'.
                                              ^^^^^^

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
The Lord protects children and fools...  But don't push it.

Re: 0.26: Bug in text of button

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Does this perhaps come under the `phrase' in the context you quoted:
> 
>    + An 'encoded-word' MUST NOT be used in parameter of a MIME
>      Content-Type or Content-Disposition field, or in any structured
>      field body except within a 'comment' or 'phrase'.
>                                               ^^^^^^

No, the C-T value parameter section consists of
"token / quoted-string".  The former is not a phrase, and the latter
is forbidden to contain encoded words by this:

   + An 'encoded-word' MUST NOT appear within a 'quoted-string'.

So I guess there is no way to specify parameters that contain
non-ascii characters.

Quoth RFC2045:

     parameter := attribute "=" value

     attribute := token
                  ; Matching of attributes
                  ; is ALWAYS case-insensitive.

     value := token / quoted-string

     token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
                 or tspecials>


(Some days ago I fetched the complete RFC collection, so I can now
reference *everything*.  :-)  I didn't know that it had grown to
110Mb, though.  (Hm.  Some big Postscript files in there as well.  The
rfc*.txt files only take 94Mb.  :-) ))

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: 0.26: Bug in text of button

[Lars Magne Ingebrigtsen]

Jean-Yves Perrier <perrier@nagra-kudelski.ch> writes:

> Therefore that is not a bug in Gnus which is behaving correctly there.

Stop press!  RFC2184 updates how parameter lists are supposed to be
dealt with.  Not only are they now allowed to contain words encoded in
yet a scheme, but you can also split long values thusly:

     Content-Type: message/external-body; access-type=URL;
      URL*0="ftp://";
      URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"

The encoding is a doozy:

     Content-Type: application/x-stuff;
      title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A

Eek.

Anyway, after reading the rest of the document, it turns out that I
was right after all -- the params are still not allowed to contain
RFC2047-encoded words.  They can only be encoded using this new
scheme, and the attribute name has to end with an "*" to signal this.

Stop press again!  RFC2184 has been obsoleted by RFC2231.  (Scan,
scan.)  Oh, it just clarifies a few things, and adds more beautiful
examples:

   Content-Type: application/x-stuff
    title*0*=us-ascii'en'This%20is%20even%20more%20
    title*1*=%2A%2A%2Afun%2A%2A%2A%20
    title*2="isn't it!"

I really should consult the rfc-index.txt file more...

Anyway (yet again), I'll write functions to parse this.  rfc2231.el,
here I come.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen