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

[Dan Kohn <[e-mail]>]

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 (which
was just approved by the IESG this week!), and that text has significantly
less detail and justification.

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.

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), it would be worth
specifying that explicitly in your registration.

		- dan
--
Dan Kohn <mailto:[e-mail]>
<http://www.dankohn.com>  <tel:[phone]>

-----Original Message-----
From: Philipp Hoschka [mailto:[e-mail]]
Sent: Sunday, 2000-10-22 11:26
To: Dan Kohn
Cc: [e-mail]
Subject: Re: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt


Dan,

thanks for the review. See replies below

Dan Kohn a écrit :
> 
> Philipp, could I suggest that you review
> <http://www.imc.org/draft-murata-xml>, which is expected to shortly
replace
> RFC 2376.  Specifically, I would strongly recommend changing your
> application to application/smil+xml, and quoting the appropriate sections
of
> RFC 2376bis by reference rather than by repeating the text.

For smil+xml, see Murata's recount of history. I added a paragraph
explaining why we chose not to use the postfix for this one.

As for the sections quoted by repeating the text: The sections were 
included by reference in earlier versions of the draft. I seem to
remember
that I decided to repeat the text either because somebody explicitly 
suggested doing this, or because somebody got it wrong when implementing
from an earlier draft. In any case, the intention is to make sure that
people actually follow these rather involved rules when implementing
application/smil.

If this doesn't convince you, I can consider taking them out again.
Before doing so, however, I would need to do some research on whether 
this wasn't something that was explicitly requested by somebody else.

> Thanks for considering this.
> 
>                 - dan
> --
> Dan Kohn <mailto:[e-mail]>
> <http://www.dankohn.com>  <tel:[phone]>
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, 2000-10-17 03:47
> Subject: I-D ACTION:draft-hoschka-smil-media-type-05.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
>         Title           : The application/smil Media Type
>         Author(s)       : P. Hoschka
>         Filename        : draft-hoschka-smil-media-type-05.txt
>         Pages           : 4
>         Date            : 16-Oct-00
> 
> This document specifies the Media Type for version 1 of the
> Synchronized Multimedia Integration Language (SMIL 1.0). SMIL allows
> integrating a set of independent multimedia objects into a
> synchronized multimedia presentation.
> 
> A RL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-05.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-hoschka-smil-media-type-05.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [e-mail].
> In the body type:
>         "FILE /internet-drafts/draft-hoschka-smil-media-type-05.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.