- Ietf-types - example.com

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

Re: Please review: audio/sp-midi MIME type registration
by Graham Klyne 21 Jul '02

21 Jul '02

(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

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

19 Jul '02

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]

1 0

[KOffice 1.2] app/vnd.kde.{kword,kspread,kpresenter,kformula,kchart,kivio,kontour,karbon}
by Marc Mutz 29 May '02

29 May '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Please find attached the registrations for the KOffice 1.2 mime types. Their texts are equal except for the names of applications and the file extensions, so you only need to read one. Marc - -- Marc Mutz <mutz(a)kde.org> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE88TXM3oWD+L2/6DgRApzFAKCBX5pzJb0nfwM0scg8xSRXI2G6CgCeK2vz /DlErD27Dvv5lKVZW4JSdDw= =ovXo -----END PGP SIGNATURE----- ***KWord*** To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.kde.kword MIME media type name: application MIME subtype name: vnd.kde.kword Required parameters: none Optional parameters: none Encoding considerations: Binary or base64 required Security considerations: As of this writing, KWord documents do not contain any active content. As such, it is believed that usage of this mimetype does not introduce security concerns other than those already inherent in ZIP archives, XML files and supported image files. It is expected that later versions of KWord feature scripting and macro recording facilities. It is, however, not intended to include active content into the KWord document itself. KWord documents include document metadata such as the name of the author, etc. However, none of this data is written automatically. The KWord user has full control over what metadata is to be included and must actively request the inclusion. As such, the use of this mimetype does not lead to hidden leaking of possibly sensitive data. Interoperability considerations: Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX tar files as archive format. It is expected that this obsolete format will die out soon after the first release of KOffice 1.2. Thus, this registration does not apply to the obsolete format. Implementations are expected to use the old application/x-kword mime type for the obsolete format. Published specification: A KWord document consists of a series of XML streams and externally generated content which are bundled together as a ZIP archive. Any content placed in KWord can either be completely embedded in the KWord document or can be linked to using URIs. The DTDs used in KOffice can be obtained from http://www.koffice.org/DTD/. A description of the storage format is contained in the source code distribution (lib/store/SPEC). The current version can be obtained online via KDE's WebCVS interface: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC Applications which use this media type: All applications in the KDE KOffice Office Suite, esp. KWord. Additional information: Magic numbers: This is an entry that can be used with the UNIX file(1) command's magic(4) file: 0 string PK\003\004 >30 string mimetype >>38 string application/vnd.kde.kword File extensions: KWT, KWD Macintosh File Type Codes: n/a Person & email address to contact for further information: David Faure <faure(a)kde.org> Intended usage: COMMON Author/Change contoller: Marc Mutz <mutz(a)kde.org> ***KSpread*** To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.kde.kspread MIME media type name: application MIME subtype name: vnd.kde.kspread Required parameters: none Optional parameters: none Encoding considerations: Binary or base64 required Security considerations: As of this writing, KSpread documents do not contain any active content. As such, it is believed that usage of this mimetype does not introduce security concerns other than those already inherent in ZIP archives, XML files and supported image files. It is expected that later versions of KSpread feature scripting and macro recording facilities. It is, however, not intended to include active content into the KSpread document itself. KSpread documents include document metadata such as the name of the author, etc. However, none of this data is written automatically. The KSpread user has full control over what metadata is to be included and must actively request the inclusion. As such, the use of this mimetype does not lead to hidden leaking of possibly sensitive data. Interoperability considerations: Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX tar files as archive format. It is expected that this obsolete format will die out soon after the first release of KOffice 1.2. Thus, this registration does not apply to the obsolete format. Implementations are expected to use the old application/x-kspread mime type for the obsolete format. Published specification: A KSpread document consists of a series of XML streams and externally generated content which are bundled together as a ZIP archive. Any content placed in KSpread can either be completely embedded in the KSpread document or can be linked to using URIs. The DTDs used in KOffice can be obtained from http://www.koffice.org/DTD/. A description of the storage format is contained in the source code distribution (lib/store/SPEC). The current version can be obtained online via KDE's WebCVS interface: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC Applications which use this media type: All applications in the KDE KOffice Office Suite, esp. KSpread. Additional information: Magic numbers: This is an entry that can be used with the UNIX file(1) command's magic(4) file: 0 string PK\003\004 >30 string mimetype >>38 string application/vnd.kde.kspread File extensions: KSP Macintosh File Type Codes: n/a Person & email address to contact for further information: David Faure <faure(a)kde.org> Intended usage: COMMON Author/Change contoller: Marc Mutz <mutz(a)kde.org> ***KPresenter*** To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.kde.kpresenter MIME media type name: application MIME subtype name: vnd.kde.kpresenter Required parameters: none Optional parameters: none Encoding considerations: Binary or base64 required Security considerations: As of this writing, KPresenter documents do not contain any active content. As such, it is believed that usage of this mimetype does not introduce security concerns other than those already inherent in ZIP archives, XML files and supported image files. It is expected that later versions of KPresenter feature scripting and macro recording facilities. It is, however, not intended to include active content into the KPresenter document itself. KPresenter documents include document metadata such as the name of the author, etc. However, none of this data is written automatically. The KPresenter user has full control over what metadata is to be included and must actively request the inclusion. As such, the use of this mimetype does not lead to hidden leaking of possibly sensitive data. Interoperability considerations: Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX tar files as archive format. It is expected that this obsolete format will die out soon after the first release of KOffice 1.2. Thus, this registration does not apply to the obsolete format. Implementations are expected to use the old application/x-kpresenter mime type for the obsolete format. Published specification: A KPresenter document consists of a series of XML streams and externally generated content which are bundled together as a ZIP archive. Any content placed in KPresenter can either be completely embedded in the KPresenter document or can be linked to using URIs. The DTDs used in KOffice can be obtained from http://www.koffice.org/DTD/. A description of the storage format is contained in the source code distribution (lib/store/SPEC). The current version can be obtained online via KDE's WebCVS interface: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC Applications which use this media type: All applications in the KDE KOffice Office Suite, esp. KPresenter. Additional information: Magic numbers: This is an entry that can be used with the UNIX file(1) command's magic(4) file: 0 string PK\003\004 >30 string mimetype >>38 string application/vnd.kde.kpresenter File extensions: KPR, KPT Macintosh File Type Codes: n/a Person & email address to contact for further information: David Faure <faure(a)kde.org> Intended usage: COMMON Author/Change contoller: Marc Mutz <mutz(a)kde.org> ***KFormula*** To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.kde.kformula MIME media type name: application MIME subtype name: vnd.kde.kformula Required parameters: none Optional parameters: none Encoding considerations: Binary or base64 required Security considerations: As of this writing, KFormula documents do not contain any active content. As such, it is believed that usage of this mimetype does not introduce security concerns other than those already inherent in ZIP archives, XML files and supported image files. It is expected that later versions of KFormula feature scripting and macro recording facilities. It is, however, not intended to include active content into the KFormula document itself. KFormula documents include document metadata such as the name of the author, etc. However, none of this data is written automatically. The KFormula user has full control over what metadata is to be included and must actively request the inclusion. As such, the use of this mimetype does not lead to hidden leaking of possibly sensitive data. Interoperability considerations: Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX tar files as archive format. It is expected that this obsolete format will die out soon after the first release of KOffice 1.2. Thus, this registration does not apply to the obsolete format. Implementations are expected to use the old application/x-kformula mime type for the obsolete format. Published specification: A KFormula document consists of a series of XML streams and externally generated content which are bundled together as a ZIP archive. Any content placed in KFormula can either be completely embedded in the KFormula document or can be linked to using URIs. The DTDs used in KOffice can be obtained from http://www.koffice.org/DTD/. A description of the storage format is contained in the source code distribution (lib/store/SPEC). The current version can be obtained online via KDE's WebCVS interface: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC Applications which use this media type: All applications in the KDE KOffice Office Suite, esp. KFormula. Additional information: Magic numbers: This is an entry that can be used with the UNIX file(1) command's magic(4) file: 0 string PK\003\004 >30 string mimetype >>38 string application/vnd.kde.kformula File extensions: KFO Macintosh File Type Codes: n/a Person & email address to contact for further information: David Faure <faure(a)kde.org> Intended usage: COMMON Author/Change contoller: Marc Mutz <mutz(a)kde.org> ***KChart*** To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.kde.kchart MIME media type name: application MIME subtype name: vnd.kde.kchart Required parameters: none Optional parameters: none Encoding considerations: Binary or base64 required Security considerations: As of this writing, KChart documents do not contain any active content. As such, it is believed that usage of this mimetype does not introduce security concerns other than those already inherent in ZIP archives, XML files and supported image files. It is expected that later versions of KChart feature scripting and macro recording facilities. It is, however, not intended to include active content into the KChart document itself. KChart documents include document metadata such as the name of the author, etc. However, none of this data is written automatically. The KChart user has full control over what metadata is to be included and must actively request the inclusion. As such, the use of this mimetype does not lead to hidden leaking of possibly sensitive data. Interoperability considerations: Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX tar files as archive format. It is expected that this obsolete format will die out soon after the first release of KOffice 1.2. Thus, this registration does not apply to the obsolete format. Implementations are expected to use the old application/x-kchart mime type for the obsolete format. Published specification: A KChart document consists of a series of XML streams and externally generated content which are bundled together as a ZIP archive. Any content placed in KChart can either be completely embedded in the KChart document or can be linked to using URIs. The DTDs used in KOffice can be obtained from http://www.koffice.org/DTD/. A description of the storage format is contained in the source code distribution (lib/store/SPEC). The current version can be obtained online via KDE's WebCVS interface: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC Applications which use this media type: All applications in the KDE KOffice Office Suite, esp. KChart. Additional information: Magic numbers: This is an entry that can be used with the UNIX file(1) command's magic(4) file: 0 string PK\003\004 >30 string mimetype >>38 string application/vnd.kde.kchart File extensions: CHRT Macintosh File Type Codes: n/a Person & email address to contact for further information: David Faure <faure(a)kde.org> Intended usage: COMMON Author/Change contoller: Marc Mutz <mutz(a)kde.org> ***Kivio*** To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.kde.kivio MIME media type name: application MIME subtype name: vnd.kde.kivio Required parameters: none Optional parameters: none Encoding considerations: Binary or base64 required Security considerations: As of this writing, Kivio documents do not contain any active content. As such, it is believed that usage of this mimetype does not introduce security concerns other than those already inherent in ZIP archives, XML files and supported image files. It is expected that later versions of Kivio feature scripting and macro recording facilities. It is, however, not intended to include active content into the Kivio document itself. Kivio documents include document metadata such as the name of the author, etc. However, none of this data is written automatically. The Kivio user has full control over what metadata is to be included and must actively request the inclusion. As such, the use of this mimetype does not lead to hidden leaking of possibly sensitive data. Interoperability considerations: Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX tar files as archive format. It is expected that this obsolete format will die out soon after the first release of KOffice 1.2. Thus, this registration does not apply to the obsolete format. Implementations are expected to use the old application/x-kivio mime type for the obsolete format. Published specification: A Kivio document consists of a series of XML streams and externally generated content which are bundled together as a ZIP archive. Any content placed in Kivio can either be completely embedded in the Kivio document or can be linked to using URIs. The DTDs used in KOffice can be obtained from http://www.koffice.org/DTD/. A description of the storage format is contained in the source code distribution (lib/store/SPEC). The current version can be obtained online via KDE's WebCVS interface: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC Applications which use this media type: All applications in the KDE KOffice Office Suite, esp. Kivio. Additional information: Magic numbers: This is an entry that can be used with the UNIX file(1) command's magic(4) file: 0 string PK\003\004 >30 string mimetype >>38 string application/vnd.kde.kivio File extensions: FLW Macintosh File Type Codes: n/a Person & email address to contact for further information: David Faure <faure(a)kde.org> Intended usage: COMMON Author/Change contoller: Marc Mutz <mutz(a)kde.org> ***Kontour*** To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.kde.kontour MIME media type name: application MIME subtype name: vnd.kde.kontour Required parameters: none Optional parameters: none Encoding considerations: Binary or base64 required Security considerations: As of this writing, Kontour documents do not contain any active content. As such, it is believed that usage of this mimetype does not introduce security concerns other than those already inherent in ZIP archives, XML files and supported image files. It is expected that later versions of Kontour feature scripting and macro recording facilities. It is, however, not intended to include active content into the Kontour document itself. Kontour documents include document metadata such as the name of the author, etc. However, none of this data is written automatically. The Kontour user has full control over what metadata is to be included and must actively request the inclusion. As such, the use of this mimetype does not lead to hidden leaking of possibly sensitive data. Interoperability considerations: Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX tar files as archive format. It is expected that this obsolete format will die out soon after the first release of KOffice 1.2. Thus, this registration does not apply to the obsolete format. Implementations are expected to use the old application/x-kontour mime type for the obsolete format. Published specification: A Kontour document consists of a series of XML streams and externally generated content which are bundled together as a ZIP archive. Any content placed in Kontour can either be completely embedded in the Kontour document or can be linked to using URIs. The DTDs used in KOffice can be obtained from http://www.koffice.org/DTD/. A description of the storage format is contained in the source code distribution (lib/store/SPEC). The current version can be obtained online via KDE's WebCVS interface: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC Applications which use this media type: All applications in the KDE KOffice Office Suite, esp. Kontour. Additional information: Magic numbers: This is an entry that can be used with the UNIX file(1) command's magic(4) file: 0 string PK\003\004 >30 string mimetype >>38 string application/vnd.kde.kontour File extensions: KON Macintosh File Type Codes: n/a Person & email address to contact for further information: David Faure <faure(a)kde.org> Intended usage: COMMON Author/Change contoller: Marc Mutz <mutz(a)kde.org> ***Karbon*** To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.kde.karbon MIME media type name: application MIME subtype name: vnd.kde.karbon Required parameters: none Optional parameters: none Encoding considerations: Binary or base64 required Security considerations: As of this writing, Karbon documents do not contain any active content. As such, it is believed that usage of this mimetype does not introduce security concerns other than those already inherent in ZIP archives, XML files and supported image files. It is expected that later versions of Karbon feature scripting and macro recording facilities. It is, however, not intended to include active content into the Karbon document itself. Karbon documents include document metadata such as the name of the author, etc. However, none of this data is written automatically. The Karbon user has full control over what metadata is to be included and must actively request the inclusion. As such, the use of this mimetype does not lead to hidden leaking of possibly sensitive data. Interoperability considerations: Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX tar files as archive format. It is expected that this obsolete format will die out soon after the first release of KOffice 1.2. Thus, this registration does not apply to the obsolete format. Implementations are expected to use the old application/x-karbon mime type for the obsolete format. Published specification: A Karbon document consists of a series of XML streams and externally generated content which are bundled together as a ZIP archive. Any content placed in Karbon can either be completely embedded in the Karbon document or can be linked to using URIs. The DTDs used in KOffice can be obtained from http://www.koffice.org/DTD/. A description of the storage format is contained in the source code distribution (lib/store/SPEC). The current version can be obtained online via KDE's WebCVS interface: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC Applications which use this media type: All applications in the KDE KOffice Office Suite, esp. Karbon. Additional information: Magic numbers: This is an entry that can be used with the UNIX file(1) command's magic(4) file: 0 string PK\003\004 >30 string mimetype >>38 string application/vnd.kde.karbon File extensions: KARBON Macintosh File Type Codes: n/a Person & email address to contact for further information: David Faure <faure(a)kde.org> Intended usage: COMMON Author/Change contoller: Marc Mutz <mutz(a)kde.org>

2 1

Re: application/pkix-pkipath
by David Hopwood 24 May '02

24 May '02

-----BEGIN PGP SIGNED MESSAGE----- Peter Williams wrote: > All certs must comply with PKIX, it says. There are very real > communities of TLS users who use a non-PKIX profile of certs. - From RFC 2246, section 7.4.2: # All certificate profiles, key and cryptographic formats are defined # by the IETF PKIX working group [ref. to RFC 2459]. (In context, this applies only to X.509 formats. If other formats were added they obviously wouldn't be defined by PKIX. This should be made clearer in RFC2246-bis.) Which communities of TLS users are (deliberately, rather than just as a result of bugs) using non-PKIX-conformant X.509 certs, and why? > They should not be excluded from the use of the TLS proposed extensions. > There is nothing inherent in the nature of TLS or the extended handling > that requires that PKIX-designated controls be enforced. That's true, but specifying PKIX improves interoperability. It's not a new requirement; it is just clarifying how a requirement that is already in RFC 2246 applies for this type. > TLS should continue to be able to maintain current > interoperability AND exploit some of the newer extensions > even when certificates are not the means of distributing > public keys for the asymmetric cipher suites, as per > traditional SSL design. We (the extensions spec authors) were very careful not to do anything that would preclude or create problems for other public key authentication methods than X.509 certs. I don't see any good argument for using non-PKIX X.509 certs, though. - -- David Hopwood <david.hopwood(a)zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBPO2zqjkCAxeYt5gVAQERdggAx5oxAZx9tm0NU1vjyfmjBbDShVAGyhkd 6Iw+sMVPIErBop61mE+8EC3vnM33yBD3fCQxWtE1L1a3LukxbKvlKzMZdl+GzIEk HJ93K42IC9xdw4yu32tGLFZhr3zMtM4nPCsowctQ5EirwNWQ2qGGGPHosgV3eIPV 36W3ZQWozKsayJM4+HLQLLpGMpEW221jMgYlyAGcwbyeXLZq9IaVud7Rbx4tVL5k lDnzQ1zSbwkvhCfTLehv2UHsvkLg8rhYCWsurU5lXxQR71wEBOBnNawy9mbltKCi r8ih+FGAMS4VWRA3PxGdW42A5iurW/ugC5HGFaCgDS9Q+acaE+28FQ== =aNbk -----END PGP SIGNATURE-----

1 0

Re: [ietf-tls] Re: application/pkix-pkipath
by David Hopwood 24 May '02

24 May '02

-----BEGIN PGP SIGNED MESSAGE----- "Housley, Russ" wrote: > The registration says: "... an update to [PKIX] ..." > > That update is (finally) finished. See RFC 3280. > Please reference RFC 3280 (not RFC 2459). Thanks, this will be fixed as follows: Change the [PKIX] reference to [PKIX] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile", IETF RFC 3280, April 2002. and change the sentence in the registration to just "All Certificates MUST conform to [PKIX]." - -- David Hopwood <david.hopwood(a)zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBPO2yNzkCAxeYt5gVAQEDmQf/Ug2IYX1t8P7N/o8pzKQwF+SbbjP/IMLY 96+llndPRHN3q1WPboAsCI+4zA+2LPEokN6PqivzXibKH9W+spSj1YZawu0kswoV /mmWFR4bYk0el2bn8yrjxJsYd/zrNs4eu+4ctkUPI2sEWQGRPdtzGrrFtihQ0wEZ AsuWNOrn/OIf+76J8kVOY6a4l8H3nkn3TWR4FiL9M9gDvXkdtmjvH3aO0M41fsXT YLKFTC2HmxQRaCCBkyHKdwZz51GVk3KC/rSvxzWoYfJS30rLk9ft6Inilmnbpast XcYW2EF1DLzFLtU8/MxKwTEdN5S0ZQwknAnRyRsTnBU8BrwDoiABRA== =iPEL -----END PGP SIGNATURE-----

