ietf
[Top] [All Lists]

Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP

2005-03-31 09:19:18
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.
 
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.
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).

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).

Section 5.4 references RFC 2026 regarding decisions made by the
media types reviewer, but RFC 2026 does not contain any text
specifically regarding media types review.  RFC 2026 section 6.5
discusses conflict resolution and has three parts, none of which
seem apropos to media type review (6.5.1 Working Group disputes,
6.5.2 [IESG] Process Failures, and 6.5.3 Questions of Applicable
Procedure) [publication of the draft as-is as a BCP might raise
a question of applicable procedure].  At minimum, some clarification
(regarding which section(s) of RFC 2026 is meant to apply) seems
necessary.

It is not necessary for RFC 2026 to have text specifically dealing with the
case of appealing a reviewer decision. RFC 2026 specifies what's necessary to
appeal something, and that's sufficient. The fact that RFC 2026 also deals 
with
several specific sorts of appeals and why they might arise is not relevant.

I see no real reason to add anything here, but I'll make the reference 
specific
to section 6.5.4 (which describes the actual appeals procedure).

6.5.4 discusses content and timing, but doesn't address to whom (IESG
as a body, IESG/IETF chair, IAB, ISOC).  I don't anticipate problems,
but I mentioned the issue for completeness.  I've had my say; I'll
leave it to you, the IESG, and/or other commenters to discuss and
decide whether to further tweak the wording.
  
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.
 
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).

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.  And of course there's the
pending erratum for the 2045 ABNF affecting tspecials (thanks, BTW).

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.

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]

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf