Subject: Content-Disposition next steps

From: Julian Reschke <[email-masked]>
Date: Sun, 07 Nov 2010 14:39:46 +0100

Hi there,

the ongoing discussions are very interesting, as they are relevant to 
most stuff we do in Part 1 through 7 as well.

My take-away is:

- there's disagreement about whether we should require specific handling 
of invalid messages

- if implementers want to do so, they are free to do that in a separate 
informational document

But...

- we should keep in mind that every cycle we spend on this discussion 
keeps us from doing other stuff, and many over here feel that other 
things have a higher priority

- for C-D, the *real* problem isn't lacking interop for invalid 
messages, but lack of interop for *valid* messages

So I'd encourage to de-couple this discussion from the actual 
Content-Disposition spec, and let those who want work on that as a 
separate activity (the question of whether that should become a WG work 
item will be interesting).

I'd like to get C-D to IETF LC as soon as possible, thus get everything 
*else* we can resolve done in the next days.

The currently open issues are at 
<http://trac.tools.ietf.org/wg/httpbis/trac/query?component=content-disp>, 
and I believe this list contains open tickets that can be closed as 
duplicates (Mark?).

Also, I'm going to say that I consider the work on tests, and 
documenting the current UA problems in a single place was a success. We 
got minor problems fixed in Opera and Konqueror, Mozilla is likely to 
improve soon, and the Chrome nightly builds now have RFC 5987 support.

I believe we should continue this work with other header fields, and a 
quite obvious candidate would be "Content-Type", which incidentally has 
two related HTML WG issues 
(<http://www.w3.org/html/wg/tracker/issues/125> and 
<http://www.w3.org/html/wg/tracker/issues/126>).

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 9 Nov 2010 12:53:32 +1100

On 08/11/2010, at 12:39 AM, Julian Reschke wrote:

> Hi there,
> 
> the ongoing discussions are very interesting, as they are relevant to most stuff we do in Part 1 through 7 as well.

Indeed.

> My take-away is:
> 
> - there's disagreement about whether we should require specific handling of invalid messages

Actually, I think we have agreement that it should *not* be required; the current discussion is whether it's useful to specify optional handling, and where that should be done. Does anyone disagree (i.e., think it should be required as part of HTTP)?

> - if implementers want to do so, they are free to do that in a separate informational document

Of course.

> But...
> 
> - we should keep in mind that every cycle we spend on this discussion keeps us from doing other stuff, and many over here feel that other things have a higher priority

Agreed. A considerable amount of time and energy has been spent on this, and the opportunity cost isn't zero. I'd much rather see people producing text, giving feedback, and running tests, rather than going around in circles.

> - for C-D, the *real* problem isn't lacking interop for invalid messages, but lack of interop for *valid* messages

There doesn't have to be just one problem.

> So I'd encourage to de-couple this discussion from the actual Content-Disposition spec, and let those who want work on that as a separate activity (the question of whether that should become a WG work item will be interesting).
> 
> I'd like to get C-D to IETF LC as soon as possible, thus get everything *else* we can resolve done in the next days.

Given that we currently have at least two vendors (probably more, I'm just going by public information) working on implementing the draft now (at least partly triggered by us going to WGLC), and it's possible we'll get feedback from them, I'm inclined to pause for a *small* number of weeks, to see if we can learn anything else. 

During that time, Adam can come up with a proposal for error handling, which we'll consider at the end of that period. 

Adam, you can do that either openly on the mailing list, or as a design team (i.e., work with other interested parties separately and bring a proposal forward when you think you're ready). I'd encourage you to do it openly on the list, to get constructive feedback from others as you go (thereby increasing your chances of delivering something people will accept). However, if Adam does this, I'd ask people not to question *why* it's being done. 

If it's done in time, and if we gather consensus on it, it can go into C-D as an optional appendix. If it's not ready in time, it can be published (by the WG or separately) on its own. Likewise, if the WG doesn't gain consensus on it, it can be published individually (in the IETF or elsewhere). 

Right now, I'm thinking three weeks -- November 30th (coincidentally, my birthday). This will give us time to re-publish, gain consensus (or not) and go to IETF Last Call by the end of the year.

Adam, is that workable for you? 

> The currently open issues are at <http://trac.tools.ietf.org/wg/httpbis/trac/query?component=content-disp>, and I believe this list contains open tickets that can be closed as duplicates (Mark?).

I'll go through those on-list separately.

> Also, I'm going to say that I consider the work on tests, and documenting the current UA problems in a single place was a success. We got minor problems fixed in Opera and Konqueror, Mozilla is likely to improve soon, and the Chrome nightly builds now have RFC 5987 support.

Indeed, and I'd like to make sure that people understand -- Julian has put in an exceptional effort here, and should be recognised for driving this to conclusion.

> I believe we should continue this work with other header fields, and a quite obvious candidate would be "Content-Type", which incidentally has two related HTML WG issues (<http://www.w3.org/html/wg/tracker/issues/125> and <http://www.w3.org/html/wg/tracker/issues/126>).

Please do file bugs as appropriate.

Regards,

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

---

From: Adam Barth <[email-masked]>
Date: Tue, 9 Nov 2010 00:29:05 -0800

> Adam, is that workable for you?

Yes, that should be enough time.

Thanks,
Adam

---

From: Julian Reschke <[email-masked]>
Date: Tue, 09 Nov 2010 09:47:00 +0100

On 09.11.2010 02:53, Mark Nottingham wrote:
> ...

I agree it should not be required.

(Note that even HTML5 allows recipients to reject non-conforming HTML)

> ...

Indeed; but there are pressing problems and less pressing problems, IMHO.

> ...

Not sure.

We will have to produce a new draft, request publication and go to AD 
review before we get to IETF LC anyway.

What's wrong with processing additional feedback during IETF LC?

> Right now, I'm thinking three weeks -- November 30th (coincidentally, my birthday). This will give us time to re-publish, gain consensus (or not) and go to IETF Last Call by the end of the year.

I have my doubts that we will go to IETF LC this year if we do not 
request publication much earlier.

Also, I'm planning to revise RFC 5987 and C-D for publication as Draft 
Standards as soon as possible (the interop research has been done 
already, and sufficient implementations *are* there). Maybe it would 
make sense to address the error handling discussion in that revision.

>> The currently open issues are at<http://trac.tools.ietf.org/wg/httpbis/trac/query?component=content-disp>, and I believe this list contains open tickets that can be closed as duplicates (Mark?).
>

Thanks.

> Indeed, and I'd like to make sure that people understand -- Julian has put in an exceptional effort here, and should be recognised for driving this to conclusion.

Merci.

>> I believe we should continue this work with other header fields, and a quite obvious candidate would be "Content-Type", which incidentally has two related HTML WG issues (<http://www.w3.org/html/wg/tracker/issues/125>  and<http://www.w3.org/html/wg/tracker/issues/126>).
>

Clarifying: with "this work" I meant doing research and filing bugs 
against the implementations, not the spec :-)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 11 Nov 2010 13:50:53 +0100

OK,

here's a summary of what changes have been done so far compared to draft 
03 -- these are not published as draft yet; see diff-marked version at 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-content-disp-latest-from-previous.diff.html> 
and full text at 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-content-disp-latest.html>:

1) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/243>

Added a minor clarification that ISO-8859-1 *only* works in 
quoted-string (I know Björn is still unhappy, but at least this adds 
more precision).

2) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/252>

Stated that modification-date *is* supported by some UAs (-> Konqueror).

3) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/253>

Clarify implied LWS rule.

4) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/258>

Rephrase a sentence not to use passive voice.

5) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/260>

We agreed to WONTFIX this.

6) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/261>

We agreed to WONTFIX this.

7) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/262>

Mark has proposed to close this without changes; do we need more feedback?

8) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/263>

Clarified the subsection that describes somewhat the percent-unescaping 
strategy of IE and Chrome.

9) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/264>

Clarified that the RFC5987 language tagging isn't very useful for filenames.

10) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/265>

Clarified that this spec is not about C-D in HTTP *payloads*.

The following issue remains open:

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/259>

...and I have made a rough proposal in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0450.html>.

I think the current changes are an improvement over draft -03, and would 
like to submit it soonish (independently of what we do with respect to 
issue 259).

Feedback appreciated, Julian

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 11 Nov 2010 11:13:52 -0800

> (Note that even HTML5 allows recipients to reject non-conforming HTML)

Optional defined error recovery seems like a good step, so I am hesitant to rock the boat, but would it be a plausible future direction to say implementations must either use the defined error recovery or reject (with a clearly defined meaning of reject, i.e. completely ignore that header field, or discard the whole message, or whatever)?

Regards,
Maciej

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 12 Nov 2010 14:29:15 +1100

On 09/11/2010, at 7:47 PM, Julian Reschke wrote:

> We will have to produce a new draft, request publication and go to AD review before we get to IETF LC anyway.
> 

Because this is WGLC, and we've heard some browser vendors -- who, as much as anyone, are members of this WG -- express that they'd like to see some more text in.

This draft is also a bit of a special case, in that it didn't receive much discussion in the WG before going to LC. That at least in part speaks to the quality of the work you've done, but I want to make sure we treat feedback appropriately before progressing.

> I have my doubts that we will go to IETF LC this year if we do not request publication much earlier.

Perhaps. Do you have reason to believe a few weeks is going to make a difference?

> Also, I'm planning to revise RFC 5987 and C-D for publication as Draft Standards as soon as possible (the interop research has been done already, and sufficient implementations *are* there). Maybe it would make sense to address the error handling discussion in that revision.

Ack.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 12 Nov 2010 14:31:05 +1100

Doubtful, because there are always going to be non-browser cases where other behaviours make sense.

I've raised it before, but there's a need out there for a "what is a browser" spec that pulls in all of the different specs a browser has to conform to. Doing that would give an opportunity to also say what optional features have to be implemented by a browser (such as this).

Regards,