- Ietf-types - example.com

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

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

14 Dec '07

Dear all The following is the updated request. The other updated requests is in another e-mail. Regarding the different types of application for the same extensions, there exist a field in ISO/IEC 23000-9 file for identifying video/dmb resources. It is called 'major_brand' in the specification. Actually, 15 brands are defined in the specification; 8 audio brands (which correspond to 'audio/dmb'), 6 video brands (which correspond to 'video/dmb'), and 1 all-in-one brand (which correspond to 'application/dmb'). Different brands for a MIME type exist basically for regional or operators’ different choice for audio codec. The registered Macintosh file type is "dmb " ("d", "m" and "b" followed by space) MIME media type name : video 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) Regards, - Houari Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

review of audio media types for evrc-wb
by Even, Roni 10 Dec '07

10 Dec '07

Hi, The AVT working group requests media type review for the audio/EVRCWB, audio/EVRCWB0, audio/EVRCWB1, audio/EVRCB, audio/EVRCB0 media types defined in section 9.1 of http://tools.ietf.org/html/draft-ietf-avt-rtp-evrc-wb-09 . Version 02 of this draft went through type review in June. There were comments in the IESG Evaluation that required changes in the media type registration, hence the request for the review. This draft is currently in AVT working group last call. We would be grateful if any comments could be made by 23 December 2007. Thanks, Roni Even (AVT co-chair)

1 0

(no subject)
by Even, Roni 10 Dec '07

10 Dec '07

Hi, The AVT working group requests media type review for the audio/EVRCWB, audio/EVRCWB0, audio/EVRCWB1, audio/EVRCB, audio/EVRCB0 media types defined in section 9.1 of http://tools.ietf.org/html/draft-ietf-avt-rtp-evrc-wb-09 . Version 02 of this draft went through type review in June. There were comments in the IESG Evaluation that required changes in the media type registration, hence the request for the review. This draft is currently in AVT working group last call. We would be grateful if any comments could be made by 23 December 2007. Thanks, Roni Even (AVT co-chair)

1 0

Registration of media type application/cea-2018+xml
by Gottfried Zimmermann 10 Dec '07

10 Dec '07

Type name: application Subtype name: cea-2018+xml Required parameters: none Optional parameters: none Note that (in contrast to application/xml) no charset parameter is defined since CEA-2018 specifies UTF-8 as the required file format. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023. Security considerations: All of the security considerations described in RFC 3023. Interoperability considerations: Same as interoperability considerations of text/xml as specified in RFC 3023. Published specification: CEA-2018 Applications that use this media type: Task-based applications, i.e. programs that interpret task model descriptions according to the semantics defined in CEA-2018. Additional information: Magic number(s): Same as magic number(s) of text/xml as specified in RFC 3023. File extension(s): .xml Macintosh file type code(s): "TEXT" Person & email address to contact for further information: Gottfried Zimmermann <gzimmermann(a)acm.org> Intended usage: COMMON Restrictions on usage: none Author: CEA-2018 is a standard by the Consumer Electronics Association (CEA), and was edited by: Gottfried Zimmermann <gzimmermann(a)acm.org> Change controller: CEA R7 and its working group 12 have change control over CEA-2018. ___________________________________________________ Dr. Gottfried Zimmermann ICT Accessibility Architect Access Technologies Group, Germany Phone +49 7121 790806 ___________________________________________________

1 0