[websec] #16: lack of explanatory text and no justifications for the normative language

[websec issue tracker]

#16: lack of explanatory text and no justifications for the normative language

 Filing this issue on behalf, as submitted by Pete Resnik:

 (no objection to progressing *a* MIME sniffing draft in the IETF as an
 RFC.)
 "He does have an objection to progressing this MIME sniffing draft in its
 current form. It has an algorithm with no explanatory text and no
 justifications for any of the normative language it gives. That's not a
 protocol. Surely the author and other folks who think this work is
 important know *why* the algorithm is written the way it is. All that I am
 asking is for that knowledge be written in the document to explain. Then,
 if someone is in an environment that is different from the one anticipated
 by the draft, be it more restrictive or less, they can figure out what the
 right thing to do is and the draft can be updated appropriately. The
 current form simply doesn't allow that."


 [Tobias]
 To discuss or to do:
 add some more justification and explanation text at RFC2119 statements?

-- 
--+
 Reporter:  tobias.gondrom@…  |  Owner:  draft-ietf-websec-mime-sniff@…
 Type:  defect| Status:  new
 Priority:  major |  Milestone:
Component:  mime-sniff|Version:
 Severity:  Active WG |   Keywords:
  Document|
--+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #15: Clarify scope of web sniffing

[Tobias Gondrom]

personally I like the scope beyond "http-only".
#1 The mis-configured header website part is in my view the main use case.
But scenarios where no content-type can be transmitted in the header, 
like other protocols (e.g. ftp), filesystem, etc. seem to make sense too.


So in general I would support a broader scope.

Just my 5cents, Tobias



On 17/10/11 22:26, websec issue tracker wrote:

#15: Clarify scope of web sniffing

  This issue may be broken down into several (is X in scope?) but this issue
  is meant to cover the overall question to start with.

  The introduction to the document cites the existence of mis-configured web
  content served via HTTP as the primary justification for "sniffing".

  However, the document itself covers many situations beyond misconfigured
  web content.

  * web sites where content-type values are syntactically correct but
  believed to be different from what was intended (because the content
  itself doesn't match)

  * situations where HTTP protocol content-type is syntactically incorrect,
  duplicate, malformed.

  * situations where no content-type is supplied at all via HTTP.

  * situations where the content is not being delivered via HTTP at all, but
  via other protocols.

  There are a number of these situations, including web accesible material
  delivered via ftp:, file: (on thumb drives?). The internet-draft is
  currently normatively required by a W3C recommendation on zip packaging,
  for example.

  So the basic question is: what is the scope? The "bug" in the
  specification is that the introduction and justification don't match the
  apparent intent of the scope of the body.



___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec