RE: mime-web-info 6.1 feedback

I've read the email below over several times, and I'm not sure
whether or not you want a change to the current document.

I guess I'm a little slow here, can you help out?
Which wording do you want a rewrite of? Any suggestions of
what it should say instead?

Larry
--
http://larry.masinter.net


-----Original Message-----
From: Eric J. Bowman [mailto:eric@bisonsystems.net] 
Sent: Monday, November 01, 2010 10:45 AM
To: Larry Masinter
Cc: www-tag@w3.org; Adam Barth
Subject: Re: mime-web-info 6.1 feedback

Larry Masinter wrote:
> 
> I was thinking about this, and wonder if the issue is really around
> the security considerations for sniffing and privilege escalation...
> 

I don't think so, or at least that wasn't my concern.  I think it's a
fundamental question of Web architecture:  where to draw the line
between user request and sender intent.  HTTP is stateless, so even if
the application type is known, the context of the request can't be (a
user-agent that's an HTML editor may be in design or preview mode; in a
browser I may right-click on an inline image and request that it be
opened sans markup in its own tab).  In Web architecture, what the user
requested is considered paramount.

So perhaps this is a matter of how to word the current section 3.1.
The definition of a media type can't declare sender intent which would
cause a user-agent to take perhaps exactly the opposite action from
that which the user requested.  If the line is drawn such that image/
jpeg stops at defining a codec without attempting to define that the
sender intends the image to be viewed inline, then the context of the
request doesn't matter -- as well it shouldn't.

Nothing else the document discusses, has anything to do with sender
intent which conflicts with what action the user requested.  IOW, all
other concerns are within scope of what a media type should do; but it
is out-of-scope for a media type to imply that sender intent outweighs
the user's requested action (as represented by browser configuration,
i.e. are PDFs rendered in-place, saved, or rendered in an external app
-- these things are for the user to decide, not the server to dictate).

I think allowing media type definitions to declare that a file should
always be downloaded, even if the user requests it to be rendered,
probably does open a whole can of security worms that's best left
unopened by clearly defining the limits of sender intent well short of
*how* the user-agent should process the payload.

-Eric

Received on Tuesday, 2 November 2010 11:26:39 UTC