Scripting Media Types
draft-hoehrmann-script-types-03
Yes
(Scott Hollenbeck)
No Objection
(David Kessens)
(Mark Townsley)
(Russ Housley)
Note: This ballot was opened for revision 03 and is now closed.
Scott Hollenbeck Former IESG member
Yes
Yes
()
Unknown
Brian Carpenter Former IESG member
(was Discuss)
No Objection
No Objection
(2005-06-23)
Unknown
I cleared my DISCUSS because Scott H is raising the general point of how obsolete media types should be marked in the registry on the ietf-types list. Two comments from review by David Black (1) While I have no objection to this being an Informational RFC, its use of MUST/SHOULD/MAY to specify implementation requirements for scripting reads like a Standards Track RFC, and so I wonder why it's not intended to be a Proposed Standard RFC. I've cc:'d Scott Hollenbeck (responsible APP AD) on the theory that he knows something about this that I don't. (2) I found one quibble in the Security Considerations section: A host environment can provide facilities to access external input, scripts that pass such input to the eval() function can be vulnerable to code injection attacks; scripts must protect against such attacks. Given that the script itself may be an external input, requiring the script to provide protection may put the fox in charge of guarding the henhouse (with apologies to Bjoern for my lack of knowledge the corresponding German idiom is for putting the thief in charge of guarding the jewels). There should be some mention of limiting the script's ability to access external input and/or execute it (e.g., limiting the script's access to a trusted environment or domain(s), or the domain from which the script was obtained, or even disabling eval() if the script accesses something that seems questionable if executed).
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
(2005-06-22)
Unknown
I decided not to block on this, since I think the document is largely documenting existing practice, but I am very concerned by this: o If the value of a charset parameter is illegal, implementations MAY recover from the error by ignoring the parameter or MAY consider the character encoding scheme unsupported. First, I don't think two MAYs here really helps interoperability much. Second, ignoring an illegal charset parameter on a script seems like a pretty bad idea. You seem likely to get garbage, and it's not clear what the benefit of attempting to process the garbage would be. Also, it seemed to me that the document did not quite give a default charset, since it wanted to leave the interpretation of an absent charset parameter up to local knowledge. That's too bad, as it really would help.