Subject: Comments on draft-ietf-httpbis-content-disp-00.txt

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 11 Sep 2010 23:57:10 +0200

Hi,

  In http://www.ietf.org/id/draft-ietf-httpbis-content-disp-00.txt
section 3.3:

   "filename" and "filename*" behave the same, except that "filename*"
   uses the encoding defined in [RFC5987], allowing the use of
   characters not present in the ISO-8859-1 character set
   ([ISO-8859-1]).  When both "filename" and "filename*" are present, a
   recipient SHOULD pick "filename*" and ignore "filename" - this will
   make it possible to send the same header value to clients that do not
   support "filename*".

Some points on this: starting a paragaph with lower case is poor form,
add something like "The parameters ...". "Behave" is probably also not
the right word to use.

As for ISO-8859-1, RFC 2616 only said what to use for non-ISO-8859-1 in
headers, it never defined that headers are otherwise ISO-8859-1 and it
is unfortunately common to use other encodings there (the draft notes
the opposite in fact.) It would be better to refer to "most of Unicode"
or something like that instead to avoid suggesting ISO-8859-1 should
work fine.

I don't think sending exactly the same value would make it useful to
send both parameters, it would rather seem filename could be a fallback,
which would imply a different, perhaps less sophisticated, value.

So perhaps something along the lines of "The parameters 'filename' and
'filename*' differ only in ... wider repertoire of characters ... fall-
back ..."

In section 4 the examples should be indented. It might be better to use
a value like "example" in place of "foo".

In appendix C.4 there is "should we mention the implementation status of
actual UAs in a RFC?" I think it would be better to submit such reports
under <http://www.ietf.org/iesg/implementation-report.html> and possibly
include a pointer in the RFC.

regards,
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Sun, 12 Sep 2010 21:41:44 +0200

Hi Björn,

thanks for the feedback; comments inline.

> add something like "The parameters ...". "Behave" is probably also not

OK.

> or something like that instead to avoid suggesting ISO-8859-1 should

Actually it *does* work fine. I'm open to changing the spec to say it 
should be avoided, though.

> which would imply a different, perhaps less sophisticated, value.

Not sure what you're referring to here. Please elaborate.

> 'filename*' differ only in ... wider repertoire of characters ... fall-

I now have:

    The parameters "filename" and "filename*" differ only in that
    "filename*" uses the encoding defined in [RFC5987], allowing the use
    of characters not present in the ISO-8859-1 character set
    ([ISO-8859-1]).  When both "filename" and "filename*" are present, a
    recipient SHOULD pick "filename*" and ignore "filename" - this will
    make it possible to send the same header value to clients that do not
    support "filename*".

> a value like "example" in place of "foo".

Done. (*)

> under<http://www.ietf.org/iesg/implementation-report.html>  and possibly

Thanks for the pointer (I wasn't aware of that page, or forgot in the 
meantime).

Best regards, Julian

(*) Current edits at 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-content-disp-latest.html>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 15 Sep 2010 08:01:56 +0200

>Not sure what you're referring to here. Please elaborate.

It did not occur to me someone might send different responses based on
whether they believe the client supports `filename*`, so I read the text
as referring to the values of the parameters and not the whole header.
Clearly using the same value for the two parameters is not useful.

>    make it possible to send the same header value to clients that do not

I still think the reference to ISO-8859-1 should be avoided (refer
instead to characters not normally allowed in HTTP headers, or simply
a wider repertoire of characters) and the last part should emphasize
that the filename parameter can be used as fallback value for older
clients, to avoid the confusion above if nothing else.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Sep 2010 15:39:52 +0200

> Clearly using the same value for the two parameters is not useful.

Ack. This text was written by somebody who had to use UA sniffing to do 
this in the past.

New text:

    ([ISO-8859-1]).

    Many user agent implementations predating this specification do not
    understand the "filename*" parameter.  Therefore, when both
    "filename" and "filename*" are present in a single header field
    value, recipients SHOULD pick "filename*" and ignore "filename".
    This way, senders can avoid special-casing specific user agents by
    sending both the more expressive "filename*" parameter, and the
    "filename" parameter as fallback for legacy recipients (see Section 4
    for an example).

Does this make things clear?

> clients, to avoid the confusion above if nothing else.

I haven't changed yet the wording with respect to ISO-8859-1, mainly 
because it reflects what's actually implemented.

That being said, I wouldn't be surprised that we'll get more feedback on 
this during the Last Calls. For now, I'll record this as a potential 
clarification: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/243>.

Best regards, Julian