Re: Working Group Last Call: draft-ietf-httpbis-content-disp-02

On Sat, Oct 2, 2010 at 4:23 PM, Eric J. Bowman <eric@bisonsystems.net> wrote:
> Adam Barth wrote:
>> I'm not agitating for a change to how RFCs are generally written.  I'm
>> saying that this document defines a profile of an existing protocol
>> element.  The profile is useful to servers.  The profile is not useful
>> for user agents.  The document should be clear about it's scope.
>
> Not answering my questions fails to convince me of your position.  Most
> folks are perfectly capable of generating conformant syntax from this
> spec.  User agents will already interpret conformant syntax correctly.
> The fact that *some* user agents desire to engage in error prevention
> by also interpreting nonconformant syntax which will only be generated
> in a minority of cases, sounds like an extreme edge case, not enough to
> warrant making an incredibly confusing change to the spec to state that
> it "isn't useful for user agents" when in fact it will be, 99% of the
> time.

That's not the change I asked for.

> You've failed to explain to me why browsers can't take a "must
> ignore" approach to nonconformant syntax,

In general, browsers cannot take a "must ignore" approach to
nonconformant syntax for two reasons:

1) Nonconformant syntax is quite prevalent on the Internet.
2) Users have a choice of browsers and choose browsers that work with
their favorite web sites.

Because of (1), ignoring nonconformant syntax will cause a number of
web sites to break.  Because of (2), these broken web sites will drive
customers away, resulting in the browser that adopted this policy
losing marketshare.  For this reason, we observe that popular browsers
are the ones that interpret nonconformant syntax.

... but this is all well-known stuff.

> let alone any rationale
> behind standardizing an error-prevention parsing model instead of
> leaving that up to implementations.

Given that browsers are going to interpret nonconformant syntax, I'd
rather live in a world in which they all did it the same way.  That
world is more predictable, which is better for security, and easier
for new entrants to the market because those new entrants don't need
to reverse engineer existing implementations.  Fewer barriers to entry
means more competition, which means users get a better browser
product.

... but, again, this is all well-known stuff.

>> > What you're suggesting sounds like wholesale change to HTTP,
>>
>> That's not what I'm suggesting.  HTTP is not a profile of another
>> protocol.
>
> But its headers are; they're re-used from MIME just like C-D, so I
> don't see how your concerns about parsing nonstandardized syntax don't
> also apply to *all* HTTP headers regardless of where they're defined,
> not to mention *all* other specs which re-use MIME.  You seem to be
> claiming that ABNF isn't precise enough to spec out one header in one
> protocol (because it fails to define parsing for nonconformant syntax),
> which seems like a concern which applies to all headers across many
> protocols.

We can talk about what HTTP should do another day.  Today we are
talking about the Content-Disposition header.

On Sat, Oct 2, 2010 at 4:31 PM, David Morris <dwm@xpasc.com> wrote:
> On Sat, 2 Oct 2010, Adam Barth wrote:
>> I'm not agitating for a change to how RFCs are generally written.  I'm
>> saying that this document defines a profile of an existing protocol
>> element.  The profile is useful to servers.  The profile is not useful
>> for user agents.  The document should be clear about it's scope.
>
> I'm really confused by your argument ... I have no problem writing a
> parser for input generated by a clear specification as to how the input
> should be generated. That is a sufficient specification for both the
> generator and consumer of the data.

I agree that it's sufficient for the generator, but don't you think
that it's extremely unlikely that the optimal profile of the
Content-Disposition header for generation is exactly the same as the
optimal profile of the Content-Disposition header for consumption?
I'm willing to believe this document contains the former.  I don't
believe it contains the latter.  I would prefer if the document where
upfront about what it contains.

> I really despise people insisting that I decode a parser specification so
> I can figure out how to write my parser.

No one is making that insistence.

> It is not necessary to state that this specification is from the
> perspective of the server. It is a response header. QED from the server.

Unfortunately, servers don't just spam this header off into the void.
Someone wants to consume them!

> If the server generates the header and value as specified, the recipient
> can process it. If the clients insisted on properly formed data, the
> servers would be fixed rather quickly. Interoperability is about doing it
> right, not agreeing on the secret sauce for how to handle garbage.

Are you suggesting that all user agents should implement exactly this
profile of the Content-Disposition header?  I neither believe that is
in their best interest nor do I believe they will do that, which is
why the document should be clear that it's not requiring them to do
so.

Adam

Received on Sunday, 3 October 2010 00:13:27 UTC