Subject: CORRECTION: Please review ietf-draft of SMIL media-type registration
From: ph at w3.org (Philipp Hoschka)
Date: Tue Jan 3 16:22:32 2006

Kari,

good catches !

See inline for more

Kari Pihkala wrote:
> 
> Hi,
> 
> I noticed some inconsistencies with the SMIL namespaces in the
> draft. In section 4:
> 
> All SMIL 2.0 files must also include a declaration of the SMIL 2.0
>    namespace.  This should appear shortly after the string "<smil", and
>    should read 'xmlns="http://www.w3.org/2001/SMIL20/PR/Language"'.

Fixed this to use
http://www.w3.org/2001/SMIL20/Language

as namespace.
 
> However, a different namespace in the end of section 5:
> 
> An example use of this parameter as part of a HTTP GET transaction
>    would be:
> 
>         Accept: application/smil+xml;
>            profile="http://www.w3.org/2001/SMIL20/REC/HostLanguage"

Removed the REC part.

The namespace should be different, I think, since this is the way 
that a client informs a server that it supports SMIL basic.

I'm not sure that people actually use the following URI to
identify SMIL basic, however
http://www.w3.org/2001/SMIL20/REC/HostLanguage

or that anyone uses the "accept" header at all - I'll send a
seperate message to the www-smil list on that.

> Also, either of these namespaces match the one in SMIL 2.0 spec
> (http://www.w3.org/TR/2001/REC-smil20-20010807/smil20-profile.html):
> 13.3.2 SMIL 2.0 Language Conformance
> 
> 5. A document must declare a default namespace for its elements with an
> xmlns attribute on the smil root element with its identifier URI:
> <smil xmlns="http://www.w3.org/2001/SMIL20/Language">
>    ...
> </smil>
> 
> You may want to check these...
> 
>  - Kari
...

From: [email-masked] (Philipp Hoschka)
Date: Tue, 27 Aug 2002 16:02:07 +0200
Subject: CORRECTION: Please review ietf-draft of SMIL media-type registration
References: <[email-masked]>
Message-ID: <[email-masked]>

Kari,

good catches !

See inline for more

Kari Pihkala wrote:
> 
> Hi,
> 
> I noticed some inconsistencies with the SMIL namespaces in the
> draft. In section 4:
> 
> All SMIL 2.0 files must also include a declaration of the SMIL 2.0
>    namespace.  This should appear shortly after the string "<smil", and
>    should read 'xmlns="http://www.w3.org/2001/SMIL20/PR/Language"'.

Fixed this to use
http://www.w3.org/2001/SMIL20/Language

as namespace.
 
> However, a different namespace in the end of section 5:
> 
> An example use of this parameter as part of a HTTP GET transaction
>    would be:
> 
>         Accept: application/smil+xml;
>            profile="http://www.w3.org/2001/SMIL20/REC/HostLanguage"

Removed the REC part.

The namespace should be different, I think, since this is the way 
that a client informs a server that it supports SMIL basic.

I'm not sure that people actually use the following URI to
identify SMIL basic, however
http://www.w3.org/2001/SMIL20/REC/HostLanguage

or that anyone uses the "accept" header at all - I'll send a
seperate message to the www-smil list on that.

> Also, either of these namespaces match the one in SMIL 2.0 spec
> (http://www.w3.org/TR/2001/REC-smil20-20010807/smil20-profile.html):
> 13.3.2 SMIL 2.0 Language Conformance
> 
> 5. A document must declare a default namespace for its elements with an
> xmlns attribute on the smil root element with its identifier URI:
> <smil xmlns="http://www.w3.org/2001/SMIL20/Language">
>    ...
> </smil>
> 
> You may want to check these...
> 
>  - Kari
...

From: [email-masked] (Philipp Hoschka)
Date: Thu, 22 Aug 2002 17:23:43 +0200
Subject: CORRECTION: Please review ietf-draft of SMIL media-type registration
Message-ID: <[email-masked]>

[the previous mail contained a superfluous and inappropriate 
attachment, and an errouneous "reply-to" header - Apologies]

------

This email serves to instantiate the two week discussion 
period on "[email-masked]" of the ietf-draft describing
the SMIL media-type registration. You can find the draft at
http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-10.txt

The expected course of advancement for this specification is:
1. I have notified one of the Application area directors (Ned Freed)
2. Request publication as an Informational RFC as specified:
  ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt
3. Ensure IANA is aware of the publication and posts the registration as 
specified:
  ftp://ftp.isi.edu/in-notes/rfc2048.txt

The changes in this specification since the last version discussed on 
"[email-masked]" include:
1. Registration of application/xml+smil in addition to application/smil
2. Addition of optional "profile" parameter
3. Addition of paragraph describing how to recognize SMIL files by
   looking into the file.

Thank you.

-- 

-Philipp Hoschka

From: ph at w3.org (Philipp Hoschka)
Date: Tue Jan  3 16:22:32 2006
Subject: Please review ietf-draft of SMIL media-type registration
Message-ID: <[email-masked]>

This email serves to instantiate the two week discussion 
period on "[email-masked]" of the ietf-draft describing
the SMIL media-type registration. You can find the draft at
http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-10.txt

The expected course of advancement for this specification is:
1. I have notified one of the Application area directors (Ned Freed)
2. Request publication as an Informational RFC as specified:
  ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt
3. Ensure IANA is aware of the publication and posts the registration as 
specified:
  ftp://ftp.isi.edu/in-notes/rfc2048.txt

The changes in this specification since the last version discussed on 
"[email-masked]" include:
1. Registration of application/xml+smil in addition to application/smil
2. Addition of optional "profile" parameter
3. Addition of paragraph describing how to recognize SMIL files by
   looking into the file.

Thank you.

-- 

-Philipp Hoschka
-------------- next part --------------

                                                             J. Reagle
Internet-Draft                                             W3C/LCS/MIT
Expires: October 2002                                        June 2002

              application/xenc+xml Media Type Registration
                    draft-reagle-xenc-mediatype-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html. 
   
   This Internet-Draft will expire on October 22, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document describes a media type (application/xenc+xml) for use
   with the XML Encryption specification.

Table of Contents

    1. Discussion of this Document
    2. Introduction
    3. application/xenc+xml Registration
    4. References
    5. Author's Address
    6. Full Copyright Statement

 

Reagle, J.                 Expires October 2002                 [Page 1] 

Internet-Draft           XML Encryption Media-Type              June 2002 

1. Discussion of this Document

   Please send comments to [email-masked]. To subscribe, send a
   message with the body 'subscribe' to [email-masked]. The
   mailing list is publicly archived at
   http://lists.w3.org/Archives/Public/xml-encryption/ .

2. Introduction

   The XML Encryption Syntax and Processing document [XENC] specifies a
   process for encrypting data and representing the result in XML. The
   data may be arbitrary data (including an XML document), an XML
   element, or XML element content. The result of encrypting data is an
   XML Encryption element which contains or references the cipher data.

   The application/xenc+xml media type allows XENC applications to
   identify XENC documents for processing. Additionally it allows
   applications cognizant of this media-type (even if they are not XENC
   implementations) to note that the media type of the decrypted
   (original) object might a type other than XML.

   This media-type is only used for documents in which the XENC
   EncyptedData and EncryptedKey element types appear as the root element
   of the XML document. XML documents which contain XENC element types in
   places other than the root element can be described using facilities
   such as [XML-schema] or [StLaurent].

3. application/xenc+xml Registration

   This is a media type registration as defined in Multipurpose Internet
   Mail Extensions (MIME) Part Four: Registration Procedures [MIME-REG]

   MIME media type name: application

   MIME subtype name: xenc+xml

   Required parameters: none

   Optional parameters: charset

     Same as charset parameter of application/xml as specified in RFC
     3023 [XML-MT] or the most recent specification that supersedes it.

   Encoding considerations:

     Same as charset parameter of application/xml as specified in RFC
     3023 [XML-MT] or the most recent specification that supersedes it.

   Security considerations:

     Security considerations include many of those described in the

Reagle, J.                 Expires October 2002                 [Page 2] 

Internet-Draft           XML Encryption Media-Type              June 2002 

     Security Considerations of [XENC].

   Interoperability considerations: none

   Published specification: [XENC].

   Applications which use this media type:

     XENC is device-, platform-, and vendor-neutral and is supported by
     a range of Web applications.

   Additional Information:

     Magic number(s): none

     Although no byte sequences can be counted on to consistently
     identify XENC documents, they will be XML documents in which the
     root element's QName's LocalPart is 'EncryptedData' with an
     associated namespace name of 'http://www.w3.org/2001/04/xmlenc#'.
     The application/xenc+xml type name MUST only be used for data
     objects in which the root element is from the XENC namespace.

     File extension(s): .xml

     Macintosh File Type Code(s): "TEXT"

   Person & email address to contact for further information:

     Joseph Reagle <[email-masked]>

     XENC Working Group <[email-masked]>

   Intended usage: COMMON

   Author/Change controller:

     The XENC specification is a work product of the World Wide Web
     Consortium. The W3C and the W3C XENC Working Group have change
     control over the specification.

4. References

   Glossary
          RFC 2828. Internet Security Glossary. Informational. R Shirey.
          2000
          http://www.ietf.org/rfc/rfc2828.txt

   HTTP
          RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1. Internet
          Official Protocol Standards. J. Gettys, J. Mogul, H. Frystyk,
          L. Masinter, P. Leach, T. Berners-Lee. June 1999.

Reagle, J.                 Expires October 2002                 [Page 3] 

Internet-Draft           XML Encryption Media-Type              June 2002 

          http://www.ietf.org/rfc/rfc2616.txt

   KEYWORDS
          RFC 2119: Key words for use in RFCs to Indicate Requirement
          Levels. Best Current Practice. S. Bradner. March 1997.
          http://www.ietf.org/rfc/rfc2119.txt

   MIME
          RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part
          One: Format of Internet Message Bodies. Standards Track. N.
          Freed & N. Borenstein. November 1996.
          http://www.ietf.org/rfc/rfc2045.txt

   StLaurent
          Registration of xmlns Media Feature Tag. S. St.Laurent, and I.
          Graham. Draft.
          http://simonstl.com/ietf/draft-stlaurent-feature-xmlns-02.txt

   XENC
          XML Encryption Syntax and Processing. D. Eastlake, and J.
          Reagle. W3C Candidate Recommendation, 2002.
          http://www.w3.org/TR/2002/CR-xmlenc-core-20020304/

   XML
          Extensible Markup Language (XML) 1.0 (Second Edition). T. Bray,
          J. Paoli, C. M. Sperberg-McQueen, E. Maler. W3C Recommendation,
          October 2000.

   XML-MT
          RFC 3023: XML Media Types. Informational. M. Murata, S.
          St.Laurent, D Kohn. January 2001.
          http://www.ietf.org/rfc/rfc2376.txt

   XML-NS
          Namespaces in XML. T. Bray, D. Hollander, A. Layman. W3C
          Recommendation, January 1999.
          http://www.w3.org/TR/1999/REC-xml-names-19990114

   XML-schema
          XML Schema Part 1: Structures D. Beech, M. Maloney, N.
          Mendelsohn. W3C Recommendation, May 2001.
          http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
          XML Schema Part 2: Datatypes. P. Biron, A. Malhotra. W3C
          Recommendation, May 2001.
          http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

5. Authors' Address

   Joseph M. Reagle Jr., W3C
   Massachusetts Institute of Technology
   Laboratory for Computer Science

Reagle, J.                 Expires October 2002                 [Page 4] 

Internet-Draft           XML Encryption Media-Type              June 2002 

   NE43-358, 200 Technology Square
   Cambridge, MA 02139
   Phone: + 1.617.258.7621
   Email: [email-masked]

6. Full Copyright

   Copyright (C) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of developing
   Internet standards in which case the procedures for copyrights defined
   in the Internet Standards process must be followed, or as required to
   translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
   WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>From [email-masked]  Thu Aug 22 17:23:43 2002
From: ph at w3.org (Philipp Hoschka)
Date: Tue Jan  3 16:22:32 2006
Subject: CORRECTION: Please review ietf-draft of SMIL media-type registration
Message-ID: <[email-masked]>

[the previous mail contained a superfluous and inappropriate 
attachment, and an errouneous "reply-to" header - Apologies]

------

This email serves to instantiate the two week discussion 
period on "[email-masked]" of the ietf-draft describing
the SMIL media-type registration. You can find the draft at
http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-10.txt

The expected course of advancement for this specification is:
1. I have notified one of the Application area directors (Ned Freed)
2. Request publication as an Informational RFC as specified:
  ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt
3. Ensure IANA is aware of the publication and posts the registration as 
specified:
  ftp://ftp.isi.edu/in-notes/rfc2048.txt

The changes in this specification since the last version discussed on 
"[email-masked]" include:
1. Registration of application/xml+smil in addition to application/smil
2. Addition of optional "profile" parameter
3. Addition of paragraph describing how to recognize SMIL files by
   looking into the file.

Thank you.

-- 

-Philipp Hoschka

From: [email-masked] (Philipp Hoschka)
Date: Thu, 22 Aug 2002 14:42:55 +0200
Subject: Please review ietf-draft of SMIL media-type registration
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.
--------------3E057BDBA78E6604561A8263
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This email serves to instantiate the two week discussion 
period on "[email-masked]" of the ietf-draft describing
the SMIL media-type registration. You can find the draft at
http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-10.txt

The expected course of advancement for this specification is:
1. I have notified one of the Application area directors (Ned Freed)
2. Request publication as an Informational RFC as specified:
  ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt
3. Ensure IANA is aware of the publication and posts the registration as 
specified:
  ftp://ftp.isi.edu/in-notes/rfc2048.txt

The changes in this specification since the last version discussed on 
"[email-masked]" include:
1. Registration of application/xml+smil in addition to application/smil
2. Addition of optional "profile" parameter
3. Addition of paragraph describing how to recognize SMIL files by
   looking into the file.

Thank you.

-- 

-Philipp Hoschka
--------------3E057BDBA78E6604561A8263
Content-Type: text/plain; charset=iso-8859-1;
 name="draft-reagle-xenc-mediatype-00.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="draft-reagle-xenc-mediatype-00.txt"

--------------3E057BDBA78E6604561A8263--

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:32 2006
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <[email-masked]>
References: <000f01c23f27$f6330b50$06432099@masinter> <000f01c23f27$f6330b50$06432099@masinter>
Message-ID: <4.2.0.58.J.20020820111249.03c13680@localhost>

Hello Aaron, dear RDF Core WG,

On [email-masked] and some related list, we were just looking
at http://www.w3.org/TR/xmlenc-core/#sec-MediaType which containes
some instances of text like this:

    Same as ... of application/xml as specified in RFC 3023[XML-MT]
    or the most recent specification that supercedes it.

There seemed to be general agreement that a moving target is
not a good idea.

Josef Reagle told us that he got that text from:
http://www.aaronsw.com/2002/rdf-mediatype.html

I wanted to tell you that you may want to fix this.

Regards,   Martin.

At 14:47 02/08/19 -0400, Joseph Reagle wrote:
>On Thursday 08 August 2002 06:07 pm, Larry Masinter wrote:
> > # Optional parameters: charset
> > #  Same as charset parameter of application/xml as
> > #  specified in RFC 3023 [XML-MT] or the most recent
> > #  specification that supersedes it.
> >
> > I admit I was a little confused on this one, and misread
> > what it said. However, I don't understand
> > "or the most recent specification that supersedes it",
> > though, since a specification may supercede RFC 3023
> > but not be appropriate for a reference to a particular
> > section.
>
>I'm happy to eliminate that text as I oppose those sort of references in
>general. In this case, I was merely following what I could see the rdf
>folks doing for a similar type of registration:
>   http://www.aaronsw.com/2002/rdf-mediatype.html
>

From: [email-masked] (Martin Duerst)
Date: Tue, 20 Aug 2002 11:19:58 +0900
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <[email-masked]>
References: <000f01c23f27$f6330b50$06432099@masinter> <000f01c23f27$f6330b50$06432099@masinter>
Message-ID: <4.2.0.58.J.20020820111249.03c13680@localhost>

Hello Aaron, dear RDF Core WG,

On [email-masked] and some related list, we were just looking
at http://www.w3.org/TR/xmlenc-core/#sec-MediaType which containes
some instances of text like this:

    Same as ... of application/xml as specified in RFC 3023[XML-MT]
    or the most recent specification that supercedes it.

There seemed to be general agreement that a moving target is
not a good idea.

Josef Reagle told us that he got that text from:
http://www.aaronsw.com/2002/rdf-mediatype.html

I wanted to tell you that you may want to fix this.

Regards,   Martin.

At 14:47 02/08/19 -0400, Joseph Reagle wrote:
>On Thursday 08 August 2002 06:07 pm, Larry Masinter wrote:
> > # Optional parameters: charset
> > #  Same as charset parameter of application/xml as
> > #  specified in RFC 3023 [XML-MT] or the most recent
> > #  specification that supersedes it.
> >
> > I admit I was a little confused on this one, and misread
> > what it said. However, I don't understand
> > "or the most recent specification that supersedes it",
> > though, since a specification may supercede RFC 3023
> > but not be appropriate for a reference to a particular
> > section.
>
>I'm happy to eliminate that text as I oppose those sort of references in
>general. In this case, I was merely following what I could see the rdf
>folks doing for a similar type of registration:
>   http://www.aaronsw.com/2002/rdf-mediatype.html
>

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:32 2006
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <000f01c23f27$f6330b50$06432099@masinter>
References: <[email-masked]>
Message-ID: <4.2.0.58.J.20020809121436.0494fde8@localhost>

At 15:07 02/08/08 -0700, Larry Masinter wrote:
>What it actually says is:
>
># Optional parameters: charset
>
>#  Same as charset parameter of application/xml as
>#  specified in RFC 3023 [XML-MT] or the most recent
>#  specification that supersedes it.
>
>I admit I was a little confused on this one, and misread
>what it said. However, I don't understand
>"or the most recent specification that supersedes it",
>though, since a specification may supercede RFC 3023
>but not be appropriate for a reference to a particular
>section. None of the other references (to XML, DES,
>HTTP, MIME, etc.) have this qualification (that they
>refer to either the current version or anything that
>supersedes it.)

I agree with Larry that a moving target is a bad idea.
At W3C, we use (mostly) dated references, don't we :-).

>I would prefer if the reference were more specific about
>what was the "same": the same syntax, the same set of
>allowable values, the same recommendation for use of
>particular values, the same interpretation of defaults,
>or all of the above. Assuming you mean 'all of the above',
>you could be more explicit:
>
> >  Optional parameters: charset
> >
> >   The allowable and recommended values for, and interpretation
> >   of the charset parameter are identical to those given
> >   for 'application/xml' in section 3.2 of RFC 3023.

I'm not sure this is a good idea. It may lead to
questions such as 'and what about the default value,
is that different',... In other words, trying to list
up all the aspects in which the charset parameter for
application/xenc+xml is the same as that for application/xml
is a futile exercise; not listing any aspects and therefore
making clear that it's everything makes things clearer
and easier, I guess.

>I'm a little concerned about allowing arbitrary charset
>values for the entire application/xml+enc body, though,
>when any encrypted data are always UTF-8 encoded.
>Is it expected that the decryption algorithm do transcoding?
>Shouldn't the behavior of the processor with non-UTF-8
>encoded xml+enc bodies be discussed?

As far as I remember it, encryption does something like
the following:
1) Convert the necessary pieces to UTF-8 (from the encoding
    the document is in)
2) Encrypt the UTF-8 bytes
3) 'Textify' the result of the encryption by using base64

The decryption algorithm has to reverse these steps,
including step 1).

Allowing arbitrary charset values for application/xml+enc
is no problem. First, these values will apply to the
non-encrypted pieces of the document. (I can obviously
have something like <ds:KeyName>????</ds:KeyName>)
Second, once the encrypted part is textified as base64,
that text can still be encoded in us-ascii (which would
be covered by UTF-8) or in ebcdic or utf-16,...

So what I think may make sense is to add something like:

Note: The character encoding denoted by the "charset"
parameter is the character encoding of the resulting XML
document after encoding.

> > > > the 'encoding considerations'
> >
>http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/#sec-MediaType-Regi
>stration
>
>Again, I would prefer if the reference were more explicit
>about exactly was 'the same'.

Again, in general I would disagree here.

>You might even note that because
>encrypted data is encoded in base64 that encrypted data
>may have different encoding requirements than the data
>it replaces.

Good point.

># Published specification: this document.

I think that 'published specification: this document' is quite
dangerous. Assume somebody (that may be IANA) copies the registration
only for their own purposes. Then the reference is lost.

Regards,    Martin.

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:32 2006
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <003601c23e69$c1359e40$06432099@masinter> <[email-masked]>
Message-ID: <4.2.0.58.J.20020809122628.0293cb78@localhost>

At 15:00 02/08/08 -0400, Joseph Reagle wrote:
>The specification says, "This media-type is only used for documents in which
>the EncryptedData and EncryptedKey element types appear as the root element
>of the XML document." I'm not sure how to be much more clear than that?

Well, change "EncryptedData and EncryptedKey" to
"EncryptedData or EncryptedKey". I haven't seen
an XML doc yet with two root elements.

Regards,    Martin.

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:32 2006
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <003601c23e69$c1359e40$06432099@masinter> <[email-masked]>
Message-ID: <4.2.0.58.J.20020809121034.04982160@localhost>

At 15:00 02/08/08 -0400, Joseph Reagle wrote:
>As Ned and Martin point out, the intent is to express the fact that
>"application/xenc+xml" is XML, and consequently shares the same charset and
>encoding semantics/processing as that defined in RFC 3023.

Well, what the spec currently writes is okay, but what
you just write above is not:

The intent is to say that application/xenc+xml shares the same
charset behaviour as application/xml defined in RFC 3023.
(text/xml behaves differently)

Regards,   Martin.

From: [email-masked] (Martin Duerst)
Date: Fri, 09 Aug 2002 12:45:14 +0900
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <000f01c23f27$f6330b50$06432099@masinter>
References: <[email-masked]>
Message-ID: <4.2.0.58.J.20020809121436.0494fde8@localhost>

At 15:07 02/08/08 -0700, Larry Masinter wrote:
>What it actually says is:
>
># Optional parameters: charset
>
>#  Same as charset parameter of application/xml as
>#  specified in RFC 3023 [XML-MT] or the most recent
>#  specification that supersedes it.
>
>I admit I was a little confused on this one, and misread
>what it said. However, I don't understand
>"or the most recent specification that supersedes it",
>though, since a specification may supercede RFC 3023
>but not be appropriate for a reference to a particular
>section. None of the other references (to XML, DES,
>HTTP, MIME, etc.) have this qualification (that they
>refer to either the current version or anything that
>supersedes it.)

I agree with Larry that a moving target is a bad idea.
At W3C, we use (mostly) dated references, don't we :-).

>I would prefer if the reference were more specific about
>what was the "same": the same syntax, the same set of
>allowable values, the same recommendation for use of
>particular values, the same interpretation of defaults,
>or all of the above. Assuming you mean 'all of the above',
>you could be more explicit:
>
> >  Optional parameters: charset
> >
> >   The allowable and recommended values for, and interpretation
> >   of the charset parameter are identical to those given
> >   for 'application/xml' in section 3.2 of RFC 3023.

I'm not sure this is a good idea. It may lead to
questions such as 'and what about the default value,
is that different',... In other words, trying to list
up all the aspects in which the charset parameter for
application/xenc+xml is the same as that for application/xml
is a futile exercise; not listing any aspects and therefore
making clear that it's everything makes things clearer
and easier, I guess.

>I'm a little concerned about allowing arbitrary charset
>values for the entire application/xml+enc body, though,
>when any encrypted data are always UTF-8 encoded.
>Is it expected that the decryption algorithm do transcoding?
>Shouldn't the behavior of the processor with non-UTF-8
>encoded xml+enc bodies be discussed?

As far as I remember it, encryption does something like
the following:
1) Convert the necessary pieces to UTF-8 (from the encoding
    the document is in)
2) Encrypt the UTF-8 bytes
3) 'Textify' the result of the encryption by using base64

The decryption algorithm has to reverse these steps,
including step 1).

Allowing arbitrary charset values for application/xml+enc
is no problem. First, these values will apply to the
non-encrypted pieces of the document. (I can obviously
have something like <ds:KeyName>鈴木太郎</ds:KeyName>)
Second, once the encrypted part is textified as base64,
that text can still be encoded in us-ascii (which would
be covered by UTF-8) or in ebcdic or utf-16,...

So what I think may make sense is to add something like:

Note: The character encoding denoted by the "charset"
parameter is the character encoding of the resulting XML
document after encoding.

> > > > the 'encoding considerations'
> >
>http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/#sec-MediaType-Regi
>stration
>
>Again, I would prefer if the reference were more explicit
>about exactly was 'the same'.

Again, in general I would disagree here.

>You might even note that because
>encrypted data is encoded in base64 that encrypted data
>may have different encoding requirements than the data
>it replaces.

Good point.

># Published specification: this document.

I think that 'published specification: this document' is quite
dangerous. Assume somebody (that may be IANA) copies the registration
only for their own purposes. Then the reference is lost.

Regards,    Martin.

From: [email-masked] (Martin Duerst)
Date: Fri, 09 Aug 2002 12:27:56 +0900
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <003601c23e69$c1359e40$06432099@masinter> <[email-masked]>
Message-ID: <4.2.0.58.J.20020809122628.0293cb78@localhost>

At 15:00 02/08/08 -0400, Joseph Reagle wrote:
>The specification says, "This media-type is only used for documents in which
>the EncryptedData and EncryptedKey element types appear as the root element
>of the XML document." I'm not sure how to be much more clear than that?

Well, change "EncryptedData and EncryptedKey" to
"EncryptedData or EncryptedKey". I haven't seen
an XML doc yet with two root elements.

Regards,    Martin.

From: [email-masked] (Martin Duerst)
Date: Fri, 09 Aug 2002 12:14:13 +0900
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <003601c23e69$c1359e40$06432099@masinter> <[email-masked]>
Message-ID: <4.2.0.58.J.20020809121034.04982160@localhost>

At 15:00 02/08/08 -0400, Joseph Reagle wrote:
>As Ned and Martin point out, the intent is to express the fact that
>"application/xenc+xml" is XML, and consequently shares the same charset and
>encoding semantics/processing as that defined in RFC 3023.

Well, what the spec currently writes is okay, but what
you just write above is not:

The intent is to say that application/xenc+xml shares the same
charset behaviour as application/xml defined in RFC 3023.
(text/xml behaves differently)

Regards,   Martin.

From: matti.s.hamalainen at nokia.com ([email-masked])
Date: Tue Jan  3 16:22:32 2006
Subject: Please review: audio/sp-midi MIME type registration
Message-ID: <[email-masked]>

Hi,
(1) Oops.

(2) MMA documents can be ordered from the Internet from MMA web site http://www.midi.org/. Some MMA publications can be downloaded freely from their WEB site but SP-MIDI documents would need to be ordered. Publishing is a source of income for MMA. I believe the situation is similar e.g. with MPEG-4 documentation w.r.t MIME registration. Membership is open to anyone commercially involved in the design or manufacture of MIDI hardware or software. 

(3) I believe this would be OK since all references are (non-IETF) published specifications. Some IDs seem to have references included as an appendix.

BR,
Matti
>-----Original Message-----
>From: ext Graham Klyne [mailto:[email-masked]]
>Sent: 21 July, 2002 21:24
>To: Hamalainen Matti.S (NRC/Tampere)
>Cc: [email-masked]
>Subject: Re: Please review: audio/sp-midi MIME type registration
>
>
>(1) typo in security considerations  "don not".
>
>(2) are the specification documents freely available on the 
>Internet?  If 
>not, I wonder if a vnd-tree registration might not be more 
>appropriate?  If 
>they are, URLs would be helpful.
>
>(3) I think maybe the references should appear in the "published 
>specifications" section of the registration template, since 
>that appears in 
>the MIME type registry.
>
>#g
>--
>
>At 12:01 AM 7/20/02 +0300, [email-masked] wrote:
>
>
>> 
>>M. Hamalainen
>>                Internet 
>> Draft                                                    Nokia
>>                Document: 
>> draft-SP-MIDI-MIME-type-01.txt                       T. White
>> 
>>MMA
>>                Expires: January 
>> 2003                                         July 2002
>>
>>
>>                               Registration of MIME media 
>type audio/sp-midi
>>
>>
>>                Status of this Memo
>>
>>                   This document is an Internet-Draft and is 
>subject to 
>> all provisions
>>                   of Section 10 of RFC2026 except that the right to 
>> produce derivative
>>                   works is not granted.
>>
>>                   Internet-Drafts are working documents of 
>the Internet 
>> Engineering
>>                   Task Force (IETF), its areas, and its working 
>> groups.  Note that
>>                   other groups may also distribute working 
>documents as 
>> Internet-
>>                   Drafts.
>>
>>                   Internet-Drafts are draft documents valid 
>for a maximum 
>> of six
>>                   months and may be updated, replaced, or 
>obsoleted by 
>> other documents
>>                   at any time.  It is inappropriate to use 
>> Internet-Drafts as
>>                   reference material or to cite them other 
>than as "work 
>> in progress."
>>
>>                   The list of current Internet-Drafts can be 
>accessed at
>>                        http://www.ietf.org/ietf/1id-abstracts.txt
>>                   The list of Internet-Draft Shadow 
>Directories can be 
>> accessed at
>>                        http://www.ietf.org/shadow.html.
>>
>>
>>                Abstract
>>
>>                   MIDI Manufacturers Association (MMA) and 
>Association of 
>> Music
>>                   Electronics industry (AMEI) have recently 
>produced the 
>> Scalable
>>                   Polyphony MIDI (SP-MIDI) standard [1]. The SP-MIDI 
>> standard has been
>>                   developed in particularly for mobile MIDI 
>applications. 
>> SP-MIDI has
>>                   been approved for 3GPP standardization and 
>a dedicated 
>> SP-MIDI
>>                   profile has been defined for 3GPP SP-MIDI 
>devices [2]. 
>> Since MIDI
>>                   information is a very compact media type 3GPP is 
>> initially focusing
>>                   on the application of SP-MIDI for music 
>downloading and 
>> messaging
>>                   applications that require MIME registration.
>>
>>
>>
>>
>>
>>
>>
>>
>>                1 Introduction
>>
>>
>>                Hamalainen & 
>> White                                            [Page 1]
>>
>>                                             SP-MIDI 
>> MIME                   July, 2002
>>
>>                   MIDI content is commonly used in the 
>Internet, however 
>> such use is
>>                   based on informal ad hoc MIME type 
>definitions that 
>> have not been
>>                   registered by IETF. The present MIME type 
>registration 
>> is harmonized
>>                   with the typical Internet usage of unregistered 
>> audio/midi and
>>                   audio/x-midi MIME types. Commonly MIDI 
>information is 
>> stored in the
>>                   Standard MIDI File (SMF) format [3]. The 
>present MIME type
>>                   registration also uses the SMF file format for the 
>> encapsulation of
>>                   SP-MIDI data. Whereas previous MIDI 
>specifications have 
>> been based
>>                   on common minimum requirements for all 
>playback devices 
>> supporting
>>                   the same specification, SP-MIDI is able to 
>support a 
>> wider range of
>>                   playback devices because playback 
>adaptations can be 
>> encoded in the
>>                   MIDI content. Due to these differences, a 
>separate MIME 
>> type,
>>                   audio/sp-midi, needs to be registered to 
>distinguish 
>> SP-MIDI
>>                   content.
>>
>>                2 Registration of audio/sp-midi
>>
>>                   MIME media type name: audio
>>
>>                   MIME subtype name: sp-midi
>>
>>                   Required parameters: none
>>
>>                   Optional parameters: none
>>
>>                   Encoding considerations:
>>
>>                        sp-midi data is binary data and must 
>be encoded 
>> for non-binary
>>                        transport; Base64 is suitable for Email
>>
>>                   Security considerations:
>>
>>                        Many synthetic audio compositions 
>have associated 
>> intellectual
>>                        property rights. It is conceivable 
>that rights 
>> owners of sp-
>>                        midi content will want to protect 
>their rights by 
>> applying
>>                        security mechanisms that prohibit the 
>rendering of 
>> the content
>>                        without a legally acquired license to 
>do so. These 
>> mechanisms
>>                        would be applied externally to the 
>Content-Type 
>> defined here;
>>                        sp-midi content itself is not encrypted 
>> internally. sp-midi
>>                        streams don not contain executable content.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>                Hamalainen & White           January 
>> 2003                     [Page 2]
>>
>>                                             SP-MIDI 
>> MIME                   July, 2002
>>
>>                   Interoperability considerations:
>>
>>                        Scalable Polyphony MIDI (SP-MIDI) is 
>a Musical 
>> Instrument
>>                        Digital Interface (MIDI) 
>specification developed 
>> by MMA and
>>                        AMEI. SP-MIDI is based on the MIDI 1.0 
>> specification [3] which
>>                        standardizes a protocol for the electronic 
>> transmission of
>>                        music as data suitable for 
>communication between a 
>> transmitter
>>                        and receiver using MIDI messages. 
>SP-MIDI data is 
>> stored in
>>                        Standard MIDI Files (SMF) [3].
>>
>>                        The SP-MIDI format [1] provides scalable 
>> representation of MIDI
>>                        content which enables broadly 
>interoperable music 
>> applications.
>>                        SP-MIDI files have encoded 
>information about playback
>>                        requirements which allows SP-MIDI 
>playback devices 
>> with
>>                        different device capabilities to play 
>the same 
>> content
>>                        according to composer's polyphony 
>requirement and 
>> Channel
>>                        priority order definitions. SP-MIDI player 
>> requirements are
>>                        defined in separate SP-MIDI profile 
>specifications 
>> [2] defining
>>                        the supported MIDI messages and device 
>> requirement. All SP-MIDI
>>                        profiles follow the definitions of 
>the SP-MIDI 
>> specification
>>                        [1].
>>
>>                        MMA and AMEI have previously defined 
>the General 
>> MIDI (GM)
>>                        system standards GM1 [4] GM2 [5], and 
>GML [6]. These
>>                        specifications are technically 
>related to the SP-MIDI
>>                        specification, but do not support polyphony 
>> scalability. Due to
>>                        the differences between GM and 
>SP-MIDI systems GM 
>> synthesizers
>>                        do not support all SP-MIDI content, 
>and likewise 
>> not all SP-
>>                        MIDI synthesizers support all GM 
>content. Thus a 
>> separate MIME
>>                        definition is needed to distinguish 
>SP-MIDI, media 
>> from the
>>                        informally used audio/midi content.
>>
>>                   Published specification:
>>
>>                        There are no previous RFC documents 
>on SP-MIDI.
>>
>>                   Applications which use this media type:
>>
>>                        SP-MIDI is a synthetic audio format 
>for the flexible
>>                        presentation of MIDI data on a wide range of 
>> playback devices,
>>                        particularly portable appliances such 
>as mobile 
>> phones, PDAs,
>>                        and palmtop computers.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>                Hamalainen & White           January 
>> 2003                     [Page 3]
>>
>>                                             SP-MIDI 
>> MIME                   July, 2002
>>
>>
>>                   Additional information:
>>
>>                   Magic number(s):
>>                        First four bytes (1-4): \115\124\150\144,
>>                        byte (24): \360,
>>                        byte (26): \177,
>>                        bytes (28-29): \013\001
>>
>>                   File extension(s): mid
>>
>>                   Macintosh File Type Code(s): mid
>>
>>                   Intended usage: COMMON
>>
>>
>>                3 IANA Considerations
>>
>>                   Section 2 of this document registers one 
>MIME subtype.
>>
>>                4 Security Considerations
>>
>>                   Security considerations are specified in 
>the MIME subtype
>>                   registration contained in Section 2.
>>
>>                5 Authors' Addresses
>>
>>                        Matti Hamalainen
>>                        Nokia
>>                        P.O. Box 100 (Visiokatu 1)
>>                        FIN-33721 Tampere, Finland
>>                        Tel: +358 7180 35789
>>                        Fax: +358 7180 35899
>>
>>                        Email: [email-masked]
>>
>>
>>                        Tom White,
>>                        MIDI Manufacturers Association
>>                        P.O. Box 3173
>>                        La Habra CA
>>                        90632-3173
>>                        Tel (714) 736-9774
>>                        Fax (714) 736-9775
>>
>>                        Email: [email-masked]
>>
>>
>>
>>
>>
>>
>>
>>
>>                Hamalainen & White           January 
>> 2003                     [Page 4]
>>
>>                                             SP-MIDI 
>> MIME                   July, 2002
>>
>>
>>
>>
>>                   Author/Change controller:
>>
>>                        Matti Hamalainen
>>                        Nokia
>>                        P.O. Box 100 (Visiokatu 1)
>>                        FIN-33721 Tampere, Finland
>>                        Tel: +358 7180 35789
>>                        Fax: +358 7180 35899
>>                        [email-masked]
>>
>>
>>
>>                References
>>
>>                   1 Scalable Polyphony MIDI Specification. 
>December 2001, 
>> RP-034, The
>>                      MIDI Manufacturers Association, Los 
>Angeles, CA, USA.
>>                   2 Scalable Polyphony MIDI Device 5-24 Note 
>Profile for 
>> 3GPP,
>>                      December 2001, RP-035, The MIDI Manufacturers 
>> Association, Los
>>                      Angeles, CA, USA.
>>                   3 MIDI 1.0 Detailed Specification, 
>Document Version 
>> 4.2. February
>>                      1996, In 'The Complete MIDI 1.0 Detailed 
>> Specification, Document
>>                      Version 96.1.' The MIDI Manufacturers 
>Association., 
>> Los Angeles,
>>                      CA, USA.
>>                   4 General MIDI System Level 1. 1994, 
>MMA0007/RP003, In 
>> 'The Complete
>>                      MIDI 1.0 Detailed Specification, 
>Document Version 
>> 96.1.' The MIDI
>>                      Manufacturers Association, Los Angeles, CA, USA.
>>                   5 General MIDI Level 2 Specification (Recommended 
>> Practice).
>>                      November 1999, RP-024, The MIDI Manufacturers 
>> Association, Los
>>                      Angeles, CA, USA.
>>                   6 General MIDI Lite, Specification for GM Lite and 
>> Guidelines for
>>                      Use In Mobile Applications. October 5, 
>2001, RP-033, 
>> Version 1.0,
>>                      The MIDI Manufacturers Association, Los 
>Angeles, CA, 
>> USA.
>>
>>
>>                Hamalainen & White           January 
>> 2003                     [Page 5]
>>
>>_______________________________________________
>>Ietf-types mailing list
>>[email-masked]
>>http://www.alvestrand.no/mailman/listinfo/ietf-types
>
>-------------------
>Graham Klyne
><[email-masked]>
>
>

From: [email-masked] ([email-masked])
Date: Wed, 7 Aug 2002 20:47:37 +0300
Subject: Please review: audio/sp-midi MIME type registration
Message-ID: <[email-masked]>

Hi,
(1) Oops.

(2) MMA documents can be ordered from the Internet from MMA web site =
http://www.midi.org/. Some MMA publications can be downloaded freely =
from their WEB site but SP-MIDI documents would need to be ordered. =
Publishing is a source of income for MMA. I believe the situation is =
similar e.g. with MPEG-4 documentation w.r.t MIME registration. =
Membership is open to anyone commercially involved in the design or =
manufacture of MIDI hardware or software.=20

(3) I believe this would be OK since all references are (non-IETF) =
published specifications. Some IDs seem to have references included as =
an appendix.

BR,
Matti
>-----Original Message-----
>From: ext Graham Klyne [mailto:[email-masked]]
>Sent: 21 July, 2002 21:24
>To: Hamalainen Matti.S (NRC/Tampere)
>Cc: [email-masked]
>Subject: Re: Please review: audio/sp-midi MIME type registration
>
>
>(1) typo in security considerations  "don not".
>
>(2) are the specification documents freely available on the=20
>Internet?  If=20
>not, I wonder if a vnd-tree registration might not be more=20
>appropriate?  If=20
>they are, URLs would be helpful.
>
>(3) I think maybe the references should appear in the "published=20
>specifications" section of the registration template, since=20
>that appears in=20
>the MIME type registry.
>
>#g
>--
>
>At 12:01 AM 7/20/02 +0300, [email-masked] wrote:
>
>
>>=20
>>M. Hamalainen
>>                Internet=20
>> Draft                                                    Nokia
>>                Document:=20
>> draft-SP-MIDI-MIME-type-01.txt                       T. White
>>=20
>>MMA
>>                Expires: January=20
>> 2003                                         July 2002
>>
>>
>>                               Registration of MIME media=20
>type audio/sp-midi
>>
>>
>>                Status of this Memo
>>
>>                   This document is an Internet-Draft and is=20
>subject to=20
>> all provisions
>>                   of Section 10 of RFC2026 except that the right to=20
>> produce derivative
>>                   works is not granted.
>>
>>                   Internet-Drafts are working documents of=20
>the Internet=20
>> Engineering
>>                   Task Force (IETF), its areas, and its working=20
>> groups.  Note that
>>                   other groups may also distribute working=20
>documents as=20
>> Internet-
>>                   Drafts.
>>
>>                   Internet-Drafts are draft documents valid=20
>for a maximum=20
>> of six
>>                   months and may be updated, replaced, or=20
>obsoleted by=20
>> other documents
>>                   at any time.  It is inappropriate to use=20
>> Internet-Drafts as
>>                   reference material or to cite them other=20
>than as "work=20
>> in progress."
>>
>>                   The list of current Internet-Drafts can be=20
>accessed at
>>                        http://www.ietf.org/ietf/1id-abstracts.txt
>>                   The list of Internet-Draft Shadow=20
>Directories can be=20
>> accessed at
>>                        http://www.ietf.org/shadow.html.
>>
>>
>>                Abstract
>>
>>                   MIDI Manufacturers Association (MMA) and=20
>Association of=20
>> Music
>>                   Electronics industry (AMEI) have recently=20
>produced the=20
>> Scalable
>>                   Polyphony MIDI (SP-MIDI) standard [1]. The SP-MIDI=20
>> standard has been
>>                   developed in particularly for mobile MIDI=20
>applications.=20
>> SP-MIDI has
>>                   been approved for 3GPP standardization and=20
>a dedicated=20
>> SP-MIDI
>>                   profile has been defined for 3GPP SP-MIDI=20
>devices [2].=20
>> Since MIDI
>>                   information is a very compact media type 3GPP is=20
>> initially focusing
>>                   on the application of SP-MIDI for music=20
>downloading and=20
>> messaging
>>                   applications that require MIME registration.
>>
>>
>>
>>
>>
>>
>>
>>
>>                1 Introduction
>>
>>
>>                Hamalainen &=20
>> White                                            [Page 1]
>>
>>                                             SP-MIDI=20
>> MIME                   July, 2002
>>
>>                   MIDI content is commonly used in the=20
>Internet, however=20
>> such use is
>>                   based on informal ad hoc MIME type=20
>definitions that=20
>> have not been
>>                   registered by IETF. The present MIME type=20
>registration=20
>> is harmonized
>>                   with the typical Internet usage of unregistered=20
>> audio/midi and
>>                   audio/x-midi MIME types. Commonly MIDI=20
>information is=20
>> stored in the
>>                   Standard MIDI File (SMF) format [3]. The=20
>present MIME type
>>                   registration also uses the SMF file format for the=20
>> encapsulation of
>>                   SP-MIDI data. Whereas previous MIDI=20
>specifications have=20
>> been based
>>                   on common minimum requirements for all=20
>playback devices=20
>> supporting
>>                   the same specification, SP-MIDI is able to=20
>support a=20
>> wider range of
>>                   playback devices because playback=20
>adaptations can be=20
>> encoded in the
>>                   MIDI content. Due to these differences, a=20
>separate MIME=20
>> type,
>>                   audio/sp-midi, needs to be registered to=20
>distinguish=20
>> SP-MIDI
>>                   content.
>>
>>                2 Registration of audio/sp-midi
>>
>>                   MIME media type name: audio
>>
>>                   MIME subtype name: sp-midi
>>
>>                   Required parameters: none
>>
>>                   Optional parameters: none
>>
>>                   Encoding considerations:
>>
>>                        sp-midi data is binary data and must=20
>be encoded=20
>> for non-binary
>>                        transport; Base64 is suitable for Email
>>
>>                   Security considerations:
>>
>>                        Many synthetic audio compositions=20
>have associated=20
>> intellectual
>>                        property rights. It is conceivable=20
>that rights=20
>> owners of sp-
>>                        midi content will want to protect=20
>their rights by=20
>> applying
>>                        security mechanisms that prohibit the=20
>rendering of=20
>> the content
>>                        without a legally acquired license to=20
>do so. These=20
>> mechanisms
>>                        would be applied externally to the=20
>Content-Type=20
>> defined here;
>>                        sp-midi content itself is not encrypted=20
>> internally. sp-midi
>>                        streams don not contain executable content.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>                Hamalainen & White           January=20
>> 2003                     [Page 2]
>>
>>                                             SP-MIDI=20
>> MIME                   July, 2002
>>
>>                   Interoperability considerations:
>>
>>                        Scalable Polyphony MIDI (SP-MIDI) is=20
>a Musical=20
>> Instrument
>>                        Digital Interface (MIDI)=20
>specification developed=20
>> by MMA and
>>                        AMEI. SP-MIDI is based on the MIDI 1.0=20
>> specification [3] which
>>                        standardizes a protocol for the electronic=20
>> transmission of
>>                        music as data suitable for=20
>communication between a=20
>> transmitter
>>                        and receiver using MIDI messages.=20
>SP-MIDI data is=20
>> stored in
>>                        Standard MIDI Files (SMF) [3].
>>
>>                        The SP-MIDI format [1] provides scalable=20
>> representation of MIDI
>>                        content which enables broadly=20
>interoperable music=20
>> applications.
>>                        SP-MIDI files have encoded=20
>information about playback
>>                        requirements which allows SP-MIDI=20
>playback devices=20
>> with
>>                        different device capabilities to play=20
>the same=20
>> content
>>                        according to composer's polyphony=20
>requirement and=20
>> Channel
>>                        priority order definitions. SP-MIDI player=20
>> requirements are
>>                        defined in separate SP-MIDI profile=20
>specifications=20
>> [2] defining
>>                        the supported MIDI messages and device=20
>> requirement. All SP-MIDI
>>                        profiles follow the definitions of=20
>the SP-MIDI=20
>> specification
>>                        [1].
>>
>>                        MMA and AMEI have previously defined=20
>the General=20
>> MIDI (GM)
>>                        system standards GM1 [4] GM2 [5], and=20
>GML [6]. These
>>                        specifications are technically=20
>related to the SP-MIDI
>>                        specification, but do not support polyphony=20
>> scalability. Due to
>>                        the differences between GM and=20
>SP-MIDI systems GM=20
>> synthesizers
>>                        do not support all SP-MIDI content,=20
>and likewise=20
>> not all SP-
>>                        MIDI synthesizers support all GM=20
>content. Thus a=20
>> separate MIME
>>                        definition is needed to distinguish=20
>SP-MIDI, media=20
>> from the
>>                        informally used audio/midi content.
>>
>>                   Published specification:
>>
>>                        There are no previous RFC documents=20
>on SP-MIDI.
>>
>>                   Applications which use this media type:
>>
>>                        SP-MIDI is a synthetic audio format=20
>for the flexible
>>                        presentation of MIDI data on a wide range of=20
>> playback devices,
>>                        particularly portable appliances such=20
>as mobile=20
>> phones, PDAs,
>>                        and palmtop computers.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>                Hamalainen & White           January=20
>> 2003                     [Page 3]
>>
>>                                             SP-MIDI=20
>> MIME                   July, 2002
>>
>>
>>                   Additional information:
>>
>>                   Magic number(s):
>>                        First four bytes (1-4): \115\124\150\144,
>>                        byte (24): \360,
>>                        byte (26): \177,
>>                        bytes (28-29): \013\001
>>
>>                   File extension(s): mid
>>
>>                   Macintosh File Type Code(s): mid
>>
>>                   Intended usage: COMMON
>>
>>
>>                3 IANA Considerations
>>
>>                   Section 2 of this document registers one=20
>MIME subtype.
>>
>>                4 Security Considerations
>>
>>                   Security considerations are specified in=20
>the MIME subtype
>>                   registration contained in Section 2.
>>
>>                5 Authors' Addresses
>>
>>                        Matti Hamalainen
>>                        Nokia
>>                        P.O. Box 100 (Visiokatu 1)
>>                        FIN-33721 Tampere, Finland
>>                        Tel: +358 7180 35789
>>                        Fax: +358 7180 35899
>>
>>                        Email: [email-masked]
>>
>>
>>                        Tom White,
>>                        MIDI Manufacturers Association
>>                        P.O. Box 3173
>>                        La Habra CA
>>                        90632-3173
>>                        Tel (714) 736-9774
>>                        Fax (714) 736-9775
>>
>>                        Email: [email-masked]
>>
>>
>>
>>
>>
>>
>>
>>
>>                Hamalainen & White           January=20
>> 2003                     [Page 4]
>>
>>                                             SP-MIDI=20
>> MIME                   July, 2002
>>
>>
>>
>>
>>                   Author/Change controller:
>>
>>                        Matti Hamalainen
>>                        Nokia
>>                        P.O. Box 100 (Visiokatu 1)
>>                        FIN-33721 Tampere, Finland
>>                        Tel: +358 7180 35789
>>                        Fax: +358 7180 35899
>>                        [email-masked]
>>
>>
>>
>>                References
>>
>>                   1 Scalable Polyphony MIDI Specification.=20
>December 2001,=20
>> RP-034, The
>>                      MIDI Manufacturers Association, Los=20
>Angeles, CA, USA.
>>                   2 Scalable Polyphony MIDI Device 5-24 Note=20
>Profile for=20
>> 3GPP,
>>                      December 2001, RP-035, The MIDI Manufacturers=20
>> Association, Los
>>                      Angeles, CA, USA.
>>                   3 MIDI 1.0 Detailed Specification,=20
>Document Version=20
>> 4.2. February
>>                      1996, In 'The Complete MIDI 1.0 Detailed=20
>> Specification, Document
>>                      Version 96.1.' The MIDI Manufacturers=20
>Association.,=20
>> Los Angeles,
>>                      CA, USA.
>>                   4 General MIDI System Level 1. 1994,=20
>MMA0007/RP003, In=20
>> 'The Complete
>>                      MIDI 1.0 Detailed Specification,=20
>Document Version=20
>> 96.1.' The MIDI
>>                      Manufacturers Association, Los Angeles, CA, USA.
>>                   5 General MIDI Level 2 Specification (Recommended=20
>> Practice).
>>                      November 1999, RP-024, The MIDI Manufacturers=20
>> Association, Los
>>                      Angeles, CA, USA.
>>                   6 General MIDI Lite, Specification for GM Lite and=20
>> Guidelines for
>>                      Use In Mobile Applications. October 5,=20
>2001, RP-033,=20
>> Version 1.0,
>>                      The MIDI Manufacturers Association, Los=20
>Angeles, CA,=20
>> USA.
>>
>>
>>                Hamalainen & White           January=20
>> 2003                     [Page 5]
>>
>>_______________________________________________
>>Ietf-types mailing list
>>[email-masked]
>>http://www.alvestrand.no/mailman/listinfo/ietf-types
>
>-------------------
>Graham Klyne
><[email-masked]>
>
>

