OK, Uncle. It was just a passing fancy. RFC-#### it is. Now, Greg, a
question for the chair: Can we get the RFC numbers lined up for all the
various documents (MIME, RFC-CHAR, RFC-HDRS, RFC-Configuration) so that
we can produce a clean text verison that references them by the right
numbers AND make our implementatons produce the right MIME-Version
string?
ietf-822 Chair on....
No. The RFC Editor assignes an RFC number to the document as it goes
out the door. Until the RFC hits the streets, the RFC number is
unknown. No exceptions.
... ietf-822 Chair off
For the above reason, and several others, I prefer a MIME version
number of "1".
Non-standard extensions are only allowed by one mechanism, registering
new content-types, registering new transport encodings (discouraged),
or registering new attributes for existing content-types. This
simple statment seems to be muddled by having an RFC #### as a version.
Say I define rich-audio in a future RFC 2001. Do I indicate my
support of this new content type with a MIME-version 2001? What If I
do not support RFC 2001, but do support RFC 2003, the rich-smell
type? Does declaring MIME-version RFC 2003 mean that support all
RFCs published before 2003?
What if the MIME RFC gets republished from Proposed to Draft, with NO
Substantive technical changes, but a lot of editorial work,
clarifications, and minor BNF fixes. This is still 100% compatable
with RFC ####, (As clarified through the grapevine) but the MIME
number now reflects the RFC number of the original spec!
Please! Use simple version numbers. Version 1 is simple,
understandable, and evolvable. A new version number can be issued
only when the standard is changed. If you use an RFC number, I would
guess that I, GV Inc, can publish a new rfc as informational or
experimental (Non-standard) and begin sending MIME version RFC2320!
At least this is the implication if you use the RFC number. It is not
clear what to do if you get my RFC2320 version! It this new version
MIME compatable, backward compatable, a totally new version?
Version 2 is later than Version 1. It is cannot be clear without
external information that version RFC 2002 is more recent than RFC
1900. For example, RFC 2002 may be an experimental sucessor to MIME,
which was rejected before becoming a proposed standard and is now
historical.
For these reasons I'd like to stick with the recent most precidents
for version identification, a number. If the document changes from
Proposed to Draft, in any substantive way, it gets version 2. If it
gets republished with no technical changes, it gets to keep the
version 1. Cute as RFC #### or RFC XXXX or RFC ALPHA are, they are
just not worth the trouble.
Greg V.