December 2007 - Ietf-types

Request for review of Turtle (an RDF serialization) media type: text/turtle
by Eric Prud'hommeaux 17 Jan '08

17 Jan '08

W3C is about to publish a Team Submission for the RDF serialization Turtle. A mockup of the document to be published is at http://www.w3.org/2007/11/21-turtle Because the document will include the text of the media type registration, I am vetting this registration with ietf-types before publishing the document. Some discussion about the claim to force utf-8 encoding (and not require that in a charset parameter) can be seen at http://lists.w3.org/Archives/Public/www-archive/2007Dec/ (Subject: Media types for RDF languages N3 and Turtle) I got moderator-actioned for having too many folks in the Cc so I'm Bcc'ing them all in this request for review: "Sean B. Palmer" <sean(a)miscoranda.com>, Tim Berners-Lee <timbl(a)w3.org>, "Daniel W. Connolly" <connolly(a)w3.org>, Dave Beckett <dave(a)dajobe.org>, Lee Feigenbaum <lee(a)thefigtrees.net>, Garret Wilson <garret(a)globalmentor.com>, Graham Klyne <GK(a)ninebynine.org>, Dan Brickley <danbri(a)danbri.org>, Type name: text Subtype name: turtle Required parameters: None Optional parameters: None Encoding considerations: The syntax of Turtle is expressed over code points in Unicode[UNICODE]. The encoding is always UTF-8 [RFC3629]; the charset parameter is not needed; though it may be included so long as the value is 'UTF-8'. Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F] Security considerations: Turtle uses IRIs as term identifiers. Applications interpreting data expressed in Turtle sould address the security issues of Internationalized Resource Identifiers (IRIs) Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7 Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "o" may appear similar to a Latin "o"). A character followed by combining characters may have the same visual representation as another character (LATIN SMALL LETTER E followed by COMBINING ACUTE ACCENT has the same visual representation as LATIN SMALL LETTER E WITH ACUTE). Any person or application that is writing or interpreting data in Turtle must take care to use the IRI that matches the intended semantics, and avoid IRIs that make look similar. Further information about matching of similar characters can be found in Unicode Security Considerations [UNISEC] and Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8. Interoperability considerations: There are no known interoperability issues. Published specification: TBD, in the mean time, see http://www.w3.org/2007/11/21-turtle Applications which use this media type: No widely deployed applications are known to use this media type. It may be used by some web services and clients consuming their data. Additional information: Magic number(s): Turtle documents may have the strings '@prefix' or '@base' (case dependent) near the beginning of the document. File extension(s): ".ttl" Base URI: The Turtle '@base <IRIref>' term can change the current base URI for relative IRIrefs in the query language that are used sequentially later in the document. Macintosh file type code(s): "TEXT" Person & email address to contact for further information: Eric Prud'hommeaux <eric(a)w3.org> Intended usage: COMMON Restrictions on usage: None Author/Change controller: The Turtle specification is the product of David Beckett and Tim Berners-Lee. A W3C Working Group may assume maintenance of this document; W3C reserves change control over this specifications. Normative References [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3629] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [UNICODE] The Unicode Standard, Version 4. ISBN 0-321-18578-1, as updated from time to time by the publication of new versions. The latest version of Unicode and additional information on versions of the standard and of the Unicode Character Database is available at http://www.unicode.org/unicode/standard/versions/. [UNISEC] Mark Davis, Michel Suignard, "Unicode Security Considerations. http://www.unicode.org/reports/tr36/ -- -eric office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA mobile: +1.617.599.3509 (eric(a)w3.org) Feel free to forward this message to any list for any purpose other than email address distribution.

9 17

Request for review of Ogg Media Types: video/ogg, audio/ogg, application/ogg
by Ivo Emanuel Gonçalves 16 Jan '08

16 Jan '08

This is a request for review of the Ogg Media Types video/ogg, audio/ogg, and application/ogg, which are described in draft-goncalves-rfc3534bis-00 [1]. Comments are welcome. If discussion regarding those types is better suited in split messages instead of one thread, please advise if that is the case. Regards, Ivo [1] http://www.ietf.org/internet-drafts/draft-goncalves-rfc3534bis-00.txt

5 8

Re: Media types for RDF languages N3 and Turtle
by Sean B. Palmer 31 Dec '07

31 Dec '07

On Dec 17, 2007 3:22 PM, Garret Wilson <garret(a)globalmentor.com> wrote: > There exists serious concern regarding the use of a text top-level > type for N3. See the recent discussion on www-rdf-comments. Eric and I discussed that in some detail prior to and subsequent to the start of this thread. One thing that I don't understand is what you said here: [[[ I suppose that, with the popular understanding that RFC 2046 requires a default character set of US-ASCII if there is no charset parameter, then it's almost as true as if RFC 2046 said so explicitly. ]]] - http://lists.w3.org/Archives/Public/www-rdf-comments/2007OctDec/0017 It seems very clear to me that RFC 2046 states explicitly that US-ASCII is required if there is no charset parameter. Here are the relevant quotes: The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII. ... Note that the character set used, if anything other than US- ASCII, must always be explicitly specified in the Content-Type field. The way I read that, that doesn't leave any room for a text/anything specification setting its own default. As for the CRLF requirement, that CRLF and *only* CRLF be used for line breaks, Dan Brickley commented in response to that that text/xml was widely regarded troublesome; but it's not clear from his citations that CRLF has anything to do with the troublesome nature, only charset defaulting. It seems that most of the problem, as you mentioned in the www-rdf-comments thread, is that the text subtree is simply broken. RFC 2046 just wasn't written to deal with the Unicode world. Check out the following, for example: A SINGLE character set that can be used universally for representing all of the world's languages in Internet mail would be preferrable. Unfortunately, existing practice in several communities seems to point to the continued use of multiple character sets in the near future. A small number of standard character sets are, therefore, defined for Internet use in this document. And it defines US-ASCII and ISO-8859-X. It's not RFC 2046's fault that it wasn't prescient, but it's *out-of-date* now and perhaps ought to be obsoleted so that text/* can be used as intended rather than as we're currently forced? But of course there is the question of what MIME implementations will do and what problems, possibly serious, it would cause to, for example, make utf-8 the new text/* default. It would need a lot of discussion and a new RFC. Note that TimBL has never, as far as I know, suggested disregarding the charset defaulting requirement, just the CRLF requirement which he mightn't even be aware of. And as it seems that the charset defaulting is the thing that most people are anxious about, I'd be happy for text/rdf+n3; charset=utf-8 or text/n3; charset=utf-8 to go forwards, even ignoring the fact that it disregards the CRLF requirement. Thanks, -- Sean B. Palmer, http://inamidst.com/sbp/

2 4

Re: [RESEND] Media types for RDF languages N3 and Turtle
by Garret Wilson 21 Dec '07

21 Dec '07

Graham Klyne wrote: > (1) use application/(something) rather than text/(something) in *all* cases > where the content is not primarily for human consumption - i.e. if you expect to > do anything other than display as-is on a character display. I think the last part of that sentence is definitely too far---the only thing that would be displayed "as-is on a character display" is text/plain. Besides plain text, "primarily for human consumption" is one possible criterion, but is that the most useful criterion? RFC 2046 mentions, "The 'text' media type is intended for sending material which is principally textual in form." I don't know what that means exactly, but the RFC goes on to say things in this category are "to some extent readable" and that, "It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form." I don't have a strong opinion here, but I will point out that RFC 2046 talks about the category being "the highest level" division and that it is "useful". To me, it is useful at a high level to note that the content types discussed here have the following characteristics: * The content bytes are interpreted as text characters (i.e. Unicode code points); ignoring encoding, no bytes are interpreted as anything other than text characters. (These text characters may later be subject to some meta-interpretation---e.g. delimiters---but they are first interpreted as text characters.) * These content types can always be edited in a text editor. * Abstract values, such as numbers, are represented by their text lexical forms, not by some non-text encoding. To me those points are meaningful, and it might be useful to include those criteria when making a high-level distinction. Is the top-level type of RFC 2046 even useful anymore? I think the biggest criteria for me is, "can I edit this thing in a text editor?" Whether the author meant the information to be directly displayed to the user, while interesting, seems less useful from a content-processing point of view. Garret

1 1

Re: Re: [RESEND] Media types for RDF languages N3 and Turtle
by Eric Prud'hommeaux 20 Dec '07

20 Dec '07

* Graham Klyne <GK(a)ninebynine.org> [2007-12-19 16:10+0000] > I've not read the latest emergence of this thread with a fine tooth comb, but I > would suggest: > > (1) use application/(something) rather than text/(something) in *all* cases > where the content is not primarily for human consumption - i.e. if you expect to > do anything other than display as-is on a character display. By that metric, I agree that they should be application/ , but I'm not confident that said metric is consistent with the rest of the text/ mime tree. Anyone else care to back up or contradict one or both of us? > I don't think that > *any* rendering of RDF is really primarily constructed for direct human > interpretation. Oh pshaw. RDF is meant for babies and grandmothers alike; and its text formats read like a romance novel, only less racey. > (2) rather than use the +suffix for cases other than +xml, use -suffix. Or, at > least, provide a compelling example of two different media types with +foo > suffix that might fall back to being processed by a common software package > associated with that suffix. > > Thus: > application/rdf+xml > application/octet-stream (ntriples) > application/rdf-turtle > application/rdf-n3 Ahh, cool. Could you tell me what are the semantics of foo-bar? I know only octet-stream, and never considered separating the words before. > #g > -- > > Eric Prud'hommeaux wrote: > > [resent, correcting typos and thinkos] > > > > Hi all, there are a couple languages that have been used for a while, > > turtle and n3, and I am trying work out the right media types to > > register for them. > > > > > > == Cast of Characters > > ╔══════════╦══════════════════════════════╦══════════════════════╗ > > ║ name ║ role ║ current media type ║ > > ╠══════════╤══════════════════════════════╤══════════════════════╣ > > ║ RDF │ data model │ N/A ║ > > ╟──────────┼──────────────────────────────┼──────────────────────╢ > > ║ RDFXML │ XML serialization of RDF │ application/rdf+xml ║ > > ╟──────────┼──────────────────────────────┼──────────────────────╢ > > ║ ntriples │ simple serialization of RDF │ text/plain ║ > > ╟──────────┼──────────────────────────────┼──────────────────────╢ > > ║ turtle │ textual serialization of RDF │ application/x-turtle ║ > > ╟──────────┼──────────────────────────────┼──────────────────────╢ > > ║ n3 │ extension¹of turtle language │ text/rdf+n3 (not ║ > > ║ │ expressing a superset of RDF │ registered) ║ > > ╚══════════╧══════════════════════════════╧══════════════════════╝ > > > > ¹ The origins of turtle and n3 are complicated, but this is the > > most practical model for media type consideration. > > > > These languages will be published under http://www.w3.org/TR/ > > (which implies certain persistance and update policy) as soon > > as I work out what to include in the media type registration. > > In the mean time, see > > http://www.dajobe.org/2004/01/turtle/#sec-mime > > http://www.w3.org/DesignIssues/Notation3 > > > > Neither the turtle nor n3 media types are registered. I seek advice > > from the community on exactly how to register them, as I will have > > to beat out some sort of consensus in order to register them. > > > > > > == Issues > > • subsumption relationshop — n3 subsumes turtle in both data model and > > grammar. To that end, text/n3; and text/n3; profile=turtle have been > > suggested. Another suggestion has been text/rdf+n3 and > > text/rdf+turtle , in somewhat the spirit of XML (where the +xml > > indecates the that it's the XML encoding of the preceding datatype). > > > > • subtree — turtle and n3 are certainly more human-readable than > > ntriples (as they are basically extensions of ntriples, with > > namespace prefixes and abbreviations for some atoms). The default > > character encoding of us-ascii is certainly outdated, and doesn't > > make sense for any of these languages. Garret Wilson (Cc'd) raised > > the question of whether a text/ registration may force the charset > > to be, say, utf-8². Both n3 and turtle, as well as related langs > > like SPARQL, are explcitly utf-8. Can the registration include text > > like "The encoding is always UTF-8"? Would that mean that the > > media type would not need a constant charset parameter? > > > > ² http://lists.w3.org/Archives/Public/www-rdf-comments/2007OctDec/0017 > > > > > > == Strawman > > Let me propose: > > n3: text/rdf+n3 > > turtle: text/rdf+turtle > > with > > [[ > > Encoding considerations: The encoding is always UTF-8 > > ]] > > and the expectation that > > [[ > > Content-type: text/rdf+n3 > > ]] > > (or +turtle) fully specifies the media type and the > > character encoding. > > > > > > A plea to all: bear in mind that this consensus bit is a hard job, > > and that the world will be much better off if we can reach a timely > > compromise. We've suffered for five years without these media types > > so let's keep our mission reallistic. > > -- > Graham Klyne > For email: > http://www.ninebynine.org/#Contact > -- -eric office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA mobile: +1.617.599.3509 (eric(a)w3.org) Feel free to forward this message to any list for any purpose other than email address distribution.

2 1

Re: Media types for RDF languages N3 and Turtle
by Garret Wilson 17 Dec '07

17 Dec '07

There exists serious concern regarding the use of a text top-level type for N3. See the recent discussion on www-rdf-comments. Garret Eric Prud'hommeaux wrote: > Hi all, there are a couple languages that have been used for a while, > turtle and n3, and I am trying work out the right media types to > register for them. > > > == Cast of Characters > ╔══════════╦══════════════════════════════╦══════════════════════╗ > ║ name ║ role ║ current media type ║ > ╠══════════╤══════════════════════════════╤══════════════════════╣ > ║ RDF │ data model │ N/A ║ > ╟──────────┼──────────────────────────────┼──────────────────────╢ > ║ RDFXML │ XML serialization of RDF │ application/rdf+xml ║ > ╟──────────┼──────────────────────────────┼──────────────────────╢ > ║ ntriples │ simple serialization of RDF │ text/plain ║ > ╟──────────┼──────────────────────────────┼──────────────────────╢ > ║ turtle │ textual serialization of RDF │ application/x+turtle ║ > ╟──────────┼──────────────────────────────┼──────────────────────╢ > ║ n3 │ extension¹of turtle language │ text/rdf+n3 (not ║ > ║ │ expressing a superset of RDF │ registered) ║ > ╚══════════╧══════════════════════════════╧══════════════════════╝ > > ¹ The origins of turtle and n3 are complicated, but this is the > most practical model for media type consideration. > > These languages will be published under http://www.w3.org/TR/ > (which implies certain persistance and update policy) as soon > as I work out what to include in the media type registration. > In the mean time, see > http://www.dajobe.org/2004/01/turtle/#sec-mime > http://www.w3.org/DesignIssues/Notation3 > > Neither the turtle nor n3 media types are registered. I seek advice > from the community on exactly how to register them, as I will have > to beat out some sort of consensus in order to register them. > > > == Issues > • subsumption relationshop — n3 subsumes turtle in both data model and > grammar. To that end, text/n3; and text/n3; profile=turtle have been > suggested. Another suggestion has been text/rdf+n3 and > text/rdf+turtle , in somewhat the spirit of XML (where the +xml > indecates the that it's the XML encoding of the preceding datatype). > > • subtree — turtle and n3 are certainly more human-readable than > ntriples (as they are basically extensions of ntriples, with > namespace prefixes and abbreviations for some atoms). The default > character encoding of iso-8859-1 is certainly outdated, and doesn't > make sense for any of these languages. Garret Wilson (Cc'd) raised > the question of whether a text/ registration may force the charset > to be, say, utf-8². Both n3 and turtle, as well as related langs > like SPARQL, are explcitly utf-8. Can the registration include text > like "The encoding is always UTF-8"? Would that mean that the > media type would not need a constant charset parameter? > > ² http://lists.w3.org/Archives/Public/www-rdf-comments/2007OctDec/0017 > > > == Strawman > Let me propose: > n3: text/rdf+n3 > turtle: text/rdf+turtle > with > [[ > Encoding considerations: The encoding is always UTF-8 > ]] > and the expectation that > [[ > Content-type: text/rdf+n3 > ]] > (or +turtle) fully specifies the media type and the > character encoding. > > > A plea to all: bear in mind that this consensus bit is a hard job, > and that the world will be much better off if we can reach a timely > compromise. We've suffered for five years without these media types > so let's keep our mission reallistic. >