From: [email-masked] (Philipp Hoschka)
Date: Tue, 27 Aug 2002 16:02:07 +0200
Subject: CORRECTION: Please review ietf-draft of SMIL media-type registration
References: <[email-masked]>
Message-ID: <[email-masked]>

Kari,

good catches !

See inline for more

Kari Pihkala wrote:
> 
> Hi,
> 
> I noticed some inconsistencies with the SMIL namespaces in the
> draft. In section 4:
> 
> All SMIL 2.0 files must also include a declaration of the SMIL 2.0
>    namespace.  This should appear shortly after the string "<smil", and
>    should read 'xmlns="http://www.w3.org/2001/SMIL20/PR/Language"'.

Fixed this to use
http://www.w3.org/2001/SMIL20/Language

as namespace.
 
> However, a different namespace in the end of section 5:
> 
> An example use of this parameter as part of a HTTP GET transaction
>    would be:
> 
>         Accept: application/smil+xml;
>            profile="http://www.w3.org/2001/SMIL20/REC/HostLanguage"

Removed the REC part.

The namespace should be different, I think, since this is the way 
that a client informs a server that it supports SMIL basic.

I'm not sure that people actually use the following URI to
identify SMIL basic, however
http://www.w3.org/2001/SMIL20/REC/HostLanguage

or that anyone uses the "accept" header at all - I'll send a
seperate message to the www-smil list on that.

> Also, either of these namespaces match the one in SMIL 2.0 spec
> (http://www.w3.org/TR/2001/REC-smil20-20010807/smil20-profile.html):
> 13.3.2 SMIL 2.0 Language Conformance
> 
> 5. A document must declare a default namespace for its elements with an
> xmlns attribute on the smil root element with its identifier URI:
> <smil xmlns="http://www.w3.org/2001/SMIL20/Language">
>    ...
> </smil>
> 
> You may want to check these...
> 
>  - Kari
...

From: [email-masked] (Philipp Hoschka)
Date: Thu, 22 Aug 2002 17:23:43 +0200
Subject: CORRECTION: Please review ietf-draft of SMIL media-type registration
Message-ID: <[email-masked]>

[the previous mail contained a superfluous and inappropriate 
attachment, and an errouneous "reply-to" header - Apologies]

------

This email serves to instantiate the two week discussion 
period on "[email-masked]" of the ietf-draft describing
the SMIL media-type registration. You can find the draft at
http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-10.txt

The expected course of advancement for this specification is:
1. I have notified one of the Application area directors (Ned Freed)
2. Request publication as an Informational RFC as specified:
  ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt
3. Ensure IANA is aware of the publication and posts the registration as 
specified:
  ftp://ftp.isi.edu/in-notes/rfc2048.txt

The changes in this specification since the last version discussed on 
"[email-masked]" include:
1. Registration of application/xml+smil in addition to application/smil
2. Addition of optional "profile" parameter
3. Addition of paragraph describing how to recognize SMIL files by
   looking into the file.

Thank you.

-- 

-Philipp Hoschka

From: [email-masked] (Philipp Hoschka)
Date: Thu, 22 Aug 2002 14:42:55 +0200
Subject: Please review ietf-draft of SMIL media-type registration
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.
--------------3E057BDBA78E6604561A8263
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This email serves to instantiate the two week discussion 
period on "[email-masked]" of the ietf-draft describing
the SMIL media-type registration. You can find the draft at
http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-10.txt

The expected course of advancement for this specification is:
1. I have notified one of the Application area directors (Ned Freed)
2. Request publication as an Informational RFC as specified:
  ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt
3. Ensure IANA is aware of the publication and posts the registration as 
specified:
  ftp://ftp.isi.edu/in-notes/rfc2048.txt

The changes in this specification since the last version discussed on 
"[email-masked]" include:
1. Registration of application/xml+smil in addition to application/smil
2. Addition of optional "profile" parameter
3. Addition of paragraph describing how to recognize SMIL files by
   looking into the file.

Thank you.

-- 

-Philipp Hoschka
--------------3E057BDBA78E6604561A8263
Content-Type: text/plain; charset=iso-8859-1;
 name="draft-reagle-xenc-mediatype-00.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="draft-reagle-xenc-mediatype-00.txt"

--------------3E057BDBA78E6604561A8263--

From: [email-masked] (Martin Duerst)
Date: Tue, 20 Aug 2002 11:19:58 +0900
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <[email-masked]>
References: <000f01c23f27$f6330b50$06432099@masinter> <000f01c23f27$f6330b50$06432099@masinter>
Message-ID: <4.2.0.58.J.20020820111249.03c13680@localhost>

Hello Aaron, dear RDF Core WG,

On [email-masked] and some related list, we were just looking
at http://www.w3.org/TR/xmlenc-core/#sec-MediaType which containes
some instances of text like this:

    Same as ... of application/xml as specified in RFC 3023[XML-MT]
    or the most recent specification that supercedes it.

There seemed to be general agreement that a moving target is
not a good idea.

Josef Reagle told us that he got that text from:
http://www.aaronsw.com/2002/rdf-mediatype.html

I wanted to tell you that you may want to fix this.

Regards,   Martin.

At 14:47 02/08/19 -0400, Joseph Reagle wrote:
>On Thursday 08 August 2002 06:07 pm, Larry Masinter wrote:
> > # Optional parameters: charset
> > #  Same as charset parameter of application/xml as
> > #  specified in RFC 3023 [XML-MT] or the most recent
> > #  specification that supersedes it.
> >
> > I admit I was a little confused on this one, and misread
> > what it said. However, I don't understand
> > "or the most recent specification that supersedes it",
> > though, since a specification may supercede RFC 3023
> > but not be appropriate for a reference to a particular
> > section.
>
>I'm happy to eliminate that text as I oppose those sort of references in
>general. In this case, I was merely following what I could see the rdf
>folks doing for a similar type of registration:
>   http://www.aaronsw.com/2002/rdf-mediatype.html
>

From: [email-masked] (Martin Duerst)
Date: Fri, 09 Aug 2002 12:45:14 +0900
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <000f01c23f27$f6330b50$06432099@masinter>
References: <[email-masked]>
Message-ID: <4.2.0.58.J.20020809121436.0494fde8@localhost>

At 15:07 02/08/08 -0700, Larry Masinter wrote:
>What it actually says is:
>
># Optional parameters: charset
>
>#  Same as charset parameter of application/xml as
>#  specified in RFC 3023 [XML-MT] or the most recent
>#  specification that supersedes it.
>
>I admit I was a little confused on this one, and misread
>what it said. However, I don't understand
>"or the most recent specification that supersedes it",
>though, since a specification may supercede RFC 3023
>but not be appropriate for a reference to a particular
>section. None of the other references (to XML, DES,
>HTTP, MIME, etc.) have this qualification (that they
>refer to either the current version or anything that
>supersedes it.)

I agree with Larry that a moving target is a bad idea.
At W3C, we use (mostly) dated references, don't we :-).

>I would prefer if the reference were more specific about
>what was the "same": the same syntax, the same set of
>allowable values, the same recommendation for use of
>particular values, the same interpretation of defaults,
>or all of the above. Assuming you mean 'all of the above',
>you could be more explicit:
>
> >  Optional parameters: charset
> >
> >   The allowable and recommended values for, and interpretation
> >   of the charset parameter are identical to those given
> >   for 'application/xml' in section 3.2 of RFC 3023.

I'm not sure this is a good idea. It may lead to
questions such as 'and what about the default value,
is that different',... In other words, trying to list
up all the aspects in which the charset parameter for
application/xenc+xml is the same as that for application/xml
is a futile exercise; not listing any aspects and therefore
making clear that it's everything makes things clearer
and easier, I guess.

>I'm a little concerned about allowing arbitrary charset
>values for the entire application/xml+enc body, though,
>when any encrypted data are always UTF-8 encoded.
>Is it expected that the decryption algorithm do transcoding?
>Shouldn't the behavior of the processor with non-UTF-8
>encoded xml+enc bodies be discussed?

As far as I remember it, encryption does something like
the following:
1) Convert the necessary pieces to UTF-8 (from the encoding
    the document is in)
2) Encrypt the UTF-8 bytes
3) 'Textify' the result of the encryption by using base64

The decryption algorithm has to reverse these steps,
including step 1).

Allowing arbitrary charset values for application/xml+enc
is no problem. First, these values will apply to the
non-encrypted pieces of the document. (I can obviously
have something like <ds:KeyName>鈴木太郎</ds:KeyName>)
Second, once the encrypted part is textified as base64,
that text can still be encoded in us-ascii (which would
be covered by UTF-8) or in ebcdic or utf-16,...

So what I think may make sense is to add something like:

Note: The character encoding denoted by the "charset"
parameter is the character encoding of the resulting XML
document after encoding.

> > > > the 'encoding considerations'
> >
>http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/#sec-MediaType-Regi
>stration
>
>Again, I would prefer if the reference were more explicit
>about exactly was 'the same'.

Again, in general I would disagree here.

>You might even note that because
>encrypted data is encoded in base64 that encrypted data
>may have different encoding requirements than the data
>it replaces.

Good point.

># Published specification: this document.

I think that 'published specification: this document' is quite
dangerous. Assume somebody (that may be IANA) copies the registration
only for their own purposes. Then the reference is lost.

Regards,    Martin.

From: [email-masked] (Martin Duerst)
Date: Fri, 09 Aug 2002 12:27:56 +0900
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <003601c23e69$c1359e40$06432099@masinter> <[email-masked]>
Message-ID: <4.2.0.58.J.20020809122628.0293cb78@localhost>

At 15:00 02/08/08 -0400, Joseph Reagle wrote:
>The specification says, "This media-type is only used for documents in which
>the EncryptedData and EncryptedKey element types appear as the root element
>of the XML document." I'm not sure how to be much more clear than that?

Well, change "EncryptedData and EncryptedKey" to
"EncryptedData or EncryptedKey". I haven't seen
an XML doc yet with two root elements.

Regards,    Martin.

From: [email-masked] (Martin Duerst)
Date: Fri, 09 Aug 2002 12:14:13 +0900
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <003601c23e69$c1359e40$06432099@masinter> <[email-masked]>
Message-ID: <4.2.0.58.J.20020809121034.04982160@localhost>

At 15:00 02/08/08 -0400, Joseph Reagle wrote:
>As Ned and Martin point out, the intent is to express the fact that
>"application/xenc+xml" is XML, and consequently shares the same charset and
>encoding semantics/processing as that defined in RFC 3023.

Well, what the spec currently writes is okay, but what
you just write above is not:

The intent is to say that application/xenc+xml shares the same
charset behaviour as application/xml defined in RFC 3023.
(text/xml behaves differently)

Regards,   Martin.

From: [email-masked] ([email-masked])
Date: Wed, 7 Aug 2002 20:47:37 +0300
Subject: Please review: audio/sp-midi MIME type registration
Message-ID: <[email-masked]>

Hi,
(1) Oops.

(2) MMA documents can be ordered from the Internet from MMA web site =
http://www.midi.org/. Some MMA publications can be downloaded freely =
from their WEB site but SP-MIDI documents would need to be ordered. =
Publishing is a source of income for MMA. I believe the situation is =
similar e.g. with MPEG-4 documentation w.r.t MIME registration. =
Membership is open to anyone commercially involved in the design or =
manufacture of MIDI hardware or software.=20

(3) I believe this would be OK since all references are (non-IETF) =
published specifications. Some IDs seem to have references included as =
an appendix.

BR,
Matti
>-----Original Message-----
>From: ext Graham Klyne [mailto:[email-masked]]
>Sent: 21 July, 2002 21:24
>To: Hamalainen Matti.S (NRC/Tampere)
>Cc: [email-masked]
>Subject: Re: Please review: audio/sp-midi MIME type registration
>
>
>(1) typo in security considerations  "don not".
>
>(2) are the specification documents freely available on the=20
>Internet?  If=20
>not, I wonder if a vnd-tree registration might not be more=20
>appropriate?  If=20
>they are, URLs would be helpful.
>
>(3) I think maybe the references should appear in the "published=20
>specifications" section of the registration template, since=20
>that appears in=20
>the MIME type registry.
>
>#g
>--
>
>At 12:01 AM 7/20/02 +0300, [email-masked] wrote:
>
>
>>=20
>>M. Hamalainen
>>                Internet=20
>> Draft                                                    Nokia
>>                Document:=20
>> draft-SP-MIDI-MIME-type-01.txt                       T. White
>>=20
>>MMA
>>                Expires: January=20
>> 2003                                         July 2002
>>
>>
>>                               Registration of MIME media=20
>type audio/sp-midi
>>
>>
>>                Status of this Memo
>>
>>                   This document is an Internet-Draft and is=20
>subject to=20
>> all provisions
>>                   of Section 10 of RFC2026 except that the right to=20
>> produce derivative
>>                   works is not granted.
>>
>>                   Internet-Drafts are working documents of=20
>the Internet=20
>> Engineering
>>                   Task Force (IETF), its areas, and its working=20
>> groups.  Note that
>>                   other groups may also distribute working=20
>documents as=20
>> Internet-
>>                   Drafts.
>>
>>                   Internet-Drafts are draft documents valid=20
>for a maximum=20
>> of six
>>                   months and may be updated, replaced, or=20
>obsoleted by=20
>> other documents
>>                   at any time.  It is inappropriate to use=20
>> Internet-Drafts as
>>                   reference material or to cite them other=20
>than as "work=20
>> in progress."
>>
>>                   The list of current Internet-Drafts can be=20
>accessed at
>>                        http://www.ietf.org/ietf/1id-abstracts.txt
>>                   The list of Internet-Draft Shadow=20
>Directories can be=20
>> accessed at
>>                        http://www.ietf.org/shadow.html.
>>
>>
>>                Abstract
>>
>>                   MIDI Manufacturers Association (MMA) and=20
>Association of=20
>> Music
>>                   Electronics industry (AMEI) have recently=20
>produced the=20
>> Scalable
>>                   Polyphony MIDI (SP-MIDI) standard [1]. The SP-MIDI=20
>> standard has been
>>                   developed in particularly for mobile MIDI=20
>applications.=20
>> SP-MIDI has
>>                   been approved for 3GPP standardization and=20
>a dedicated=20
>> SP-MIDI
>>                   profile has been defined for 3GPP SP-MIDI=20
>devices [2].=20
>> Since MIDI
>>                   information is a very compact media type 3GPP is=20
>> initially focusing
>>                   on the application of SP-MIDI for music=20
>downloading and=20
>> messaging
>>                   applications that require MIME registration.
>>
>>
>>
>>
>>
>>
>>
>>
>>                1 Introduction
>>
>>
>>                Hamalainen &=20
>> White                                            [Page 1]
>>
>>                                             SP-MIDI=20
>> MIME                   July, 2002
>>
>>                   MIDI content is commonly used in the=20
>Internet, however=20
>> such use is
>>                   based on informal ad hoc MIME type=20
>definitions that=20
>> have not been
>>                   registered by IETF. The present MIME type=20
>registration=20
>> is harmonized
>>                   with the typical Internet usage of unregistered=20
>> audio/midi and
>>                   audio/x-midi MIME types. Commonly MIDI=20
>information is=20
>> stored in the
>>                   Standard MIDI File (SMF) format [3]. The=20
>present MIME type
>>                   registration also uses the SMF file format for the=20
>> encapsulation of
>>                   SP-MIDI data. Whereas previous MIDI=20
>specifications have=20
>> been based
>>                   on common minimum requirements for all=20
>playback devices=20
>> supporting
>>                   the same specification, SP-MIDI is able to=20
>support a=20
>> wider range of
>>                   playback devices because playback=20
>adaptations can be=20
>> encoded in the
>>                   MIDI content. Due to these differences, a=20
>separate MIME=20
>> type,
>>                   audio/sp-midi, needs to be registered to=20
>distinguish=20
>> SP-MIDI
>>                   content.
>>
>>                2 Registration of audio/sp-midi
>>
>>                   MIME media type name: audio
>>
>>                   MIME subtype name: sp-midi
>>
>>                   Required parameters: none
>>
>>                   Optional parameters: none
>>
>>                   Encoding considerations:
>>
>>                        sp-midi data is binary data and must=20
>be encoded=20
>> for non-binary
>>                        transport; Base64 is suitable for Email
>>
>>                   Security considerations:
>>
>>                        Many synthetic audio compositions=20
>have associated=20
>> intellectual
>>                        property rights. It is conceivable=20
>that rights=20
>> owners of sp-
>>                        midi content will want to protect=20
>their rights by=20
>> applying
>>                        security mechanisms that prohibit the=20
>rendering of=20
>> the content
>>                        without a legally acquired license to=20
>do so. These=20
>> mechanisms
>>                        would be applied externally to the=20
>Content-Type=20
>> defined here;
>>                        sp-midi content itself is not encrypted=20
>> internally. sp-midi
>>                        streams don not contain executable content.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>                Hamalainen & White           January=20
>> 2003                     [Page 2]
>>
>>                                             SP-MIDI=20
>> MIME                   July, 2002
>>
>>                   Interoperability considerations:
>>
>>                        Scalable Polyphony MIDI (SP-MIDI) is=20
>a Musical=20
>> Instrument
>>                        Digital Interface (MIDI)=20
>specification developed=20
>> by MMA and
>>                        AMEI. SP-MIDI is based on the MIDI 1.0=20
>> specification [3] which
>>                        standardizes a protocol for the electronic=20
>> transmission of
>>                        music as data suitable for=20
>communication between a=20
>> transmitter
>>                        and receiver using MIDI messages.=20
>SP-MIDI data is=20
>> stored in
>>                        Standard MIDI Files (SMF) [3].
>>
>>                        The SP-MIDI format [1] provides scalable=20
>> representation of MIDI
>>                        content which enables broadly=20
>interoperable music=20
>> applications.
>>                        SP-MIDI files have encoded=20
>information about playback
>>                        requirements which allows SP-MIDI=20
>playback devices=20
>> with
>>                        different device capabilities to play=20
>the same=20
>> content
>>                        according to composer's polyphony=20
>requirement and=20
>> Channel
>>                        priority order definitions. SP-MIDI player=20
>> requirements are
>>                        defined in separate SP-MIDI profile=20
>specifications=20
>> [2] defining
>>                        the supported MIDI messages and device=20
>> requirement. All SP-MIDI
>>                        profiles follow the definitions of=20
>the SP-MIDI=20
>> specification
>>                        [1].
>>
>>                        MMA and AMEI have previously defined=20
>the General=20
>> MIDI (GM)
>>                        system standards GM1 [4] GM2 [5], and=20
>GML [6]. These
>>                        specifications are technically=20
>related to the SP-MIDI
>>                        specification, but do not support polyphony=20
>> scalability. Due to
>>                        the differences between GM and=20
>SP-MIDI systems GM=20
>> synthesizers
>>                        do not support all SP-MIDI content,=20
>and likewise=20
>> not all SP-
>>                        MIDI synthesizers support all GM=20
>content. Thus a=20
>> separate MIME
>>                        definition is needed to distinguish=20
>SP-MIDI, media=20
>> from the
>>                        informally used audio/midi content.
>>
>>                   Published specification:
>>
>>                        There are no previous RFC documents=20
>on SP-MIDI.
>>
>>                   Applications which use this media type:
>>
>>                        SP-MIDI is a synthetic audio format=20
>for the flexible
>>                        presentation of MIDI data on a wide range of=20
>> playback devices,
>>                        particularly portable appliances such=20
>as mobile=20
>> phones, PDAs,
>>                        and palmtop computers.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>                Hamalainen & White           January=20
>> 2003                     [Page 3]
>>
>>                                             SP-MIDI=20
>> MIME                   July, 2002
>>
>>
>>                   Additional information:
>>
>>                   Magic number(s):
>>                        First four bytes (1-4): \115\124\150\144,
>>                        byte (24): \360,
>>                        byte (26): \177,
>>                        bytes (28-29): \013\001
>>
>>                   File extension(s): mid
>>
>>                   Macintosh File Type Code(s): mid
>>
>>                   Intended usage: COMMON
>>
>>
>>                3 IANA Considerations
>>
>>                   Section 2 of this document registers one=20
>MIME subtype.
>>
>>                4 Security Considerations
>>
>>                   Security considerations are specified in=20
>the MIME subtype
>>                   registration contained in Section 2.
>>
>>                5 Authors' Addresses
>>
>>                        Matti Hamalainen
>>                        Nokia
>>                        P.O. Box 100 (Visiokatu 1)
>>                        FIN-33721 Tampere, Finland
>>                        Tel: +358 7180 35789
>>                        Fax: +358 7180 35899
>>
>>                        Email: [email-masked]
>>
>>
>>                        Tom White,
>>                        MIDI Manufacturers Association
>>                        P.O. Box 3173
>>                        La Habra CA
>>                        90632-3173
>>                        Tel (714) 736-9774
>>                        Fax (714) 736-9775
>>
>>                        Email: [email-masked]
>>
>>
>>
>>
>>
>>
>>
>>
>>                Hamalainen & White           January=20
>> 2003                     [Page 4]
>>
>>                                             SP-MIDI=20
>> MIME                   July, 2002
>>
>>
>>
>>
>>                   Author/Change controller:
>>
>>                        Matti Hamalainen
>>                        Nokia
>>                        P.O. Box 100 (Visiokatu 1)
>>                        FIN-33721 Tampere, Finland
>>                        Tel: +358 7180 35789
>>                        Fax: +358 7180 35899
>>                        [email-masked]
>>
>>
>>
>>                References
>>
>>                   1 Scalable Polyphony MIDI Specification.=20
>December 2001,=20
>> RP-034, The
>>                      MIDI Manufacturers Association, Los=20
>Angeles, CA, USA.
>>                   2 Scalable Polyphony MIDI Device 5-24 Note=20
>Profile for=20
>> 3GPP,
>>                      December 2001, RP-035, The MIDI Manufacturers=20
>> Association, Los
>>                      Angeles, CA, USA.
>>                   3 MIDI 1.0 Detailed Specification,=20
>Document Version=20
>> 4.2. February
>>                      1996, In 'The Complete MIDI 1.0 Detailed=20
>> Specification, Document
>>                      Version 96.1.' The MIDI Manufacturers=20
>Association.,=20
>> Los Angeles,
>>                      CA, USA.
>>                   4 General MIDI System Level 1. 1994,=20
>MMA0007/RP003, In=20
>> 'The Complete
>>                      MIDI 1.0 Detailed Specification,=20
>Document Version=20
>> 96.1.' The MIDI
>>                      Manufacturers Association, Los Angeles, CA, USA.
>>                   5 General MIDI Level 2 Specification (Recommended=20
>> Practice).
>>                      November 1999, RP-024, The MIDI Manufacturers=20
>> Association, Los
>>                      Angeles, CA, USA.
>>                   6 General MIDI Lite, Specification for GM Lite and=20
>> Guidelines for
>>                      Use In Mobile Applications. October 5,=20
>2001, RP-033,=20
>> Version 1.0,
>>                      The MIDI Manufacturers Association, Los=20
>Angeles, CA,=20
>> USA.
>>
>>
>>                Hamalainen & White           January=20
>> 2003                     [Page 5]
>>
>>_______________________________________________
>>Ietf-types mailing list
>>[email-masked]
>>http://www.alvestrand.no/mailman/listinfo/ietf-types
>
>-------------------
>Graham Klyne
><[email-masked]>
>
>

From: ph at w3.org (Philipp Hoschka)
Date: Tue Jan  3 16:22:32 2006
Subject: CORRECTION: Please review ietf-draft of SMIL media-type registration
References: <[email-masked]>
Message-ID: <[email-masked]>

Kari,

good catches !

See inline for more

Kari Pihkala wrote:
> 
> Hi,
> 
> I noticed some inconsistencies with the SMIL namespaces in the
> draft. In section 4:
> 
> All SMIL 2.0 files must also include a declaration of the SMIL 2.0
>    namespace.  This should appear shortly after the string "<smil", and
>    should read 'xmlns="http://www.w3.org/2001/SMIL20/PR/Language"'.

Fixed this to use
http://www.w3.org/2001/SMIL20/Language

as namespace.
 
> However, a different namespace in the end of section 5:
> 
> An example use of this parameter as part of a HTTP GET transaction
>    would be:
> 
>         Accept: application/smil+xml;
>            profile="http://www.w3.org/2001/SMIL20/REC/HostLanguage"

Removed the REC part.

The namespace should be different, I think, since this is the way 
that a client informs a server that it supports SMIL basic.

I'm not sure that people actually use the following URI to
identify SMIL basic, however
http://www.w3.org/2001/SMIL20/REC/HostLanguage

or that anyone uses the "accept" header at all - I'll send a
seperate message to the www-smil list on that.

> Also, either of these namespaces match the one in SMIL 2.0 spec
> (http://www.w3.org/TR/2001/REC-smil20-20010807/smil20-profile.html):
> 13.3.2 SMIL 2.0 Language Conformance
> 
> 5. A document must declare a default namespace for its elements with an
> xmlns attribute on the smil root element with its identifier URI:
> <smil xmlns="http://www.w3.org/2001/SMIL20/Language">
>    ...
> </smil>
> 
> You may want to check these...
> 
>  - Kari
...

From: [email-masked] (Philipp Hoschka)
Date: Tue, 27 Aug 2002 16:02:07 +0200
Subject: CORRECTION: Please review ietf-draft of SMIL media-type registration
References: <[email-masked]>
Message-ID: <[email-masked]>

Kari,

good catches !

See inline for more

Kari Pihkala wrote:
> 
> Hi,
> 
> I noticed some inconsistencies with the SMIL namespaces in the
> draft. In section 4:
> 
> All SMIL 2.0 files must also include a declaration of the SMIL 2.0
>    namespace.  This should appear shortly after the string "<smil", and
>    should read 'xmlns="http://www.w3.org/2001/SMIL20/PR/Language"'.

Fixed this to use
http://www.w3.org/2001/SMIL20/Language

as namespace.
 
> However, a different namespace in the end of section 5:
> 
> An example use of this parameter as part of a HTTP GET transaction
>    would be:
> 
>         Accept: application/smil+xml;
>            profile="http://www.w3.org/2001/SMIL20/REC/HostLanguage"

Removed the REC part.

The namespace should be different, I think, since this is the way 
that a client informs a server that it supports SMIL basic.

I'm not sure that people actually use the following URI to
identify SMIL basic, however
http://www.w3.org/2001/SMIL20/REC/HostLanguage

or that anyone uses the "accept" header at all - I'll send a
seperate message to the www-smil list on that.

> Also, either of these namespaces match the one in SMIL 2.0 spec
> (http://www.w3.org/TR/2001/REC-smil20-20010807/smil20-profile.html):
> 13.3.2 SMIL 2.0 Language Conformance
> 
> 5. A document must declare a default namespace for its elements with an
> xmlns attribute on the smil root element with its identifier URI:
> <smil xmlns="http://www.w3.org/2001/SMIL20/Language">
>    ...
> </smil>
> 
> You may want to check these...
> 
>  - Kari
...

From: [email-masked] (Philipp Hoschka)
Date: Thu, 22 Aug 2002 17:23:43 +0200
Subject: CORRECTION: Please review ietf-draft of SMIL media-type registration
Message-ID: <[email-masked]>

[the previous mail contained a superfluous and inappropriate 
attachment, and an errouneous "reply-to" header - Apologies]

------

This email serves to instantiate the two week discussion 
period on "[email-masked]" of the ietf-draft describing
the SMIL media-type registration. You can find the draft at
http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-10.txt

The expected course of advancement for this specification is:
1. I have notified one of the Application area directors (Ned Freed)
2. Request publication as an Informational RFC as specified:
  ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt
3. Ensure IANA is aware of the publication and posts the registration as 
specified:
  ftp://ftp.isi.edu/in-notes/rfc2048.txt

The changes in this specification since the last version discussed on 
"[email-masked]" include:
1. Registration of application/xml+smil in addition to application/smil
2. Addition of optional "profile" parameter
3. Addition of paragraph describing how to recognize SMIL files by
   looking into the file.

Thank you.

-- 

-Philipp Hoschka

From: ph at w3.org (Philipp Hoschka)
Date: Tue Jan  3 16:22:32 2006
Subject: Please review ietf-draft of SMIL media-type registration
Message-ID: <[email-masked]>

This email serves to instantiate the two week discussion 
period on "[email-masked]" of the ietf-draft describing
the SMIL media-type registration. You can find the draft at
http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-10.txt

The expected course of advancement for this specification is:
1. I have notified one of the Application area directors (Ned Freed)
2. Request publication as an Informational RFC as specified:
  ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt
3. Ensure IANA is aware of the publication and posts the registration as 
specified:
  ftp://ftp.isi.edu/in-notes/rfc2048.txt

The changes in this specification since the last version discussed on 
"[email-masked]" include:
1. Registration of application/xml+smil in addition to application/smil
2. Addition of optional "profile" parameter
3. Addition of paragraph describing how to recognize SMIL files by
   looking into the file.

Thank you.

-- 

-Philipp Hoschka
-------------- next part --------------

                                                             J. Reagle
Internet-Draft                                             W3C/LCS/MIT
Expires: October 2002                                        June 2002

              application/xenc+xml Media Type Registration
                    draft-reagle-xenc-mediatype-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html. 
   
   This Internet-Draft will expire on October 22, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document describes a media type (application/xenc+xml) for use
   with the XML Encryption specification.

Table of Contents

    1. Discussion of this Document
    2. Introduction
    3. application/xenc+xml Registration
    4. References
    5. Author's Address
    6. Full Copyright Statement

 

Reagle, J.                 Expires October 2002                 [Page 1] 

Internet-Draft           XML Encryption Media-Type              June 2002 

1. Discussion of this Document

   Please send comments to [email-masked]. To subscribe, send a
   message with the body 'subscribe' to [email-masked]. The
   mailing list is publicly archived at
   http://lists.w3.org/Archives/Public/xml-encryption/ .

2. Introduction

   The XML Encryption Syntax and Processing document [XENC] specifies a
   process for encrypting data and representing the result in XML. The
   data may be arbitrary data (including an XML document), an XML
   element, or XML element content. The result of encrypting data is an
   XML Encryption element which contains or references the cipher data.

   The application/xenc+xml media type allows XENC applications to
   identify XENC documents for processing. Additionally it allows
   applications cognizant of this media-type (even if they are not XENC
   implementations) to note that the media type of the decrypted
   (original) object might a type other than XML.

   This media-type is only used for documents in which the XENC
   EncyptedData and EncryptedKey element types appear as the root element
   of the XML document. XML documents which contain XENC element types in
   places other than the root element can be described using facilities
   such as [XML-schema] or [StLaurent].

3. application/xenc+xml Registration

   This is a media type registration as defined in Multipurpose Internet
   Mail Extensions (MIME) Part Four: Registration Procedures [MIME-REG]

   MIME media type name: application

   MIME subtype name: xenc+xml

   Required parameters: none

   Optional parameters: charset

     Same as charset parameter of application/xml as specified in RFC
     3023 [XML-MT] or the most recent specification that supersedes it.

   Encoding considerations:

     Same as charset parameter of application/xml as specified in RFC
     3023 [XML-MT] or the most recent specification that supersedes it.

   Security considerations:

     Security considerations include many of those described in the

Reagle, J.                 Expires October 2002                 [Page 2] 

Internet-Draft           XML Encryption Media-Type              June 2002 

     Security Considerations of [XENC].

   Interoperability considerations: none

   Published specification: [XENC].

   Applications which use this media type:

     XENC is device-, platform-, and vendor-neutral and is supported by
     a range of Web applications.

   Additional Information:

     Magic number(s): none

     Although no byte sequences can be counted on to consistently
     identify XENC documents, they will be XML documents in which the
     root element's QName's LocalPart is 'EncryptedData' with an
     associated namespace name of 'http://www.w3.org/2001/04/xmlenc#'.
     The application/xenc+xml type name MUST only be used for data
     objects in which the root element is from the XENC namespace.

     File extension(s): .xml

     Macintosh File Type Code(s): "TEXT"

   Person & email address to contact for further information:

     Joseph Reagle <[email-masked]>

     XENC Working Group <[email-masked]>

   Intended usage: COMMON

   Author/Change controller:

     The XENC specification is a work product of the World Wide Web
     Consortium. The W3C and the W3C XENC Working Group have change
     control over the specification.

4. References

   Glossary
          RFC 2828. Internet Security Glossary. Informational. R Shirey.
          2000
          http://www.ietf.org/rfc/rfc2828.txt

   HTTP
          RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1. Internet
          Official Protocol Standards. J. Gettys, J. Mogul, H. Frystyk,
          L. Masinter, P. Leach, T. Berners-Lee. June 1999.

Reagle, J.                 Expires October 2002                 [Page 3] 

Internet-Draft           XML Encryption Media-Type              June 2002 

          http://www.ietf.org/rfc/rfc2616.txt

   KEYWORDS
          RFC 2119: Key words for use in RFCs to Indicate Requirement
          Levels. Best Current Practice. S. Bradner. March 1997.
          http://www.ietf.org/rfc/rfc2119.txt

   MIME
          RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part
          One: Format of Internet Message Bodies. Standards Track. N.
          Freed & N. Borenstein. November 1996.
          http://www.ietf.org/rfc/rfc2045.txt

   StLaurent
          Registration of xmlns Media Feature Tag. S. St.Laurent, and I.
          Graham. Draft.
          http://simonstl.com/ietf/draft-stlaurent-feature-xmlns-02.txt

   XENC
          XML Encryption Syntax and Processing. D. Eastlake, and J.
          Reagle. W3C Candidate Recommendation, 2002.
          http://www.w3.org/TR/2002/CR-xmlenc-core-20020304/

   XML
          Extensible Markup Language (XML) 1.0 (Second Edition). T. Bray,
          J. Paoli, C. M. Sperberg-McQueen, E. Maler. W3C Recommendation,
          October 2000.

   XML-MT
          RFC 3023: XML Media Types. Informational. M. Murata, S.
          St.Laurent, D Kohn. January 2001.
          http://www.ietf.org/rfc/rfc2376.txt

   XML-NS
          Namespaces in XML. T. Bray, D. Hollander, A. Layman. W3C
          Recommendation, January 1999.
          http://www.w3.org/TR/1999/REC-xml-names-19990114

   XML-schema
          XML Schema Part 1: Structures D. Beech, M. Maloney, N.
          Mendelsohn. W3C Recommendation, May 2001.
          http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
          XML Schema Part 2: Datatypes. P. Biron, A. Malhotra. W3C
          Recommendation, May 2001.
          http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

5. Authors' Address

   Joseph M. Reagle Jr., W3C
   Massachusetts Institute of Technology
   Laboratory for Computer Science

Reagle, J.                 Expires October 2002                 [Page 4] 

Internet-Draft           XML Encryption Media-Type              June 2002 

   NE43-358, 200 Technology Square
   Cambridge, MA 02139
   Phone: + 1.617.258.7621
   Email: [email-masked]

6. Full Copyright

   Copyright (C) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of developing
   Internet standards in which case the procedures for copyrights defined
   in the Internet Standards process must be followed, or as required to
   translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
   WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>From [email-masked]  Thu Aug 22 17:23:43 2002
From: ph at w3.org (Philipp Hoschka)
Date: Tue Jan  3 16:22:32 2006
Subject: CORRECTION: Please review ietf-draft of SMIL media-type registration
Message-ID: <[email-masked]>

[the previous mail contained a superfluous and inappropriate 
attachment, and an errouneous "reply-to" header - Apologies]

------

This email serves to instantiate the two week discussion 
period on "[email-masked]" of the ietf-draft describing
the SMIL media-type registration. You can find the draft at
http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-10.txt

The expected course of advancement for this specification is:
1. I have notified one of the Application area directors (Ned Freed)
2. Request publication as an Informational RFC as specified:
  ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt
3. Ensure IANA is aware of the publication and posts the registration as 
specified:
  ftp://ftp.isi.edu/in-notes/rfc2048.txt

The changes in this specification since the last version discussed on 
"[email-masked]" include:
1. Registration of application/xml+smil in addition to application/smil
2. Addition of optional "profile" parameter
3. Addition of paragraph describing how to recognize SMIL files by
   looking into the file.

Thank you.

-- 

-Philipp Hoschka

From: [email-masked] (Philipp Hoschka)
Date: Thu, 22 Aug 2002 14:42:55 +0200
Subject: Please review ietf-draft of SMIL media-type registration
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.
--------------3E057BDBA78E6604561A8263
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This email serves to instantiate the two week discussion 
period on "[email-masked]" of the ietf-draft describing
the SMIL media-type registration. You can find the draft at
http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-10.txt

The expected course of advancement for this specification is:
1. I have notified one of the Application area directors (Ned Freed)
2. Request publication as an Informational RFC as specified:
  ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt
3. Ensure IANA is aware of the publication and posts the registration as 
specified:
  ftp://ftp.isi.edu/in-notes/rfc2048.txt

The changes in this specification since the last version discussed on 
"[email-masked]" include:
1. Registration of application/xml+smil in addition to application/smil
2. Addition of optional "profile" parameter
3. Addition of paragraph describing how to recognize SMIL files by
   looking into the file.

Thank you.

-- 

-Philipp Hoschka
--------------3E057BDBA78E6604561A8263
Content-Type: text/plain; charset=iso-8859-1;
 name="draft-reagle-xenc-mediatype-00.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="draft-reagle-xenc-mediatype-00.txt"

--------------3E057BDBA78E6604561A8263--

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:32 2006
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <[email-masked]>
References: <000f01c23f27$f6330b50$06432099@masinter> <000f01c23f27$f6330b50$06432099@masinter>
Message-ID: <4.2.0.58.J.20020820111249.03c13680@localhost>

Hello Aaron, dear RDF Core WG,

On [email-masked] and some related list, we were just looking
at http://www.w3.org/TR/xmlenc-core/#sec-MediaType which containes
some instances of text like this:

    Same as ... of application/xml as specified in RFC 3023[XML-MT]
    or the most recent specification that supercedes it.

There seemed to be general agreement that a moving target is
not a good idea.

Josef Reagle told us that he got that text from:
http://www.aaronsw.com/2002/rdf-mediatype.html

I wanted to tell you that you may want to fix this.

Regards,   Martin.

At 14:47 02/08/19 -0400, Joseph Reagle wrote:
>On Thursday 08 August 2002 06:07 pm, Larry Masinter wrote:
> > # Optional parameters: charset
> > #  Same as charset parameter of application/xml as
> > #  specified in RFC 3023 [XML-MT] or the most recent
> > #  specification that supersedes it.
> >
> > I admit I was a little confused on this one, and misread
> > what it said. However, I don't understand
> > "or the most recent specification that supersedes it",
> > though, since a specification may supercede RFC 3023
> > but not be appropriate for a reference to a particular
> > section.
>
>I'm happy to eliminate that text as I oppose those sort of references in
>general. In this case, I was merely following what I could see the rdf
>folks doing for a similar type of registration:
>   http://www.aaronsw.com/2002/rdf-mediatype.html
>

From: [email-masked] (Martin Duerst)
Date: Tue, 20 Aug 2002 11:19:58 +0900
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <[email-masked]>
References: <000f01c23f27$f6330b50$06432099@masinter> <000f01c23f27$f6330b50$06432099@masinter>
Message-ID: <4.2.0.58.J.20020820111249.03c13680@localhost>

Hello Aaron, dear RDF Core WG,

On [email-masked] and some related list, we were just looking
at http://www.w3.org/TR/xmlenc-core/#sec-MediaType which containes
some instances of text like this:

    Same as ... of application/xml as specified in RFC 3023[XML-MT]
    or the most recent specification that supercedes it.

There seemed to be general agreement that a moving target is
not a good idea.

Josef Reagle told us that he got that text from:
http://www.aaronsw.com/2002/rdf-mediatype.html

I wanted to tell you that you may want to fix this.

Regards,   Martin.

At 14:47 02/08/19 -0400, Joseph Reagle wrote:
>On Thursday 08 August 2002 06:07 pm, Larry Masinter wrote:
> > # Optional parameters: charset
> > #  Same as charset parameter of application/xml as
> > #  specified in RFC 3023 [XML-MT] or the most recent
> > #  specification that supersedes it.
> >
> > I admit I was a little confused on this one, and misread
> > what it said. However, I don't understand
> > "or the most recent specification that supersedes it",
> > though, since a specification may supercede RFC 3023
> > but not be appropriate for a reference to a particular
> > section.
>
>I'm happy to eliminate that text as I oppose those sort of references in
>general. In this case, I was merely following what I could see the rdf
>folks doing for a similar type of registration:
>   http://www.aaronsw.com/2002/rdf-mediatype.html
>

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:32 2006
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <000f01c23f27$f6330b50$06432099@masinter>
References: <[email-masked]>
Message-ID: <4.2.0.58.J.20020809121436.0494fde8@localhost>

At 15:07 02/08/08 -0700, Larry Masinter wrote:
>What it actually says is:
>
># Optional parameters: charset
>
>#  Same as charset parameter of application/xml as
>#  specified in RFC 3023 [XML-MT] or the most recent
>#  specification that supersedes it.
>
>I admit I was a little confused on this one, and misread
>what it said. However, I don't understand
>"or the most recent specification that supersedes it",
>though, since a specification may supercede RFC 3023
>but not be appropriate for a reference to a particular
>section. None of the other references (to XML, DES,
>HTTP, MIME, etc.) have this qualification (that they
>refer to either the current version or anything that
>supersedes it.)

I agree with Larry that a moving target is a bad idea.
At W3C, we use (mostly) dated references, don't we :-).

>I would prefer if the reference were more specific about
>what was the "same": the same syntax, the same set of
>allowable values, the same recommendation for use of
>particular values, the same interpretation of defaults,
>or all of the above. Assuming you mean 'all of the above',
>you could be more explicit:
>
> >  Optional parameters: charset
> >
> >   The allowable and recommended values for, and interpretation
> >   of the charset parameter are identical to those given
> >   for 'application/xml' in section 3.2 of RFC 3023.

I'm not sure this is a good idea. It may lead to
questions such as 'and what about the default value,
is that different',... In other words, trying to list
up all the aspects in which the charset parameter for
application/xenc+xml is the same as that for application/xml
is a futile exercise; not listing any aspects and therefore
making clear that it's everything makes things clearer
and easier, I guess.

>I'm a little concerned about allowing arbitrary charset
>values for the entire application/xml+enc body, though,
>when any encrypted data are always UTF-8 encoded.
>Is it expected that the decryption algorithm do transcoding?
>Shouldn't the behavior of the processor with non-UTF-8
>encoded xml+enc bodies be discussed?

As far as I remember it, encryption does something like
the following:
1) Convert the necessary pieces to UTF-8 (from the encoding
    the document is in)
2) Encrypt the UTF-8 bytes
3) 'Textify' the result of the encryption by using base64

The decryption algorithm has to reverse these steps,
including step 1).

Allowing arbitrary charset values for application/xml+enc
is no problem. First, these values will apply to the
non-encrypted pieces of the document. (I can obviously
have something like <ds:KeyName>????</ds:KeyName>)
Second, once the encrypted part is textified as base64,
that text can still be encoded in us-ascii (which would
be covered by UTF-8) or in ebcdic or utf-16,...

So what I think may make sense is to add something like:

Note: The character encoding denoted by the "charset"
parameter is the character encoding of the resulting XML
document after encoding.

> > > > the 'encoding considerations'
> >
>http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/#sec-MediaType-Regi
>stration
>
>Again, I would prefer if the reference were more explicit
>about exactly was 'the same'.

Again, in general I would disagree here.

>You might even note that because
>encrypted data is encoded in base64 that encrypted data
>may have different encoding requirements than the data
>it replaces.

Good point.

># Published specification: this document.

I think that 'published specification: this document' is quite
dangerous. Assume somebody (that may be IANA) copies the registration
only for their own purposes. Then the reference is lost.

Regards,    Martin.

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:32 2006
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <003601c23e69$c1359e40$06432099@masinter> <[email-masked]>
Message-ID: <4.2.0.58.J.20020809122628.0293cb78@localhost>

At 15:00 02/08/08 -0400, Joseph Reagle wrote:
>The specification says, "This media-type is only used for documents in which
>the EncryptedData and EncryptedKey element types appear as the root element
>of the XML document." I'm not sure how to be much more clear than that?

Well, change "EncryptedData and EncryptedKey" to
"EncryptedData or EncryptedKey". I haven't seen
an XML doc yet with two root elements.

Regards,    Martin.

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:32 2006
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <003601c23e69$c1359e40$06432099@masinter> <[email-masked]>
Message-ID: <4.2.0.58.J.20020809121034.04982160@localhost>

At 15:00 02/08/08 -0400, Joseph Reagle wrote:
>As Ned and Martin point out, the intent is to express the fact that
>"application/xenc+xml" is XML, and consequently shares the same charset and
>encoding semantics/processing as that defined in RFC 3023.

Well, what the spec currently writes is okay, but what
you just write above is not:

The intent is to say that application/xenc+xml shares the same
charset behaviour as application/xml defined in RFC 3023.
(text/xml behaves differently)

Regards,   Martin.

From: [email-masked] (Martin Duerst)
Date: Fri, 09 Aug 2002 12:45:14 +0900
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <000f01c23f27$f6330b50$06432099@masinter>
References: <[email-masked]>
Message-ID: <4.2.0.58.J.20020809121436.0494fde8@localhost>

At 15:07 02/08/08 -0700, Larry Masinter wrote:
>What it actually says is:
>
># Optional parameters: charset
>
>#  Same as charset parameter of application/xml as
>#  specified in RFC 3023 [XML-MT] or the most recent
>#  specification that supersedes it.
>
>I admit I was a little confused on this one, and misread
>what it said. However, I don't understand
>"or the most recent specification that supersedes it",
>though, since a specification may supercede RFC 3023
>but not be appropriate for a reference to a particular
>section. None of the other references (to XML, DES,
>HTTP, MIME, etc.) have this qualification (that they
>refer to either the current version or anything that
>supersedes it.)

I agree with Larry that a moving target is a bad idea.
At W3C, we use (mostly) dated references, don't we :-).

>I would prefer if the reference were more specific about
>what was the "same": the same syntax, the same set of
>allowable values, the same recommendation for use of
>particular values, the same interpretation of defaults,
>or all of the above. Assuming you mean 'all of the above',
>you could be more explicit:
>
> >  Optional parameters: charset
> >
> >   The allowable and recommended values for, and interpretation
> >   of the charset parameter are identical to those given
> >   for 'application/xml' in section 3.2 of RFC 3023.

I'm not sure this is a good idea. It may lead to
questions such as 'and what about the default value,
is that different',... In other words, trying to list
up all the aspects in which the charset parameter for
application/xenc+xml is the same as that for application/xml
is a futile exercise; not listing any aspects and therefore
making clear that it's everything makes things clearer
and easier, I guess.

>I'm a little concerned about allowing arbitrary charset
>values for the entire application/xml+enc body, though,
>when any encrypted data are always UTF-8 encoded.
>Is it expected that the decryption algorithm do transcoding?
>Shouldn't the behavior of the processor with non-UTF-8
>encoded xml+enc bodies be discussed?

As far as I remember it, encryption does something like
the following:
1) Convert the necessary pieces to UTF-8 (from the encoding
    the document is in)
2) Encrypt the UTF-8 bytes
3) 'Textify' the result of the encryption by using base64

The decryption algorithm has to reverse these steps,
including step 1).

Allowing arbitrary charset values for application/xml+enc
is no problem. First, these values will apply to the
non-encrypted pieces of the document. (I can obviously
have something like <ds:KeyName>鈴木太郎</ds:KeyName>)
Second, once the encrypted part is textified as base64,
that text can still be encoded in us-ascii (which would
be covered by UTF-8) or in ebcdic or utf-16,...

So what I think may make sense is to add something like:

Note: The character encoding denoted by the "charset"
parameter is the character encoding of the resulting XML
document after encoding.

> > > > the 'encoding considerations'
> >
>http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/#sec-MediaType-Regi
>stration
>
>Again, I would prefer if the reference were more explicit
>about exactly was 'the same'.

Again, in general I would disagree here.

>You might even note that because
>encrypted data is encoded in base64 that encrypted data
>may have different encoding requirements than the data
>it replaces.

Good point.

># Published specification: this document.

I think that 'published specification: this document' is quite
dangerous. Assume somebody (that may be IANA) copies the registration
only for their own purposes. Then the reference is lost.

Regards,    Martin.

From: [email-masked] (Martin Duerst)
Date: Fri, 09 Aug 2002 12:27:56 +0900
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <003601c23e69$c1359e40$06432099@masinter> <[email-masked]>
Message-ID: <4.2.0.58.J.20020809122628.0293cb78@localhost>

At 15:00 02/08/08 -0400, Joseph Reagle wrote:
>The specification says, "This media-type is only used for documents in which
>the EncryptedData and EncryptedKey element types appear as the root element
>of the XML document." I'm not sure how to be much more clear than that?

Well, change "EncryptedData and EncryptedKey" to
"EncryptedData or EncryptedKey". I haven't seen
an XML doc yet with two root elements.

Regards,    Martin.

From: [email-masked] (Martin Duerst)
Date: Fri, 09 Aug 2002 12:14:13 +0900
Subject: draft-reagle-xenc-mediatype-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <003601c23e69$c1359e40$06432099@masinter> <[email-masked]>
Message-ID: <4.2.0.58.J.20020809121034.04982160@localhost>

At 15:00 02/08/08 -0400, Joseph Reagle wrote:
>As Ned and Martin point out, the intent is to express the fact that
>"application/xenc+xml" is XML, and consequently shares the same charset and
>encoding semantics/processing as that defined in RFC 3023.

Well, what the spec currently writes is okay, but what
you just write above is not:

The intent is to say that application/xenc+xml shares the same
charset behaviour as application/xml defined in RFC 3023.
(text/xml behaves differently)

Regards,   Martin.

From: matti.s.hamalainen at nokia.com ([email-masked])
Date: Tue Jan  3 16:22:32 2006
Subject: Please review: audio/sp-midi MIME type registration
Message-ID: <[email-masked]>

Hi,
(1) Oops.

(2) MMA documents can be ordered from the Internet from MMA web site http://www.midi.org/. Some MMA publications can be downloaded freely from their WEB site but SP-MIDI documents would need to be ordered. Publishing is a source of income for MMA. I believe the situation is similar e.g. with MPEG-4 documentation w.r.t MIME registration. Membership is open to anyone commercially involved in the design or manufacture of MIDI hardware or software. 

(3) I believe this would be OK since all references are (non-IETF) published specifications. Some IDs seem to have references included as an appendix.

BR,
Matti
>-----Original Message-----
>From: ext Graham Klyne [mailto:[email-masked]]
>Sent: 21 July, 2002 21:24
>To: Hamalainen Matti.S (NRC/Tampere)
>Cc: [email-masked]
>Subject: Re: Please review: audio/sp-midi MIME type registration
>
>
>(1) typo in security considerations  "don not".
>
>(2) are the specification documents freely available on the 
>Internet?  If 
>not, I wonder if a vnd-tree registration might not be more 
>appropriate?  If 
>they are, URLs would be helpful.
>
>(3) I think maybe the references should appear in the "published 
>specifications" section of the registration template, since 
>that appears in 
>the MIME type registry.
>
>#g
>--
>
>At 12:01 AM 7/20/02 +0300, [email-masked] wrote:
>
>
>> 
>>M. Hamalainen
>>                Internet 
>> Draft                                                    Nokia
>>                Document: 
>> draft-SP-MIDI-MIME-type-01.txt                       T. White
>> 
>>MMA
>>                Expires: January 
>> 2003                                         July 2002
>>
>>
>>                               Registration of MIME media 
>type audio/sp-midi
>>
>>
>>                Status of this Memo
>>
>>                   This document is an Internet-Draft and is 
>subject to 
>> all provisions
>>                   of Section 10 of RFC2026 except that the right to 
>> produce derivative
>>                   works is not granted.
>>
>>                   Internet-Drafts are working documents of 
>the Internet 
>> Engineering
>>                   Task Force (IETF), its areas, and its working 
>> groups.  Note that
>>                   other groups may also distribute working 
>documents as 
>> Internet-
>>                   Drafts.
>>
>>                   Internet-Drafts are draft documents valid 
>for a maximum 
>> of six
>>                   months and may be updated, replaced, or 
>obsoleted by 
>> other documents
>>                   at any time.  It is inappropriate to use 
>> Internet-Drafts as
>>                   reference material or to cite them other 
>than as "work 
>> in progress."
>>
>>                   The list of current Internet-Drafts can be 
>accessed at
>>                        http://www.ietf.org/ietf/1id-abstracts.txt
>>                   The list of Internet-Draft Shadow 
>Directories can be 
>> accessed at
>>                        http://www.ietf.org/shadow.html.
>>
>>
>>                Abstract
>>
>>                   MIDI Manufacturers Association (MMA) and 
>Association of 
>> Music
>>                   Electronics industry (AMEI) have recently 
>produced the 
>> Scalable
>>                   Polyphony MIDI (SP-MIDI) standard [1]. The SP-MIDI 
>> standard has been
>>                   developed in particularly for mobile MIDI 
>applications. 
>> SP-MIDI has
>>                   been approved for 3GPP standardization and 
>a dedicated 
>> SP-MIDI
>>                   profile has been defined for 3GPP SP-MIDI 
>devices [2]. 
>> Since MIDI
>>                   information is a very compact media type 3GPP is 
>> initially focusing
>>                   on the application of SP-MIDI for music 
>downloading and 
>> messaging
>>                   applications that require MIME registration.
>>
>>
>>
>>
>>
>>
>>
>>
>>                1 Introduction
>>
>>
>>                Hamalainen & 
>> White                                            [Page 1]
>>
>>                                             SP-MIDI 
>> MIME                   July, 2002
>>
>>                   MIDI content is commonly used in the 
>Internet, however 
>> such use is
>>                   based on informal ad hoc MIME type 
>definitions that 
>> have not been
>>                   registered by IETF. The present MIME type 
>registration 
>> is harmonized
>>                   with the typical Internet usage of unregistered 
>> audio/midi and
>>                   audio/x-midi MIME types. Commonly MIDI 
>information is 
>> stored in the
>>                   Standard MIDI File (SMF) format [3]. The 
>present MIME type
>>                   registration also uses the SMF file format for the 
>> encapsulation of
>>                   SP-MIDI data. Whereas previous MIDI 
>specifications have 
>> been based
>>                   on common minimum requirements for all 
>playback devices 
>> supporting
>>                   the same specification, SP-MIDI is able to 
>support a 
>> wider range of
>>                   playback devices because playback 
>adaptations can be 
>> encoded in the
>>                   MIDI content. Due to these differences, a 
>separate MIME 
>> type,
>>                   audio/sp-midi, needs to be registered to 
>distinguish 
>> SP-MIDI
>>                   content.
>>
>>                2 Registration of audio/sp-midi
>>
>>                   MIME media type name: audio
>>
>>                   MIME subtype name: sp-midi
>>
>>                   Required parameters: none
>>
>>                   Optional parameters: none
>>
>>                   Encoding considerations:
>>
>>                        sp-midi data is binary data and must 
>be encoded 
>> for non-binary
>>                        transport; Base64 is suitable for Email
>>
>>                   Security considerations:
>>
>>                        Many synthetic audio compositions 
>have associated 
>> intellectual
>>                        property rights. It is conceivable 
>that rights 
>> owners of sp-
>>                        midi content will want to protect 
>their rights by 
>> applying
>>                        security mechanisms that prohibit the 
>rendering of 
>> the content
>>                        without a legally acquired license to 
>do so. These 
>> mechanisms
>>                        would be applied externally to the 
>Content-Type 
>> defined here;
>>                        sp-midi content itself is not encrypted 
>> internally. sp-midi
>>                        streams don not contain executable content.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>                Hamalainen & White           January 
>> 2003                     [Page 2]
>>
>>                                             SP-MIDI 
>> MIME                   July, 2002
>>
>>                   Interoperability considerations:
>>
>>                        Scalable Polyphony MIDI (SP-MIDI) is 
>a Musical 
>> Instrument
>>                        Digital Interface (MIDI) 
>specification developed 
>> by MMA and
>>                        AMEI. SP-MIDI is based on the MIDI 1.0 
>> specification [3] which
>>                        standardizes a protocol for the electronic 
>> transmission of
>>                        music as data suitable for 
>communication between a 
>> transmitter
>>                        and receiver using MIDI messages. 
>SP-MIDI data is 
>> stored in
>>                        Standard MIDI Files (SMF) [3].
>>
>>                        The SP-MIDI format [1] provides scalable 
>> representation of MIDI
>>                        content which enables broadly 
>interoperable music 
>> applications.
>>                        SP-MIDI files have encoded 
>information about playback
>>                        requirements which allows SP-MIDI 
>playback devices 
>> with
>>                        different device capabilities to play 
>the same 
>> content
>>                        according to composer's polyphony 
>requirement and 
>> Channel
>>                        priority order definitions. SP-MIDI player 
>> requirements are
>>                        defined in separate SP-MIDI profile 
>specifications 
>> [2] defining
>>                        the supported MIDI messages and device 
>> requirement. All SP-MIDI
>>                        profiles follow the definitions of 
>the SP-MIDI 
>> specification
>>                        [1].
>>
>>                        MMA and AMEI have previously defined 
>the General 
>> MIDI (GM)
>>                        system standards GM1 [4] GM2 [5], and 
>GML [6]. These
>>                        specifications are technically 
>related to the SP-MIDI
>>                        specification, but do not support polyphony 
>> scalability. Due to
>>                        the differences between GM and 
>SP-MIDI systems GM 
>> synthesizers
>>                        do not support all SP-MIDI content, 
>and likewise 
>> not all SP-
>>                        MIDI synthesizers support all GM 
>content. Thus a 
>> separate MIME
>>                        definition is needed to distinguish 
>SP-MIDI, media 
>> from the
>>                        informally used audio/midi content.
>>
>>                   Published specification:
>>
>>                        There are no previous RFC documents 
>on SP-MIDI.
>>
>>                   Applications which use this media type:
>>
>>                        SP-MIDI is a synthetic audio format 
>for the flexible
>>                        presentation of MIDI data on a wide range of 
>> playback devices,
>>                        particularly portable appliances such 
>as mobile 
>> phones, PDAs,
>>                        and palmtop computers.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>                Hamalainen & White           January 
>> 2003                     [Page 3]
>>
>>                                             SP-MIDI 
>> MIME                   July, 2002
>>
>>
>>                   Additional information:
>>
>>                   Magic number(s):
>>                        First four bytes (1-4): \115\124\150\144,
>>                        byte (24): \360,
>>                        byte (26): \177,
>>                        bytes (28-29): \013\001
>>
>>                   File extension(s): mid
>>
>>                   Macintosh File Type Code(s): mid
>>
>>                   Intended usage: COMMON
>>
>>
>>                3 IANA Considerations
>>
>>                   Section 2 of this document registers one 
>MIME subtype.
>>
>>                4 Security Considerations
>>
>>                   Security considerations are specified in 
>the MIME subtype
>>                   registration contained in Section 2.
>>
>>                5 Authors' Addresses
>>
>>                        Matti Hamalainen
>>                        Nokia
>>                        P.O. Box 100 (Visiokatu 1)
>>                        FIN-33721 Tampere, Finland
>>                        Tel: +358 7180 35789
>>                        Fax: +358 7180 35899
>>
>>                        Email: [email-masked]
>>
>>
>>                        Tom White,
>>                        MIDI Manufacturers Association
>>                        P.O. Box 3173
>>                        La Habra CA
>>                        90632-3173
>>                        Tel (714) 736-9774
>>                        Fax (714) 736-9775
>>
>>                        Email: [email-masked]
>>
>>
>>
>>
>>
>>
>>
>>
>>                Hamalainen & White           January 
>> 2003                     [Page 4]
>>
>>                                             SP-MIDI 
>> MIME                   July, 2002
>>
>>
>>
>>
>>                   Author/Change controller:
>>
>>                        Matti Hamalainen
>>                        Nokia
>>                        P.O. Box 100 (Visiokatu 1)
>>                        FIN-33721 Tampere, Finland
>>                        Tel: +358 7180 35789
>>                        Fax: +358 7180 35899
>>                        [email-masked]
>>
>>
>>
>>                References
>>
>>                   1 Scalable Polyphony MIDI Specification. 
>December 2001, 
>> RP-034, The
>>                      MIDI Manufacturers Association, Los 
>Angeles, CA, USA.
>>                   2 Scalable Polyphony MIDI Device 5-24 Note 
>Profile for 
>> 3GPP,
>>                      December 2001, RP-035, The MIDI Manufacturers 
>> Association, Los
>>                      Angeles, CA, USA.
>>                   3 MIDI 1.0 Detailed Specification, 
>Document Version 
>> 4.2. February
>>                      1996, In 'The Complete MIDI 1.0 Detailed 
>> Specification, Document
>>                      Version 96.1.' The MIDI Manufacturers 
>Association., 
>> Los Angeles,
>>                      CA, USA.
>>                   4 General MIDI System Level 1. 1994, 
>MMA0007/RP003, In 
>> 'The Complete
>>                      MIDI 1.0 Detailed Specification, 
>Document Version 
>> 96.1.' The MIDI
>>                      Manufacturers Association, Los Angeles, CA, USA.
>>                   5 General MIDI Level 2 Specification (Recommended 
>> Practice).
>>                      November 1999, RP-024, The MIDI Manufacturers 
>> Association, Los
>>                      Angeles, CA, USA.
>>                   6 General MIDI Lite, Specification for GM Lite and 
>> Guidelines for
>>                      Use In Mobile Applications. October 5, 
>2001, RP-033, 
>> Version 1.0,
>>                      The MIDI Manufacturers Association, Los 
>Angeles, CA, 
>> USA.
>>
>>
>>                Hamalainen & White           January 
>> 2003                     [Page 5]
>>
>>_______________________________________________
>>Ietf-types mailing list
>>[email-masked]
>>http://www.alvestrand.no/mailman/listinfo/ietf-types
>
>-------------------
>Graham Klyne
><[email-masked]>
>
>

From: [email-masked] ([email-masked])
Date: Wed, 7 Aug 2002 20:47:37 +0300
Subject: Please review: audio/sp-midi MIME type registration
Message-ID: <[email-masked]>

Hi,
(1) Oops.

(2) MMA documents can be ordered from the Internet from MMA web site =
http://www.midi.org/. Some MMA publications can be downloaded freely =
from their WEB site but SP-MIDI documents would need to be ordered. =
Publishing is a source of income for MMA. I believe the situation is =
similar e.g. with MPEG-4 documentation w.r.t MIME registration. =
Membership is open to anyone commercially involved in the design or =
manufacture of MIDI hardware or software.=20

(3) I believe this would be OK since all references are (non-IETF) =
published specifications. Some IDs seem to have references included as =
an appendix.

BR,
Matti
>-----Original Message-----
>From: ext Graham Klyne [mailto:[email-masked]]
>Sent: 21 July, 2002 21:24
>To: Hamalainen Matti.S (NRC/Tampere)
>Cc: [email-masked]
>Subject: Re: Please review: audio/sp-midi MIME type registration
>
>
>(1) typo in security considerations  "don not".
>
>(2) are the specification documents freely available on the=20
>Internet?  If=20
>not, I wonder if a vnd-tree registration might not be more=20
>appropriate?  If=20
>they are, URLs would be helpful.
>
>(3) I think maybe the references should appear in the "published=20
>specifications" section of the registration template, since=20
>that appears in=20
>the MIME type registry.
>
>#g
>--
>
>At 12:01 AM 7/20/02 +0300, [email-masked] wrote:
>
>
>>=20
>>M. Hamalainen
>>                Internet=20
>> Draft                                                    Nokia
>>                Document:=20
>> draft-SP-MIDI-MIME-type-01.txt                       T. White
>>=20
>>MMA
>>                Expires: January=20
>> 2003                                         July 2002
>>
>>
>>                               Registration of MIME media=20
>type audio/sp-midi
>>
>>
>>                Status of this Memo
>>
>>                   This document is an Internet-Draft and is=20
>subject to=20
>> all provisions
>>                   of Section 10 of RFC2026 except that the right to=20
>> produce derivative
>>                   works is not granted.
>>
>>                   Internet-Drafts are working documents of=20
>the Internet=20
>> Engineering
>>                   Task Force (IETF), its areas, and its working=20
>> groups.  Note that
>>                   other groups may also distribute working=20
>documents as=20
>> Internet-
>>                   Drafts.
>>
>>                   Internet-Drafts are draft documents valid=20
>for a maximum=20
>> of six
>>                   months and may be updated, replaced, or=20
>obsoleted by=20
>> other documents
>>                   at any time.  It is inappropriate to use=20
>> Internet-Drafts as
>>                   reference material or to cite them other=20
>than as "work=20
>> in progress."
>>
>>                   The list of current Internet-Drafts can be=20
>accessed at
>>                        http://www.ietf.org/ietf/1id-abstracts.txt
>>                   The list of Internet-Draft Shadow=20
>Directories can be=20
>> accessed at
>>                        http://www.ietf.org/shadow.html.
>>
>>
>>                Abstract
>>
>>                   MIDI Manufacturers Association (MMA) and=20
>Association of=20
>> Music
>>                   Electronics industry (AMEI) have recently=20
>produced the=20
>> Scalable
>>                   Polyphony MIDI (SP-MIDI) standard [1]. The SP-MIDI=20
>> standard has been
>>                   developed in particularly for mobile MIDI=20
>applications.=20
>> SP-MIDI has
>>                   been approved for 3GPP standardization and=20
>a dedicated=20
>> SP-MIDI
>>                   profile has been defined for 3GPP SP-MIDI=20
>devices [2].=20
>> Since MIDI
>>                   information is a very compact media type 3GPP is=20
>> initially focusing
>>                   on the application of SP-MIDI for music=20
>downloading and=20
>> messaging
>>                   applications that require MIME registration.
>>
>>
>>
>>
>>
>>
>>
>>
>>                1 Introduction
>>
>>
>>                Hamalainen &=20
>> White                                            [Page 1]
>>
>>                                             SP-MIDI=20
>> MIME                   July, 2002
>>
>>                   MIDI content is commonly used in the=20
>Internet, however=20
>> such use is
>>                   based on informal ad hoc MIME type=20
>definitions that=20
>> have not been
>>                   registered by IETF. The present MIME type=20
>registration=20
>> is harmonized
>>                   with the typical Internet usage of unregistered=20
>> audio/midi and
>>                   audio/x-midi MIME types. Commonly MIDI=20
>information is=20
>> stored in the
>>                   Standard MIDI File (SMF) format [3]. The=20
>present MIME type
>>                   registration also uses the SMF file format for the=20
>> encapsulation of
>>                   SP-MIDI data. Whereas previous MIDI=20
>specifications have=20
>> been based
>>                   on common minimum requirements for all=20
>playback devices=20
>> supporting
>>                   the same specification, SP-MIDI is able to=20
>support a=20
>> wider range of
>>                   playback devices because playback=20
>adaptations can be=20
>> encoded in the
>>                   MIDI content. Due to these differences, a=20
>separate MIME=20
>> type,
>>                   audio/sp-midi, needs to be registered to=20
>distinguish=20
>> SP-MIDI
>>                   content.
>>
>>                2 Registration of audio/sp-midi
>>
>>                   MIME media type name: audio
>>
>>                   MIME subtype name: sp-midi
>>
>>                   Required parameters: none
>>
>>                   Optional parameters: none
>>
>>                   Encoding considerations:
>>
>>                        sp-midi data is binary data and must=20
>be encoded=20
>> for non-binary
>>                        transport; Base64 is suitable for Email
>>
>>                   Security considerations:
>>
>>                        Many synthetic audio compositions=20
>have associated=20
>> intellectual
>>                        property rights. It is conceivable=20
>that rights=20
>> owners of sp-
>>                        midi content will want to protect=20
>their rights by=20
>> applying
>>                        security mechanisms that prohibit the=20
>rendering of=20
>> the content
>>                        without a legally acquired license to=20
>do so. These=20
>> mechanisms
>>                        would be applied externally to the=20
>Content-Type=20
>> defined here;
>>                        sp-midi content itself is not encrypted=20
>> internally. sp-midi
>>                        streams don not contain executable content.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>                Hamalainen & White           January=20
>> 2003                     [Page 2]
>>
>>                                             SP-MIDI=20
>> MIME                   July, 2002
>>
>>                   Interoperability considerations:
>>
>>                        Scalable Polyphony MIDI (SP-MIDI) is=20
>a Musical=20
>> Instrument
>>                        Digital Interface (MIDI)=20
>specification developed=20
>> by MMA and
>>                        AMEI. SP-MIDI is based on the MIDI 1.0=20
>> specification [3] which
>>                        standardizes a protocol for the electronic=20
>> transmission of
>>                        music as data suitable for=20
>communication between a=20
>> transmitter
>>                        and receiver using MIDI messages.=20
>SP-MIDI data is=20
>> stored in
>>                        Standard MIDI Files (SMF) [3].
>>
>>                        The SP-MIDI format [1] provides scalable=20
>> representation of MIDI
>>                        content which enables broadly=20
>interoperable music=20
>> applications.
>>                        SP-MIDI files have encoded=20
>information about playback
>>                        requirements which allows SP-MIDI=20
>playback devices=20
>> with
>>                        different device capabilities to play=20
>the same=20
>> content
>>                        according to composer's polyphony=20
>requirement and=20
>> Channel
>>                        priority order definitions. SP-MIDI player=20
>> requirements are
>>                        defined in separate SP-MIDI profile=20
>specifications=20
>> [2] defining
>>                        the supported MIDI messages and device=20
>> requirement. All SP-MIDI
>>                        profiles follow the definitions of=20
>the SP-MIDI=20
>> specification
>>                        [1].
>>
>>                        MMA and AMEI have previously defined=20
>the General=20
>> MIDI (GM)
>>                        system standards GM1 [4] GM2 [5], and=20
>GML [6]. These
>>                        specifications are technically=20
>related to the SP-MIDI
>>                        specification, but do not support polyphony=20
>> scalability. Due to
>>                        the differences between GM and=20
>SP-MIDI systems GM=20
>> synthesizers
>>                        do not support all SP-MIDI content,=20
>and likewise=20
>> not all SP-
>>                        MIDI synthesizers support all GM=20
>content. Thus a=20
>> separate MIME
>>                        definition is needed to distinguish=20
>SP-MIDI, media=20
>> from the
>>                        informally used audio/midi content.
>>
>>                   Published specification:
>>
>>                        There are no previous RFC documents=20
>on SP-MIDI.
>>
>>                   Applications which use this media type:
>>
>>                        SP-MIDI is a synthetic audio format=20
>for the flexible
>>                        presentation of MIDI data on a wide range of=20
>> playback devices,
>>                        particularly portable appliances such=20
>as mobile=20
>> phones, PDAs,
>>                        and palmtop computers.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>                Hamalainen & White           January=20
>> 2003                     [Page 3]
>>
>>                                             SP-MIDI=20
>> MIME                   July, 2002
>>
>>
>>                   Additional information:
>>
>>                   Magic number(s):
>>                        First four bytes (1-4): \115\124\150\144,
>>                        byte (24): \360,
>>                        byte (26): \177,
>>                        bytes (28-29): \013\001
>>
>>                   File extension(s): mid
>>
>>                   Macintosh File Type Code(s): mid
>>
>>                   Intended usage: COMMON
>>
>>
>>                3 IANA Considerations
>>
>>                   Section 2 of this document registers one=20
>MIME subtype.
>>
>>                4 Security Considerations
>>
>>                   Security considerations are specified in=20
>the MIME subtype
>>                   registration contained in Section 2.
>>
>>                5 Authors' Addresses
>>
>>                        Matti Hamalainen
>>                        Nokia
>>                        P.O. Box 100 (Visiokatu 1)
>>                        FIN-33721 Tampere, Finland
>>                        Tel: +358 7180 35789
>>                        Fax: +358 7180 35899
>>
>>                        Email: [email-masked]
>>
>>
>>                        Tom White,
>>                        MIDI Manufacturers Association
>>                        P.O. Box 3173
>>                        La Habra CA
>>                        90632-3173
>>                        Tel (714) 736-9774
>>                        Fax (714) 736-9775
>>
>>                        Email: [email-masked]
>>
>>
>>
>>
>>
>>
>>
>>
>>                Hamalainen & White           January=20
>> 2003                     [Page 4]
>>
>>                                             SP-MIDI=20
>> MIME                   July, 2002
>>
>>
>>
>>
>>                   Author/Change controller:
>>
>>                        Matti Hamalainen
>>                        Nokia
>>                        P.O. Box 100 (Visiokatu 1)
>>                        FIN-33721 Tampere, Finland
>>                        Tel: +358 7180 35789
>>                        Fax: +358 7180 35899
>>                        [email-masked]
>>
>>
>>
>>                References
>>
>>                   1 Scalable Polyphony MIDI Specification.=20
>December 2001,=20
>> RP-034, The
>>                      MIDI Manufacturers Association, Los=20
>Angeles, CA, USA.
>>                   2 Scalable Polyphony MIDI Device 5-24 Note=20
>Profile for=20
>> 3GPP,
>>                      December 2001, RP-035, The MIDI Manufacturers=20
>> Association, Los
>>                      Angeles, CA, USA.
>>                   3 MIDI 1.0 Detailed Specification,=20
>Document Version=20
>> 4.2. February
>>                      1996, In 'The Complete MIDI 1.0 Detailed=20
>> Specification, Document
>>                      Version 96.1.' The MIDI Manufacturers=20
>Association.,=20
>> Los Angeles,
>>                      CA, USA.
>>                   4 General MIDI System Level 1. 1994,=20
>MMA0007/RP003, In=20
>> 'The Complete
>>                      MIDI 1.0 Detailed Specification,=20
>Document Version=20
>> 96.1.' The MIDI
>>                      Manufacturers Association, Los Angeles, CA, USA.
>>                   5 General MIDI Level 2 Specification (Recommended=20
>> Practice).
>>                      November 1999, RP-024, The MIDI Manufacturers=20
>> Association, Los
>>                      Angeles, CA, USA.
>>                   6 General MIDI Lite, Specification for GM Lite and=20
>> Guidelines for
>>                      Use In Mobile Applications. October 5,=20
>2001, RP-033,=20
>> Version 1.0,
>>                      The MIDI Manufacturers Association, Los=20
>Angeles, CA,=20
>> USA.
>>
>>
>>                Hamalainen & White           January=20
>> 2003                     [Page 5]
>>
>>_______________________________________________
>>Ietf-types mailing list
>>[email-masked]
>>http://www.alvestrand.no/mailman/listinfo/ietf-types
>
>-------------------
>Graham Klyne
><[email-masked]>
>
>