On Tue March 29 2005 14:03, ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
[I wrote]
Section 4.2.1 might benefit from a clarification of "text" as
communication in a natural language intended primarily for human
consumption (perhaps something like the description in BCP 18).
Perhaps, but this text was very carefully crafted after a long
debate and I don't feel comfortable changing it.
I recall the debate :-). BTW, I like the wording under the application
media types discussion, which may be sufficient to cover the case of
scripting (computer programming) languages.
Good. It's always hard to know if the balance between specificity and generality
is right in these things.
As "Mac OS" is a somewhat obscure platform, and as the registration
template provides for "Mac OS" "Type codes", a normative reference
providing information on those codes would be appropriate in
section 4.11.
Suggestions welcome as to what an appropriate reference would be.
Hmmm. As we've discussed, that may be difficult. Unfortunately,
the vendor (Apple) doesn't seem to provide much useful information
(at least not online); the best I was able to find after hours of
searching was http://docs.info.apple.com/article.html?artnum=55381.
OK, let's run with that. We'll see what the RFC Editor thinks. Besides, it
gives me the chance to try out some xml2rfc features I just learned about on
the xml2rfc list ;-) FWIW, the cite I came up with looks like this:
<reference anchor="MacOSFileTypes"
target="http://docs.info.apple.com/article.html?artnum=55381";>
<front>
<title>Mac OS: File Type and Creator Codes, and File Formats</title>
<author>
<organization>Apple Computer, Inc.</organization>
</author>
<date month="June" year="1993"/>
</front>
<seriesInfo name="Apple Knowledge Base" value="Article 55381"/>
</reference>
IIRC you suggested http://cocoa.mamasam.com/COCOADEV/2001/09/1/11740.php.
It is -- as you noted -- unclear whether either of those URIs would be
acceptable to the RFC Editor
(http://www.rfc-editor.org/policy.html#policy.urls).
On inspection I think this one is too much about file extensions and too little
about file type codes to be useful.
By the way, a note to the effect that in order to avoid confusion,
four-letter words indicating lack of a code (e.g. "none") should
be avoided, might be advisable (since the codes themselves
consist of four characters).
Good idea. Added. I also pointed out that there are similar concerns
for file extensions.
The section 6 procedure (modified from RFC 2048 section 2.4) doesn't
seem to be effective in practice. While the additional step of review
by the media types reviewer might be an improvement, specific
statements regarding necessary IANA actions should probably be included
in the IANA Considerations section (the present IANA Considerations
section seems somewhat sparse).
Well, if the goal is to make the procedure more effective, the last thing we
need to do is nail it down more precisely. This has been shown over and over
and over again to be an inhibiting factor in this general space, not a
facilitator.
What really needs to happen here is for someone to issue a comment on a
registration and let the process run. If this turns up a problem we can
examine
it and amend the process accordingly. And if it doesn't, if it ain't
broke...
In any case, I am extrelemy reluctant to twiddle with this further in the
absence of any "running code".
We've discussed this off-list based on a security-related comment on
a registered type; let's see what happens.
Agreed.
Section 8 is somewhat unclear regarding standards tree registration
requirements. It states "Registrations in the standards tree MUST
satisfy the additional requirement that they originate from the
IETF itself or from another standards body recognized as such by the
IETF". Ignoring the part about "another standards body", there is
some ambiguity regarding standards tree registrations using IETF
procedures (i.e. published RFCs). The ambiguity arises from the
phrase "originate from the IETF itself", coupled with the fact that
"the IETF" is not a well-defined set. It is unclear whether or not
an individual submission RFC (as distinct from an RFC which is the
product of an IETF working group) qualifies for registration of a
media type or subtype in the standards tree.
The vagueness here is intentional since it isn't clear who gets to make the
call as to whether or not some other organization is a standards body or
not.
Hmmm. That wasn't my concern. Rather it's about individual submissions
(as distinct from WG items) as standards tree registrations (a real
case that is in process, albeit under the current RFC 2048 procedure)
and the case of a revision to an RFC-based registration for the purpose
of adding comments (e.g. revising security considerations; see below).
OK, now I understand. I don't think there is, or should be, a real distinction
between WG documents and individual submissions. I expect the IESG, in its role
"central scrutinizer", will look at individual submissions more closely (I know
I did when I was on the IESG), but that's a matter of IESG policy, not
something we should write down in a registration document.
It is worth noting that in practice a fair number of media types in the
standards tree have been come about through individual submissions.
Several of the references are amended by other RFCS (e.g. RFC 2231
amends normative reference RFC 2045) or by errata maintained by the
RFC Editor. Additional references to those amending RFCs and
errata should probably be included.
I disagree. I don't think a reference to RFC 2231 is necessary. I also think
including references to errata is neither necessary or appropriate.
Moreover,
including them opens a huge can of worms as to whether or not an errata
can be
normative. This is a sleeping dog I'm going to let lie.
Well 2231 section 7 amends applicable parts of RFC 2045.
Unfortunately, some developers seem to be unaware of that amendment
or of the erratum to 2231 section 7.
Hmm. I'd agree with this if there was a reference to this aspect of RFC 2045 in
the current document but there wasn't one. OTOH, perhaps there should be such a
reference in regards to how the ABNF in this document and the MIME relate to
each other. I'll add one, which of course will require an informative reference
to the RFC 2231 amendment.
And of course there's the
pending erratum for the 2045 ABNF affecting tspecials (thanks, BTW).
No problem. Sorry it took so long.
My opinion regarding the "can of worms" is that an approved erratum
amends the affected RFC, but does not change whether the RFC reference
is normative or informative. It does, however, pose a problem
regarding how a reference to the errat[um,a] are/is presented in a
draft or RFC (again, I suspect I'm about to find out, as I have a
draft in process which references 2045, 2231, and errata). The RFC
Editor has a search engine that will display errata for a specified
RFC, but unfortunately it doesn't provide a URI that can be used to
reference the RFC-specific errata. If such a URI were available, the
cleanest solution would be to provide RFC-specific URIs of the same
category (normative vs. informative) as the referenced RFC.
I'm going to take a wait-and-see appproach on this one...
A list of the specific media types which are affected by ownership
and change control principles in the draft should probably be included
in Appendix A.
It might be nice but I don't think such a list is necessary, so unless
someone
else produces it I'm not going to add it.
I'm not planning to produce it. My concern is that if an existing
registration in the standards tree requires an RFC update to add a
comment, and the process for doing so gets bogged down in administrivia
such as new boilerplate required, changes required to the bulk of the
registration template (because it would be a new RFC and therefore no
longer "grandfathered"), etc. that such comments simply won't happen.
In the case of security-related issues, that would be a shame. I think
a reasonably light-weight mechanism for commentary in such a case (as
distinct from a registration template which is not part of a published
RFC, and which therefore (theoretically at least) could be amended by
IANA without much fuss) would be desirable, but I am at a loss to
suggest a specific mechanism. [our off-list discussion of
message/partial is an example of this specific scenario; it's not
merely hypothetical]
FWIW, I have every intention of incorporating your comments on message/partial
into the next revision of the base MIME specification. I like to think we a
reasonable job overall on the initial set of security considerations, but this
is one we clearly missed.
In any case, I'll be sending in an updated draft in a bit that incorporates all
these changes. Thanks for reading this specification so carefully.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf