- Ietf-types - example.com

Online Registartion at www.iana.org
by Marc Mutz 30 Apr '02

30 Apr '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Are Online Registrations from www.iana.org posted here? Marc - -- Marc Mutz <mutz(a)kde.org> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE8zta23oWD+L2/6DgRAiR5AKDg1AD0W7nqpkyvPU0o0BMx1AaWhQCgwNX/ 8LuR85Jo+15nlmvwOn03JpY= =IV9v -----END PGP SIGNATURE-----

1 0

sp midi and nokia ringtones
by jeanluc 15 Apr '02

15 Apr '02

hi, I'm a french composer, and I try to create an sp-midi file for nokia 3510 and communicator I use beatnik since 2 years and I know that a mini Beatnik Audio Engine is in some nokia phones. I'm waiting for Scalable Polyphony MIDI Specification and Device Profiles by MMa. I try to create an sp-midi file. To do that , musician must embed at the top of the midifile a "mip " code( in hexadecimal code )..This mip code allow to reduce or increase polyphony of a midifile for 4-polyphony device or 8 or16- polyphony device.... This mip code is just a sys-ex message, in hexadecimal code.The hex is in the MMA's specification. Also in the spec. are the device ID's for upcoming phones. Do you know : How can I put the correct "'MIP" code in my sp-midi file ? Have you in hexdecimal code thi mip code, with device ID's ? How can I test a sp-midi file exept on a phone and beatnik editor? can I test a file on a desktop nkia 3510 phone emulator? thanks, my website: www.kitmusica.com (flashsound api and beatnik) try our beatnik mixer www.kitmusica.com/introbeat.htm (beatnik) a sonified web site www.helentraiteur.com, by kitmusica (beatnik) a sonified gypsy web site http://jeanluc.borla.free.fr/chico4/chico.htm (flashsound api)

1 0

Fwd: I-D ACTION:draft-swartz-rdfcore-rdfxml-mediatype-00.txt
by Graham Klyne 09 Apr '02

09 Apr '02

All, The following was recently published as a work item of the W3C RDFcore working group. It is our hope that when the specification documents are stabilized as W3C recommendations (hopefully, quite soon) we can move this forward promptly for RFC publication. If there's anything here likely to be problematic, we'd appreciate knowing sooner rather than later. #g -- >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : application/rdf+xml Media Type Registration > Author(s) : A. Swartz > Filename : draft-swartz-rdfcore-rdfxml-mediatype-00.txt > Pages : > Date : 05-Apr-02 > >This document describes a media type (application/rdf+xml) for use >with the XML serialization of the Resource Description Framework >(RDF). RDF is a language designed to support the Semantic Web, by >facilitating resource description and data exchange on the Web. RDF >provides common structures that can be used for interoperable data >exchange and follows the World Wide Web Consortium (W3C) design >principles of interoperability, evolution, and decentralization. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-0… > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-swartz-rdfcore-rdfxml-mediatype-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv(a)ietf.org. >In the body type: > "FILE /internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20020405150842.I-D(a)ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-00.txt > ><ftp://ftp.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-00…> ------------------- Graham Klyne <GK(a)NineByNine.org>

1 0

Re: please review: application/smil MIME type registration
by Philipp Hoschka 05 Apr '02

05 Apr '02

Anders, I am picking this up again - sorry for the long delay. The optional parameter that you requested has been added to the latest draft - see http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-09.txt -Philipp "Anders Nohlgren (EPL)" wrote: > > Philipp, > couldn't there be an optional parameter to the SMIL MIME type (indicating e.g. profile) that could be used for content-negotiation purposes? I fully understand your arguments that such a parameter is not absolutely necessary, but in some cases it would be a useful feature. If you want to deliver an optimised SMIL file to the client you should be able to indicate the supported profile. The last sentence of clause 14.4.4 in the SMIL 2.0 recommendation (http://www.w3.org/TR/smil20/smil-basic.html#smilBasicNS-GuidePlayer) talks about processing the test attributes already on the server side. When doing so it would help to know the SMIL profile that the client supports. Providing this with the MIME type would be efficient I think. > > Best regards, > Anders > > > -----Original Message----- > > From: Philipp Hoschka [mailto:ph@w3.org] > > Sent: 22 June 2001 19:45 > > To: Peter Stark (ECS) > > Cc: ietf-types(a)iana.org; www-smil(a)w3.org > > Subject: Re: please review: application/smil MIME type registration > > > > > > Peter, > > > > I presume your use case is that a client should be able to > > request a SMIL-basic document via content-negotiation ? > > This is not the way SMIL basic works. > > > > All SMIL 2.0 documents are also SMIL basic documents > > http://www.w3.org/TR/smil20/smil-basic.html#BaseGuideNS-BasicDoc > > > > However, SMIL basic user agents interpret only a well-defined > > subset of the markup that may occur in a SMIL 2.0 docucment (see > > clause 5. and 7. at > > http://www.w3.org/TR/smil20/smil-basic.html#BaseGuideNS-BasicUserAgent > > > > To avoid an unsatisfactory user experience, an author can > > 1) only use markup defined for SMIL basic > > http://www.w3.org/TR/smil20/smil-basic.html#smilBasicNS-Basic > > 2) write a "scalable document" that adapts gracefully depending > > on whether it is played on a SMIL 2.0 or a SMIL basic user > > agent: > > http://www.w3.org/TR/smil20/smil-basic.html#smilBasicNS-GuideDoc > > > > The same approach can be applied to any profile, not just SMIL > > basic, and there is thus no need to use the MIME type to distinguish > > between profiles. > > > > -Philipp > > > > "Peter Stark (ECS)" a écrit : > > > > > > How does can it be used to distinguish between full SMIL > > 2.0 and a profile such as SMIL Basic? > > > > > > PS > > > > > > > -----Original Message----- > > > > From: Philipp Hoschka [mailto:ph@w3.org] > > > > Sent: den 21 juni 2001 18:03 > > > > To: ietf-types(a)iana.org > > > > Cc: www-smil(a)w3.org > > > > Subject: please review: application/smil MIME type registration > > > > > > > > > > > > We'd like to start the two-week review of > > > > > > > > http://search.ietf.org/internet-drafts/draft-hoschka-smil-medi > > > > a-type-08.txt > > > > > > > > describing the registration of the application/smil MIME type for > > > > SMIL 1.0 and SMIL 2.0. > > > > > > > > -Philipp Hoschka, W3C > > > > > >

2 1

RE: WAP Mime types
by Pieter Kasselman 04 Mar '02

04 Mar '02

