On Tue March 15 2005 16:24, The IESG wrote:
> The IESG has received a request from an individual submitter to consider the
> following document:
>
> - 'Scripting Media Types '
> <draft-hoehrmann-script-types-02.txt> as an Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send any comments to the
> iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by 2005-04-12.
Comments on the draft:
Section 2 has the usual comment about 2219 keywords, though "SHALL",
"SHALL NOT", "SHOULD NOT", and "OPTIONAL" appear nowhere else in the
draft, and could be elided from the section 2 list. Not a big deal.
Draft section 4 refers to RFC 3536 for definitions of terms used in
that section. RFC 3536 does not define "source text" or "binary
source text", and 3536's use of "text" is in the context of human
language, whereas the media types defined in the draft are computer
languages. Those media types fit into the media type framework
(draft-freed-media-type-reg-03.txt) as "application" subtypes
exclusively ("languages for 'active' (computational) material"). As
neither "source text" (perhaps meant as "source code"?) nor "binary
source text" are well-defined, the meaning of the entire section 4
is unclear. ["Binary" is also undefined in RFC 3536, though it is
defined in the MIME context in RFC 2045, where that meaning of
"binary" is inapplicable to "text" media types, due to the RFC
2046 sections 4.1.1 and 4.1.2 requirements on line endings for text
media types.] The draft has no mention of the RFC 2046 sect. 4.1.1
requirements for CRLF line endings in text media subtypes. It's
difficult to say what to make of these issues given the unclear
meanings of "source text" and "binary source text".
Section 4.1 refers to RFC 2278 (which has been obsoleted by RFC 2978)
section 3.3. grammar, but makes no mention of registration of charsets.
I.e. "blurfl" matches the RFC 2278 sect. 3.3 charset production, but is
not a registered charset name. Accordingly, "blurfl" would appear to
be a "legal" charset for the purposes of the draft, even though there
is no publicly registered charset with that name. The interoperability
considerations section(s) [extraordinarily sparse in the draft] fail to
mention how an unregistered charset name is to be interpreted. The
issue of charset registration should be addressed, and interoperability
should be carefully considered.
Section 4.2 refers to "charset parameter with a legal value", which in
light of the above is unclear. Setting aside the unclear meaning of
"binary source text" as noted above, specific UTF-* charsets other
than UTF-8 are (as I understand it) incompatible with the RFC 2046
sections 4.1.1, 4.1.2 requirements and cannot be used with text media
types in a MIME context. The incompatibilities with RFC 2046 should
be reviewed.
Section 4.3 has continued ambiguity w.r.t. unregistered charset names.
The security considerations section 5 mentions remote resource
retrieval, but does not note that such retrieval may result in denial
of service (due to self-referential or multi-site looping remote
resource pointers).
Sections 7 & 8 subsections point to RFC 3023 for encoding
considerations; the considerations should be explicitly specified in
the media type registration templates (copying if necessary). There
are no other references to RFC 3023 in the draft; that reference (to
unrelated media types) could be elided.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf