August 2002 - Ietf-types

Re: CORRECTION: Please review ietf-draft of SMIL media-type registration
by Philipp Hoschka 27 Aug '02

27 Aug '02

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 ...

1 0

CORRECTION: Please review ietf-draft of SMIL media-type registration
by Philipp Hoschka 22 Aug '02

22 Aug '02

[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 "ietf-types(a)iana.org" 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 "ietf-xml-mime(a)imc.org" 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

1 0

Please review ietf-draft of SMIL media-type registration
by Philipp Hoschka 22 Aug '02

22 Aug '02

This email serves to instantiate the two week discussion period on "ietf-types(a)iana.org" 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 "ietf-xml-mime(a)imc.org" 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 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 xml-encryption(a)w3.org. To subscribe, send a message with the body 'subscribe' to xml-encryption(a)w3.org. 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 <reagle(a)w3.org> XENC Working Group <xml-encryption(a)w3.org> 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: reagle(a)w3.org 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.

1 0

Re: draft-reagle-xenc-mediatype-01.txt
by Martin Duerst 20 Aug '02

20 Aug '02

Hello Aaron, dear RDF Core WG, On ietf-types(a)iana.org 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 >

1 0

RE: draft-reagle-xenc-mediatype-01.txt
by Martin Duerst 09 Aug '02

09 Aug '02

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.

1 0

Re: draft-reagle-xenc-mediatype-01.txt
by Martin Duerst 09 Aug '02

09 Aug '02

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.

1 0

Re: draft-reagle-xenc-mediatype-01.txt
by Martin Duerst 09 Aug '02

09 Aug '02

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.

1 0

RE: Please review: audio/sp-midi MIME type registration
by matti.s.hamalainen＠nokia.com 07 Aug '02

07 Aug '02

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:GK@ninebynine.org] >Sent: 21 July, 2002 21:24 >To: Hamalainen Matti.S (NRC/Tampere) >Cc: ietf-types(a)iana.org >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, matti.s.hamalainen(a)nokia.com 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: matti.s.hamalainen(a)nokia.com >> >> >> Tom White, >> MIDI Manufacturers Association >> P.O. Box 3173 >> La Habra CA >> 90632-3173 >> Tel (714) 736-9774 >> Fax (714) 736-9775 >> >> Email: mma(a)midi.org >> >> >> >> >> >> >> >> >> 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 >> matti.s.hamalainen(a)nokia.com >> >> >> >> 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 >>Ietf-types(a)eikenes.alvestrand.no >>http://www.alvestrand.no/mailman/listinfo/ietf-types > >------------------- >Graham Klyne ><GK(a)NineByNine.org> > >

1 0