Hi, apologies for any inconvenience caused. I include the three mime type definitions as text in the main body of the mail. Pieter -------------------------application/vnd.wap.cert-response------------------ ---------- From: pkasselman(a)baltimore.com To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.wap.cert-response MIME media type name: application MIME subtype name: vnd.wap.cert-response Required parameters: None Optional parameters: None Encoding considerations: The encoding follows the WTLS encoding rules as specified in [WTLS]. The content takes the form of a CertResponse structure. This structure is defined in [WPKI]. Security considerations: This MIME type is used to install new client certificates on a WAP client device. The structure allows for a X509 certificate, certificate URL or a referral URL to be returned. Interpreting the MIME type requires the certificate storage medium to be accessed and modified. If this medium is accessed or updated incorrectly existing certificate information may be corrupted. If an incorrect certificate URL is returned, this may be used as part of a denial of service attack on a server at a later stage. Likewise the referral URL may be used to launch a co-ordinated denial of service attack on a server. Interoperability considerations: The WAP Forum Ltd. Interoperability Working Group (WIG) assesses interoperability for all WAP Forum Ltd. specifications. See [WAP]. Published specification: This media type is specified in the WPKI specification that can be found at http://www.wapforum.org/what/technical.htm The encoding rules and signature generation are defined in the WTLS specification that can be found at http://www.wapforum.org/what/technical.htm Applications which use this media type: Any application that conforms with the [WPKI] specification. Additional information: Magic number(s): None File extension(s): None Macintosh File Type Code(s): None Person & email address to contact for further information: Pieter Kasselman Baltimore Technologies pkasselman(a)baltimore.com Intended usage: COMMON Author/Change controller: The WAP Forum Ltd. References [WPKI] Wireless Public Key Infrastructure Definition - WAP- 217-WPKI [WTLS] Wireless Transport Layer Security Specification - WAP- 261-WTLS -------------------------application/vnd.wap.hashed-certificate------------- --------------- From: sjosefsson(a)rsasecurity.com To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.wap.hashed-certificate MIME media type name: application MIME subtype name: vnd.wap.hashed-certificate Required parameters: None Optional parameters: None Encoding considerations: The encoding follows the WTLS encoding rules as specified in [WTLS]. The content takes the form of a TBHTrustedCAInfo structure. This structure is defined in [WPKI], reproduced below for informational purposes. The structure is binary data, and must be encoded for non-binary transport; in 7-bit environments the Base64 encoding is suitable. struct { CharacterSet character_set; opaque displayName <1..2^8-1>; } CertDisplayName; enum { sha1 (0), 255 } HashAlgorithm ; struct { uint8 version; CertDisplayName displayName; Certificate trustedCACert; opaque cainfo_url <0..2^8-1>; HashAlgorithm hash_alg; } TBHTrustedCAInfo; Users must enter exactly 80 "effective" bits of hash, which extracted from the display form and are the leftmost 80 bits of the SHA-1 hash of the CA information. Let "hash" be the SHA-1 hash of the encoding of (the encoding of) a TBHTrustedCAInfo structure. This consists of 160 bits (h0,..h159), in network byte order, h0 being the leftmost bit). The display form of the hash consists of 30 decimal digits, constructed of 5 blocks of 6 digits. The leftmost 5 digits of each block represent 16 bits of the effective hash, (i.e. can take the value '00000' to '65535' decimal), the sixth digit of each block is a check digit for the block. Block zero consists of h0 to h15 (with h0 being the most significant bit), followed by the associated check digit; block one consists of h16 to h31; followed by the associated check digit etc. That is if h0 is '1'B and h1 to h15 are all '0'B, then the sixteen bits have the value '8000'H or '32678' decimal, and the check digit is '5' decimal (see below for the check digit calculation method). The check digit is calculated using the same mechanism as used for credit card numbers, that is, the LUHN formula (mod 10) as described below. The following steps are required to validate a 6 digit group: Step 1: Double the value of alternate digits of the number beginning with the second digit from the right (the first right--hand digit is the check digit.) Step 2: Add the individual digits comprising the products obtained in Step 1 to each of the unaffected digits in the original number. Step 3: The total obtained in Step 2 must be a number ending in zero (30, 40, 50, etc.) for the number to be validated. Example 1: to validate the group 398719, corresponding to '9BBF'H as the sixteen bits of hash: Step 1: 3 9 8 7 1 9 x2 x2 x2 ------------ 6 16 2 Step 2: (6) + 9 +(1+6) + 7 + (2) + 9 Step 3: Sum is 40 = 0 (mod 10): group is validated Example 2: to validate the group 326785, corresponding to '8000'H as the sixteen bits of hash: Step 1: 3 2 6 7 8 5 x2 x2 x2 ------------ 6 12 16 Step 2: (6) + 2 +(1+2) + 7 + (1+6) + 5 Step 3: Sum is 30 = 0 (mod 10): group is validated Security considerations: This MIME type is used to install new CA certificates on a WAP client device. The TBHTrustedCAInfo structure contains the new CA certificate, without protection. Due to the sensitive nature of CA certificates the client uses a checksum value entered by the user, received "out of band" of the CA certificate delivery response (e.g. via paper mail), to guarantee the integrity of the CA certificate. The client must calculate the checksum of the received TBHTrustedCAInfo structure and verify it against the manually entered checksum value. Interoperability considerations: The WAP Forum Ltd. Interoperability Working Group (WIG) assesses interoperability for all WAP Forum Ltd. specifications. See [WAP]. Published specification: This media type is specified in the WPKI specification that can be found at http://www.wapforum.org/what/technical.htm The encoding rules and signature generation are defined in the WTLS specification that can be found at http://www.wapforum.org/what/technical.htm Applications which use this media type: Any application that conforms with the [WPKI] specification. Additional information: Magic number(s): None File extension(s): None Macintosh File Type Code(s): None Person & email address to contact for further information: Simon Josefsson RSA Security sjosefsson(a)rsasecurity.com Intended usage: COMMON Author/Change controller: The WAP Forum Ltd. References: [WPKI] Wireless Public Key Infrastructure Definition - WAP-217-WPKI [WTLS] Wireless Transport Layer Security Specification - WAP-261-WTLS [WAP] WAP Forum Certification Program and Policy - http://www.wapforum.org/cert/go-cert.html -------------------------vnd.wap.signed-certificate------------------------- --- From: pkasselman(a)baltimore.com To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.wap.signed-certificate MIME media type name: application MIME subtype name: vnd.wap.signed-certificate Required parameters: None Optional parameters: None Encoding considerations: The encoding follows the WTLS encoding rules as specified in [WTLS]. The content takes the form of a SignedTrustedCAInfo structure. This structure is defined in [WPKI]. Security considerations: This MIME type is used to install new CA certificates on a WAP client device. The SignedTrustedCAInfo structure contains both the new CA certificate and the certificate of the signer that introduces the new CA certificate. The structure is signed as specified in [WPKI] and [WTLS]. Due to the sensitive nature of CA certificates the client device must be able to trust the signer of this structure before the contained certificate is used. The client must verify the signature contained in the SignedTrustedCAInfo structure, verify the certificate of the signer as well as the signature on the new self-signed CA certificate. If the signer CA is independent of the newly introduced CA there may be implications for the certification policies of the two CAs. Interoperability considerations: The WAP Forum Ltd. Interoperability Working Group (WIG) assesses interoperability for all WAP Forum Ltd. specifications. See [WAP]. Published specification: This media type is specified in the WPKI specification that can be found at http://www.wapforum.org/what/technical.htm The encoding rules and signature generation are defined in the WTLS specification that can be found at http://www.wapforum.org/what/technical.htm Applications which use this media type: Additional information: Magic number(s): None File extension(s): None Macintosh File Type Code(s): None Person & email address to contact for further information: Pieter Kasselman Baltimore Technologies pkasselman(a)baltimore.com Intended usage: COMMON Author/Change controller: The WAP Forum Ltd. References: [WPKI] Wireless Public Key Infrastructure Definition - WAP- 217-WPKI [WTLS] Wireless Transport Layer Security Specification - WAP- 261-WTLS > -----Original Message----- > From: Keith Moore [SMTP:moore@cs.utk.edu] > Sent: 04 March 2002 14:43 > To: Pieter Kasselman > Cc: 'ietf-types(a)iana.org' > Subject: Re: WAP Mime types > > I can't read the proposed type registrations because they are mislabeled > as application/octet-stream. Perhaps you could repost them with proper > labelling? > > Keith ----------------------------------------------------------------------------- Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. http://www.baltimore.com

1 0

WAP Mime types
by Pieter Kasselman 04 Mar '02

04 Mar '02

Hi, the WAP Forum Security Group would like to submit the following MIME-types for registration in the vendor tree. In accordance with recommendations in RFC 2048 the mime types are submitted for a two week community review before submission to IANA. The mime types are: vnd.wap.hashed-certificate - Used for installing a new CA certificate on a mobile device. vnd.wap.signed-certificate - An alternative for installing a new CA certificate on a mobile device. vnd.wap.cert-response - Installing user certificates on a mobile device. <<vnd.wap.hashed-certificate>> <<vnd.wap.signed-certificate>> <<vnd.wap.cert-response>> Pieter ----------------------------------------------------------------------------- Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. http://www.baltimore.com

2 1

Registration of MIME media type audio/sp-midi
by matti.s.hamalainen＠nokia.com 15 Feb '02

15 Feb '02

<<draft-hamalainen-sp-midi-mimetype-00.txt>>

1 0

Modified registration of APPLICATION/IP
by Donald E. Eastlake 3rd 29 Jan '02

29 Jan '02

Based on Last Call comments received, I have just posted a new version of draft-eastlake-ip-mime. Here is the revised MIME type registration... MIME media type name: APPLICATION MIME subtype name: IP Required parameters: version version=n This parameter exposes the IP Version number [RFC 791] in the MIME Content-Type. Optional parameters: dilation, address dilation=nnn Typically IP packets will be MIME labeled for transmission over email or other application level protocols. Such transmission is normally slower than lower level network protocols. While this is not much of a concern if a packet is just being communicated for analysis, if such transmission is used to establish connectivity, the sender of a datagram may wish to advise the recipient of the estimated time dilation factor. For example, if datagrams typically take around a second and occasionally up to ten seconds end-to-end but it is more like a minute and occasionally up to ten minutes if they are MIME encoded in email, a "dilation=60" parameter would be reasonable. Note: Although IP and TCP are defined as timing independent protocols, many implementations actually have timeouts built in. In some cases, an effective technique to defeat these timeouts is to repeatedly resend the last packet received. This is, if a MIME encoded TCP packet is being sent from Host A to Host B in the figure above where the applications are gatewaying the packets to the real IP stack, repeated transmission of this packet by the application on Host B to the stack may stave off timeouts. Similarly, the repeated transmission to the real IP stack on Host A of the last reply TCP packet may stave off timeouts there. address=xxx Full, if slow, IP connectivity via an application level protocol such as SMTP [RFC 2821, 2822] might require that routing, tunneling, and/or interface entries be installed at each end. Routing entries would be best created or updated by routing protocol messages and the establishment of tunnels is beyond the scope of this MIME type. However, the address= parameter enables the sender to optionally indicate an IP address for itself. This may only be useful in cases where the sender knows an address that is available for itself in the recipient's addressing environment. It can be viewed as a replacement for ARP [RFC 826] on the possible path to the source of the APPLICATION/IP object via the same application level protocol. (A receiver of such an APPLICATION/IP object with an address= parameter might reasonably require that it be authenticated as meeting their policy as to from whom they would accept such information. For example, they could ignore address= parameters unless the APPLICATION/IP object was wrapped in an acceptable MULTIPART/SIGNED [RFC 1847] authentication, although that implies some trust relationship between the parties.) Examples: address="10.100.1.10" address="1080:0:0:0:8:800:200C:4171" Encoding considerations: Because of the binary nature of the body, BASE64 transfer encoding should normally be used. Security considerations: Care should be taken under any circumstance where APPLCIATION/IP content can be treated as a "live" packet. MULTIPART/ENCRYPTED and MULTIPART/SIGNED [RFC 1847] may be used to further disguise and/or authenticate MIME packaged IP traffic. Interoperability considerations: See [draft-eastlake-ip-mime-*.txt]. MULTIPART/MIXED [RFC 2046] may be used to package multiple IP datagrams together. Published specification: See [draft-eastlake-ip-mime-*.txt]. Applications which use this media type: Not yet in use. See also [RFC 3093]. Additional information: (none) Person & email address to contact for further information: Donald E. Eastlake 3rd, dee3(a)torque.pothole.com Intended usage: LIMITED USE Author/Change controller: IETF D. Eastlake 3rd [Page 8] ------- End of Forwarded Message

