ACTION-308 (part 1) - Updates to Authoritative Metadata

Hello,

Below are proposed updates to the Authoritative Metadata Finding [AuthMeta] to "acknowledge the reality of sniffing":

Regards,

- johnk

(begin proposed changes)

1. 

Section 3.4 What to do when there is no authoritative metadata

Replace:

That is why the HTTP/1.1 specification [RFC2616] states:

"If and only if the media type is not given by a "Content-Type"
field, the recipient MAY attempt to guess the media type via inspection of
its content and/or the name extension(s) of the URI used to identify the
resource."

With:

That is why [HTTPbis] states:

"If the Content-Type header field is not present, it indicates that the sender does not know the media type of the data; recipients MAY either assume that it is "application/octet-stream" or examine the content to determine its type."

SInce the examination of content to determine its type has a certain security risk (see [REF]) it is important that Web agents follow a common and secure algorithm such as [BarthSniff] for determining the content type. 

2. 

Section 4 Overriding authoritative metadata

After paragraph: 

Recipients SHOULD detect inconsistencies between representation data and metadata but MUST NOT resolve them without the consent of the user. Choosing to ignore or override authoritative metadata is only allowed within the Web architecture when the user has given consent.

Add:

In such cases where a recipient ignores or overrides authoritative metadata by examining content to determine its type, the recipient should follow an accepted and secure algorithm such as [BarthSniff] (as noted also in the previous section). 

3. 

References

Add:

[REF] (find a good description of the specific issue)
[HTTPbis] http://tools.ietf.org/id/draft-ietf-httpbis-p3-payload-08.txt
[BarthSniff] http://tools.ietf.org/html/draft-abarth-mime-sniff-03

(end of proposed changes)

Received on Thursday, 31 December 2009 17:43:51 UTC