RE: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt

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@xxxxxxxxxxx>
<http://www.dankohn.com>  <tel:+1-650-327-2600>

-----Original Message-----
From: Philipp Hoschka [mailto:ph@xxxxxx]
Sent: Monday, 2000-10-23 08:53
To: Dan Kohn
Cc: ietf-xml-mime@xxxxxxx
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.