2 1

Registration of MIME media type application/vnd.broadshow.streampoint.producer+xml
by Lee Atkinson 18 Dec '01

18 Dec '01

MIME media type name: Application MIME subtype name: vnd.broadshow.streampoint.producer+xml Required parameters: none (Version number is stored within file) Optional parameters: none Encoding considerations: file format follows XML conventions Security considerations: files are transmitted via secure channels (either SSL or VPN) only. Does not contain any personal or sensitive data. Interoperability considerations: Published specification: The specifications for this content-type are proprietary. They are specified by Broadshow Ltd. The registration of this content-type is intended only to provide a convention for labelling this proprietary data type within the MIME/HTTP environment and does not specify any details about the content format or semantics, except to refer to the software and specifications provided by Broadshow Ltd. Applications which use this media type: Broadshow Streampoint Producer Additional information: Magic number(s): File extension(s): .bsproducer Macintosh File Type Code(s): Person & email address to contact for further information: Lee Atkinson, lee.atkinson(a)broadshow.com Intended usage: LIMITED USE Author/Change controller: Lee Atkinson, lee.atkinson(a)broadshow.com

2 1

Registration of MIME media type application/vnd.broadshow.streampoint.producer
by Lee Atkinson 18 Dec '01

18 Dec '01

MIME media type name: Application MIME subtype name: vnd.broadshow.streampoint.producer Required parameters: none (Version number is stored within file) Optional parameters: none Encoding considerations: file format follows XML conventions Security considerations: files are transmitted via secure channels (either SSL or VPN) Interoperability considerations: Published specification: The specifications for this content-type are proprietary. They are specified by Broadshow Ltd. The registration of this content-type is intended only to provide a convention for labeling this proprietary data type within the MIME/HTTP environment and does not specify any details about the content format or semantics, except to refer to the software and specifications provided by Broadshow Ltd. Applications which use this media type: Broadshow Streampoint Producer Additional information: Magic number(s): File extension(s): .bsproducer Macintosh File Type Code(s): Person & email address to contact for further information: Lee Atkinson, lee.atkinson(a)broadshow.com Intended usage: LIMITED USE Author/Change controller: Lee Atkinson, lee.atkinson(a)broadshow.com

3 2