The basic processes of IETF standardization would not allow a
non-backward-compatible change to RFC2376bis, so I think there is little
risk and some potential gain in referencing 2376bis. The fact that it has
been "in the making for some while now" is exactly why I would prefer for
any insights it contains not to go to waste. It is your choice, however.
As to approval (which should be announced soon), see the minutes available
at:
http://www.ietf.org/iesg/iesg.2K-10-05
2. The IESG approved publication of XML Media Types
<draft-murata-xml-09.txt> as a Proposed Standard. Steve to send
announcement.
My understanding of the RFC Editor queue is that you could reference 2376bis
in your I-D with a request for them to fill in the correct RFC number, and
that this should not delay your draft (which I believe also needs to go
through Last Call first).
- dan
--
Dan Kohn <mailto:dan(_at_)dankohn(_dot_)com>
<http://www.dankohn.com> <tel:+1-650-327-2600>
-----Original Message-----
From: Philipp Hoschka [mailto:ph(_at_)w3(_dot_)org]
Sent: Monday, 2000-10-23 08:53
To: Dan Kohn
Cc: ietf-xml-mime(_at_)imc(_dot_)org
Subject: Re: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt
Dan Kohn a écrit :
I would strongly suggest an include by reference, as implementation
experience will likely cause further updates to 2376bis at some point. As
an example, you are actually quoting text from RFC 2376, not 2376bis
Citing RFC2376 seems correct, given that RFC 2376 is a stable spec,
wheras
the current internet draft (which you refer to as 2376bis) is not, and
has
been in the making for quite a while now.
Given what you write below, it looks like this has changed recently.
Do you have a pointer to the decision record ? Do you know the RFC
number ? Do you know when it will be published ?
As I said, I am will consider removing the "reference by copy", once
I found out if anybody actually requested reference by copy, and why.
However, I disagree with your argument that an advantage of citing
by reference is that it allows easier updates - the reference will
be to a stable document, and if that document is replaced by
a new document, that doesn't mean that the registration for
application/smil changes as well. Propagating the changes would
require an update of the application/smil document.
...
If people are not willing to look up a referenced RFC, than they probably
won't bother reading the MIME registration RFC in the first place.
As I said, I think there is practical evidence to the contrary.
Also, as specified in Section 7.1 of
<http://www.imc.org/draft-murata-xml>,
we would recommend referring to 2376bis for "specifying magic numbers,
fragment identifiers, base URIs, and use of the BOM". If you decide not
to
do so (e.g., because of non-XPointer fragment semantics),
The fragment semantics of application/smil are compatible with XPointer,
as far as I can tell.
it would be worth
specifying that explicitly in your registration.