> In the case of the audio/t38 document (RFC 4612), this was written only
> because, if I read RFC 4288 correctly, such a document is needed to register
> a MIME type in the IETF tree.
Then you're not reading the document correctly. For one thing, there isn't an
"IETF tree" any longer - it's now callled the "standards tree". As for
publication requirements, the text is pretty clear:
4.10 Publication Requirements
Proposals for media types registered in the standards tree by the IETF itself
^^^^^^^^^^^^^^^^^^
MUST be published as RFCs. RFC publication of vendor and personal media type
proposals is encouraged but not required. In all cases the IANA will retain
copies of all media type proposals and "publish" them as part of the media
types registration tree itself.
Note the added emphasis - when the IETF has to publish any registrations it
makes in an RFC. This requirement is specific to the IETF, not to other
standards bodies.
As stated previously, standards tree registrations for media types defined in
documents produced by other standards bodies MUST be described by a formal
standards specification produced by that body. Such specifications MUST contain
an appropriate media type registration template taken from Section 10.
Additionally, the copyright on the registration template MUST allow the IANA to
copy it into the IANA registry.
Other standards bodies are in turn enjoined to put their registrations in
whatever sort of formal specifications they produce.
The point here is that registrations in the standards tree have to be formally
published in some way. For the IETF that means they have to appear in an RFC
since that's the formal publication mechanism the IETF has. Other standards
bodies all have their own mechanisms and should be used as appropriate.
Now, since the IESG has to approve these registrations and has considerable
leeway as to the what's allowed, nothing prevents them from asking for a
descriptive RFC for the type if they feel such a document is appropriate. The
obvious case that comes to mind is where an IETF specification and some
specification done elsewhere are intertwined in some way. But this sort of
thing would be an IESG action, not a process requirement.
> In the case of MIME, we could have used a different tree (e.g.,
> audio/itu.t38).
There are really only media types; MIME merely defined the system first. And
ever since separate trees were introduced the rule has always been that
creating a new tree requires standards action. (There's also a very substantial
process specification burden associated with defining a new tree.)
> However, as far as I know, there is no such tree.
Correct. My original plan was to define a "standards tree" separate from the
existing "IETF tree" with a prefix of something like "std." for other standards
bodies to use. This plan was rejected for various reasons and the IETF tree was
renamed to the standards tree instead and other standards bodies were
encouraged to use it.
> Secondly, while it might be easy to get such a tree, there are various SDP
> parameters and other such things the ITU has defined in recommendation
> (e.g., V.150) for which there are no "trees". I like symmetry.
First, definining a tree is perhaps the most difficult activity in this entire
space. The main change in RFC 4288 is the rejiggering of the IETF/standards
tree, and getting this document through the process proved to be a decidedly
nontrivial exercise.
Second, the tree mechanism was very intentionally embedded in the subtype name.
It serves as a visual reminder for people dealing with the type in
specifications and processes. It is not intended to be a structural mechanism
for software to use. So the fact that this isn't structurally visible in
protocols is intentional, and the notion that there's a symmetry issue makes no
sense at all.
Ned
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf