- From: Larry Masinter <masinter@adobe.com>
- Date: Sat, 30 May 2009 12:15:11 -0700
- To: Sam Ruby <rubys@intertwingly.net>
- CC: "www-archive@w3.org" <www-archive@w3.org>
I hope you can focus the discussion of "feed readers" on "what do the documents say about the scope of normative applicability". I wrote the following, but won't send it to the main list as it's repetitive in some of the points, and I don't have time to edit it down, although it does expand on some of the issues already raised. ------------------------------------- I'm hoping this isn't a "political" discussion, but rather one specifically about the technical scope of applicability of the documents being produced -- what are the categories of applications, what do we call them, and which requirements are applicable to which categories. There are many Internet applications that, for one reason or another, are layered on top of HTTP that are not part of "the web", do not interact with browsers; many of them do not use HTML. Many of them are not standards, but involve HTTP. The question raised -- by Sam for "feed readers", is whether content-type sniffing applies to those services? MUST a feed reader follow the content-type sniffing algorithm? A java program? Or is the scope of applicability narrower than "all applications that use HTTP"? If the scope isn't "all applications that use HTTP", then what is the scope? I think "Either it's useful or not. If it's useful, I'll use it." doesn't address this issue. When evaluating a document for progression as a standard, one of the primary questions to evaluate is: whether it is useful for the scope of applications for which it is defined. If you don't write that down, then you have a document that is ambiguous, and, in the case of content-type sniffing, increases the risk of injection attacks, interferes with security scanners, content filters, and so forth. The entire rationale for writing down the content-type sniffing algorithm was to reduce the ambiguity of when and what sniffing was or wasn't going to be done. Larry -- http://larry.masinter.net
Received on Saturday, 30 May 2009 19:15:52 UTC