Subject: conformance languages (issue 278), was: Last Call: <draft-ietf-httpbis-content-disp-06.txt> (Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)) to Proposed Standard

From: Julian Reschke <[email-masked]>
Date: Tue, 01 Mar 2011 16:50:42 +0100

Hi Barry,

we're tracking this as 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/278>.

On 01.03.2011 00:33, Barry Leiba wrote:
> I'm sorry not to have posted this during WGLC, but I didn't notice it until now:
>
> The document uses the phrase "are advised [to do something]" in two
> places (the penultimate paragraph in Section 4.3, and the beginning of
> Appendix D).  I suggest that we either switch to 2119 language
> ("SHOULD [do something]") or insert a sentence into section 2 that
> explains the normative meaning of "ADVISED" that we intend (as being
> softer than SHOULD).  Even if we want to leave it fluffy, we should
> probably make it clear that we're intentionally leaving it fluffy.[1]
>
> Barry
>
> [1] Apologies to Cullen, in case he has trademarked "fluffy".

Or maybe we should revise RFC 2119 :-).

I agree that this needs tuning; but I'd rather not invent a new keyword 
for that.

The appendix D 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-content-disp-06.html#rfc.section.D>) 
isn't meant to be normative; thus I believe leaving it the way it is 
ought to be ok.

With respect to 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-content-disp-06.html#rfc.section.4.3>, 
I believe we really should say "SHOULD" in all the three last items:

    o  Many platforms do not use Internet Media Types ([RFC2046]) to hold
       type information in the file system, but rely on filename
       extensions instead.  Trusting the server-provided file extension
       could introduce a privilege escalation when the saved file is
       later opened (consider ".exe").  Thus, recipients need to ensure
       that a file extension is used that is safe, optimally matching the
       media type of the received payload.

-> SHOULD ensure

    o  Recipients are advised to strip or replace character sequences
       that are known to cause confusion both in user interfaces and in
       filenames, such as control characters and leading and trailing
       whitespace.

-> SHOULD strip or replace

    o  Other aspects recipients need to be aware of are names that have a
       special meaning in the file system or in shell commands, such as
       "." and "..", "~", "|", and also device names.

-> ...and SHOULD and ignore or substitute these names...

...the last one is a bit tricky, as what's special really depends on the 
operating system...

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Tue, 1 Mar 2011 11:00:13 -0500

> I agree that this needs tuning; but I'd rather not invent a new keyword for
> that.

Sensible.

> isn't meant to be normative; thus I believe leaving it the way it is ought
> to be ok.

OK.

> I believe we really should say "SHOULD" in all the three last items:

It all works for me.  Thanks, and again, I'm sorry to pipe in late.

Barry

---

From: Martin Rex <[email-masked]>
Date: Tue, 1 Mar 2011 18:06:33 +0100 (MET)

> ...the last one is a bit tricky, as what's special really depends on the 

Everything around filenames can be very tricky --
especially with Filesystems like Microsoft Windows NTFS.

Seemingly sufficient (but factually quite incomplete) guidelines
are going to cause more problems that they solve.

Think of a Filename such as  ".\ badfilename.txt ::$DATA"

that does not appear to have leading or trailing space characters.

If you do anything like this in a Windows CMD.EXE:

    echo hi there > ".\ badfilename.txt ::$DATA"
    echo hi there > "\ badfilename.txt ::$DATA"
    echo hi there > " badfilename.txt ::$DATA"
    echo hi there > "badfilename.txt ::$DATA"

then you obtain files that Windows Explorer can NOT cope with.
(you can only delete them from the command line, e.g.  del *badfilename.txt* )

-Martin

---

From: Julian Reschke <[email-masked]>
Date: Tue, 01 Mar 2011 19:34:58 +0100

On 01.03.2011 18:06, Martin Rex wrote:
> ...
> ...

Do you have a specific suggestion about what the spec SHOULD say?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Mar 2011 15:11:40 +0100

> It all works for me.  Thanks, and again, I'm sorry to pipe in late.

Proposed change for the three items in 4.3:

       later opened (consider ".exe").  Thus, recipients SHOULD ensure

    o  Recipients SHOULD strip or replace character sequences that are
       known to cause confusion both in user interfaces and in filenames,
       such as control characters and leading and trailing whitespace.

    o  Other aspects recipients need to be aware of are names that have a
       special meaning in the file system or in shell commands, such as
       "." and "..", "~", "|", and also device names.  Recipients SHOULD
       ignore or substitute names like these.

(see 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/278/i278.diff>).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 06 Mar 2011 12:13:11 +0100

> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/278/i278.diff>).

...applied with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1152>; I plan to 
submit a -07 draft soon after LC ends.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Mar 2011 09:44:06 +0100

On 28.02.2011 23:43, The IESG wrote:
>
> The IESG has received a request from the Hypertext Transfer Protocol Bis
> WG (httpbis) to consider the following document:
> - 'Use of the Content-Disposition Header Field in the Hypertext Transfer
>     Protocol (HTTP)'
>    <draft-ietf-httpbis-content-disp-06.txt>  as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2011-03-14. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> ...

Hi there,

I received one LC comment from Barry, and a quite some feedback from the 
IESG.

As a result, I tuned some of the spec text and submitted a new draft 
(-08), see 
<http://trac.tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-httpbis-content-disp-06.txt&url2=http://tools.ietf.org/id/draft-ietf-httpbis-content-disp-08.txt> 
for the diffs compared to the IETF LC version (which was -06).

Best regards, Julian