1 0

Request for review - FIXatdl xml meda type
by Rick Labs 15 Dec '07

15 Dec '07

Per a request from Amanda Baber at Internet Assigned Numbers Authority (IANA) we post here for feedback on this MIME registration request. All help is very much appreciated. There are several areas that are unclear to us at this time. (See question marks below) Thanks in advance for your assistance. Rick Labs tmp2004 at clbcm.com Name : Richard Labs Email : tmp2004 at clbcm.com MIME media type name : Application MIME subtype name : Standards Tree -FIXatdl+xml [Not quite sure we have that correct?] Required parameters : none Optional parameters : none Encoding considerations : binary [Everything we do is really just text in UTF-8 to support all modern languages. So not sure if this should be Text (particularly if that implies ASCII) or binary or ?] This media type is XML encoded with UTF-8 to support all languages including Asian, character based languages. UTF-8 encoding may require encoding on transports not capable directly supporting it. Security considerations : (1) State whether or not the media type contains active or executable content. The media type does not contain any executable code. It carries the detailed parameter values for a specific algorithmic security trade. For a basic overview see: http://en.wikipedia.org/wiki/Algorithmic_trading and particularly, the communications subsection section. For an announcement regarding the standard search the WWW for "FIXatdl" (2) State whether or not the information contained in the media type needs privacy or integrity services. Yes, the information contained in this media type requires both privacy and integrity services. It is envisioned that this media type would predominately be transfered via conventional SSL WWW protocols. The media type carries data that drive the parameters of an algorithmic trading securities order. There is however, no automatic execution of these orders without several additional steps. In a typical use-case the interaction is as follows: 1. The trader is on a SSL link to a broker's web site. Prior to interacting on that web site he was fully authenticated and logged in. 2. WWW interaction occurs and a draft security order is mutually worked up. 2. The trader directs his Order Management System to "import" this draft order by fetching and parsing the XML file. 3. During the parsing, that xml is checked against its standard schema to insure it's well formed and fully validating. 4. The Order Management System applies substantial additional security measures to the importation of this type of data. 5. The imported xml order values are displayed to the securities trader once import validation is complete. 6. Once the trader is satisfied with the order, he hits a send order button and comprehensive validation of all parts of the order can run at that time. 7. Once the order is released from OMS system, it is transmitted via direct, dedicated IP circuits, or highly encrypted VPNs, from the trader to the broker. Interoperability considerations : These media types are common xml files with UTF-8 encoding. They will support English plus all other modern languages. Published specification : http://www.fixprotocol.org/working_groups/algowg/documents Applications which use this media : These files should have universal interoperability - they are not application specific. They are designed to be used with a wide variety of Order Management Systems (OMS) in the securities trading industry. Some order management systems have a broad user base and are distributed as conventional, prepackaged software. Other Order Management Systems are entirely created and maintained in-house by a single entity. All these systems just import these xml orders and the interact with them on their own terms. Additional information : 1. Magic number(s) : none 2. File extension(s) : .FIXatdl [not sure here?] 3. Macintosh file type code : .FIXatdl? (Not sure here? XML? Text? UTF-8?) 4. Object Identifiers: none We are in the final steps of finishing the XML schema for this new standard. We would very much like to register the Mime extension and mandate that structure in our final standard. We expect to issue FIXatdl as a standard early in 2008. Person to contact for further information : 1. Name : Algorithmic Trading Working Group, FIX Protocol Ltd. 2. Email : algotech at fixprotocol.org Intended usage : Common These XML files are designed to be used with a wide variety of Order Management Systems (OMS) in the securities trading industry Author/Change controller : FIX Protocol Limited Algorithmic Trading Working Group http://www.fixprotocol.org/ -- Rick Labs CL&B Capital Management, LLC 7583 Hunt Lane Fayetteville, NY 13066-2554 315-637-0915 x11 FAX 815-642-9396

1 0

Registration review for vnd.americandynamics.acc
by Sands, Gary 14 Dec '07

14 Dec '07

American Dynamics intends to submit the following registration to IANA. As recommended by RFC4288 I submit the intended registration for a two week review period. Type name: video Subtype name: vnd.americandynamics.acc Required parameters: rate (RTP only) Optional parameters: none Encoding considerations: ACC video data is binary data and must be encoded for non-binary transport - typically BASE64. Security considerations: ACC is a binary file format that contains no active content and no textual information. Interoperability considerations: none Published specification: none Applications that use this media type: Intellex DVMS, Intellex Management Suite Additional information: Magic number(s): File extension(s): acc Macintosh file type code(s): Person & email address to contact for further information: gsands AT tycoint.com Intended usage: LIMITED USE Restrictions on usage: This type may be transmitted over RTP. Author: gsands AT tycoint.com Change controller: gsands AT tycoint.com Other information Active Content Compression (ACC) is a proprietary video compression that is optimised for CCTV applications. ACC has been deployed world-wide in security applications since 1997. A white paper on ACC is available at http://americandynamics.net/webapps/getdocument.aspx?filename=whitepaper _acc_lt_en.pdf -------------------------------------------------------- Tyco Safety Products/CEM Systems Ltd. Registered in Northern Ireland: NI 25728. Registered Office: Unit 4 Ravenhill Business Park, Ravenhill Road, Belfast, BT6 8AW.. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender immediately and delete any copies in your possession.

2 5

Request for review of DMB Application format media types: application/dmb [updated]
by Houari 14 Dec '07

14 Dec '07

MIME media type name : application MIME subtype name : dmb Required parameters : none Optional parameters : none Encoding considerations : binary This media type may require encoding on transports not capable of handling binary. Security considerations : It is not possible to inject supported components other than those are specified in the DMB AF specification (ISO/IEC 23000-9) in the dmb file. This might prevent to crash the receiver or temporarily make it unavailable. The authentication mechanism can be used to validate of the sender and the data to prevent security problems due to non-compliant malignant dmb file. Interoperability considerations : A number of interoperating implementations exist within the ISO/IEC 23000 community, and that community has reference software for reading and writing the file format. Published specification : Not published yet. However, ISO/IEC 23000-9 is currently at FDIS stage and expected to be published in Jan. 2008. Applications which use this media : Multimedia applications Additional information : 1. Magic number(s) : none 2. File extension(s) : dmb 3. Macintosh file type code : dmb Person & email address to contact for further information: Hui Yong Kim <hykim5(a)etri.re.kr <mailto:hykim5@etri.re.kr>> Intended usage : COMMON Author: Hui Yong Kim, editor of ISO/IEC 23000-9 Digital Multimedia Broadcasting Application Format Change controller: ISO/IEC JTC 1/SC 29/WG 11 (MPEG) Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

Request for review of DMB Application format media types: audio/dmb [updated]
by Houari 14 Dec '07

14 Dec '07

MIME media type name : audio MIME subtype name : dmb Required parameters : none Optional parameters : none Encoding considerations : binary This media type may require encoding on transports not capable of handling binary. Security considerations : It is not possible to inject supported components other than those are specified in the DMB AF specification (ISO/IEC 23000-9) in the dmb file. This might prevent to crash the receiver or temporarily make it unavailable. The authentication mechanism can be used to validate of the sender and the data to prevent security problems due to non-compliant malignant dmb file. Interoperability considerations : A number of interoperating implementations exist within the ISO/IEC 23000 community, and that community has reference software for reading and writing the file format. Published specification : Not published yet. However, ISO/IEC 23000-9 is currently at FDIS stage and expected to be published in Jan. 2008. Applications which use this media : Multimedia applications Additional information : 1. Magic number(s) : none 2. File extension(s) : dmb 3. Macintosh file type code : dmb Person & email address to contact for further information: Hui Yong Kim <hykim5(a)etri.re.kr <mailto:hykim5@etri.re.kr>> Intended usage : COMMON Author: Hui Yong Kim, editor of ISO/IEC 23000-9 Digital Multimedia Broadcasting Application Format Change controller: ISO/IEC JTC 1/SC 29/WG 11 (MPEG) Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0