Re: "HTTP for Web Browsers and Servers"

Do you think that it would be able to take a substantial amount of the  
material in 2616 into a separate document?

My concern is that writing such a beast from scratch is a pretty big  
undertaking, when we already have BIS and the security property docs  
on our plate. Are you volunteering? :)


On 25/01/2008, at 2:14 AM, Larry Masinter wrote:

>
> What do you think about a separate document for "HTTP for Web  
> Browsers and
> Servers" that talks about charset and EOL for HTML and text types,  
> warnings,
> login dialogs, etc.?
>
> Target BCP instead of (Draft) Standard.
>
> It would be a way of removing some of these topics from the HTTP  
> standard
> while keeping them as IETF official specifications.
>
> Larry
>
>
>> -----Original Message-----
>> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg- 
>> request@w3.org]
>> On Behalf Of Adrien de Croy
>> Sent: Thursday, January 24, 2008 12:21 AM
>> To: Mark Nottingham
>> Cc: HTTP Working Group
>> Subject: Re: security impact of dropping charset default
>>
>>
>>
>> Mark Nottingham wrote:
>>>
>>> Are you saying that you're against adding a sentence or two to
>>> Security Considerations about this issue? So far, I've seen pretty
>>> strong support for doing so from a variety of people.
>>
>> I'm not against warning people about security issues, however I think
>> HTTP needs to take a stand with respect to where the boundaries of  
>> its
>> responsibility lie.  E.g. by making comment on security issues
>> unrelated
>> to the protocol itself, it should take pains to avoid being seen to  
>> be
>> accepting any responsibility for what happens to content whilst being
>> processed by a user agent.
>>
>> Such warnings would perhaps be best put in another place, i.e
>> guidelines
>> for content processing of UAs.  Such a document certainly I would
>> support being referenced by the HTTP RFC.
>>
>> If this is the only issue, then it could be expedient to cover it in
>> HTTP RFC, but I'd make it clear that it's nothing to do with HTTP
>> itself.  If it's not the only issue then where to draw the line?
>>
>> My POV is one of a proxy developer.  For UA or server developers,  
>> they
>> are forced anyway to deal with these issues as part of other non HTTP
>> (protocol) functions in their products.  UAs already heuristically
>> surmise content types and character sets even regardless of (what
>> should
>> be MIME-) headers (in many cases done to cope with poorly configured
>> servers).  Servers likewise have a human somewhere telling them or
>> setting rules for content type and possibly char set for the  
>> resources
>> they serve.
>>
>> Proxies don't have this luxury.  They can only realistically forward
>> entity headers untouched.  I'd hate this charset issue to become a
>> requirement for proxies to sanitize entity headers.
>>
>> Regards
>>
>> Adrien
>>
>
>
>


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

Received on Wednesday, 30 January 2008 09:50:00 UTC