1 0

application/pkix-pkipath
by David Hopwood 23 May '02

23 May '02

-----BEGIN PGP SIGNED MESSAGE----- The following template is from the Standards Track I-D <draft-ietf-tls-extensions-04.txt>, which has just been submitted for Last Call in the TLS WG. It's intended to be consistent with the types application/pkix-{cert,crl} from RFC 2585. (Note: Reply-To is set to the ietf-types list only.) To: ietf-types(a)iana.org Subject: Registration of MIME media type application/pkix-pkipath MIME media type name: application MIME subtype name: pkix-pkipath Required parameters: none Optional parameters: version (default value is "1") Encoding considerations: This MIME type is a DER encoding of the ASN.1 type PkiPath, defined as follows: PkiPath ::= SEQUENCE OF Certificate PkiPath is used to represent a certification path. Within the sequence, the order of certificates is such that the subject of the first certificate is the issuer of the second certificate, etc. This is identical to the definition that will be published in [X509-4th-TC1]; note that it is different from that in [X509-4th]. All Certificates MUST conform to [PKIX] (an update to [PKIX] is in preparation, and should be followed when it is published). DER (as opposed to BER) encoding MUST be used. If this type is sent over a 7-bit transport, base64 encoding SHOULD be used. Security considerations: The security considerations of [X509-4th] and [PKIX] (or any updates to them) apply, as well as those of any protocol that uses this type (e.g. TLS). Note that this type only specifies a certificate chain that can be assessed for validity according to the relying party's existing configuration of trusted CAs; it is not intended to be used to specify any change to that configuration. Interoperability considerations: No specific interoperability problems are known with this type, but for recommendations relating to X.509 certificates in general, see [PKIX]. Published specification: <draft-ietf-tls-extensions-04.txt> and [PKIX]. Applications which use this media type: TLS. It may also be used by other protocols, or for general interchange of PKIX certificate chains. Additional information: Magic number(s): DER-encoded ASN.1 can be easily recognised. Further parsing is required to distinguish from other ASN.1 types. File extension(s): .pkipath Macintosh File Type Code(s): not specified Person & email address to contact for further information: Magnus Nystrom <magnus(a)rsasecurity.com> Intended usage: COMMON Author/Change controller: Magnus Nystrom <magnus(a)rsasecurity.com> Normative References [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," IETF RFC 2119, March 1997. [PKIX] R. Housley, W. Ford, W. Polk, and D. Solo, "Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile", IETF RFC 2459, January 1999. [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001, "Information Systems - Open Systems Interconnection - The Directory: Public key and attribute certificate frameworks." [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) | ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC 9594:8:2001. - -- David Hopwood <david.hopwood(a)zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBPOrjTTkCAxeYt5gVAQHddQf5ATsJ4D4flPu6Y5JgtazAO/Fc0MxG9Iy6 XJsov+JNMmEwP66eESuSkgk44RWlk+TkHadGnsybRth9aRUumhni8GjnIO4UAn4I QghOXua2BZ8QoePEcm2i1BqlcTg7jgOHIcVXiRk3l/N3IvZviDy1a/h9B4pmYafV ZUgKhzwr7qFg63LWQyuSkOzisWpNeC778A6u95G+P0HhGdL77IEqiVz0GfWPuq2A jTmGP7kOl+WhS1pbjliGqxUNjYyw4fX/rcd5ltzhijY5LRa3jsUq+ixK8uSx4kle XXI1Aig8NLaX5Vfu2AkojMrcH2/wMFQK/JHwZY2cfs2mhdi7JBPUng== =6X2a -----END PGP SIGNATURE-----

1 0