Skip to main content

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.