- Ietf-types - example.com

Change to prs.sid
by Linus Walleij 09 Sep '03

09 Sep '03

I submit this chnage to an existing MIME transport type named "audio/prs.sid" to the list for review. What has changed is one line: both "PSID" and "RSID" are accepted as "magic numbers". This was important for the developers of this format. I cannot remember ever seeing someone change an existing MIME transport type before, so I guess this is a rare occasion :-) Yours, Linus Walleij ----------------------------------------------------- Name : Linus Walleij E-mail : triad(a)df.lth.se MIME media type name : audio MIME subtype name: Private Tree - prs.sid Required parameters: None Optional parameters: None Encoding considerations: A file of this type contains binary data. Binary or Base-64 encoding is preferred. Security considerations: The data is intended for interpretation by a program that understands the data on the recipient's system. When the data is executed the security of the machine can be violated. Interoperability considerations: None Published specification: The PSID file format is described on the HTML page http://www.geocities.com/SiliconValley/Lakes/5147/sidplay/docs.html#filefor… Applications which use this media type: Any that conforms to the PSID file specification. Additional information: The data is a binary memory chunk from a Commodore 64 with an attached header. The header contains metadata such as composer, year of publication etc. The binary chunk is being interpreted as CSG 6510 microprocessor instruction bytecodes attached to a Commodore 64 chipset. Magic number(s): first 4 bytes are 0x50534944 - "PSID" or 0x52534944 - "RSID" File extension(s): .sid, .psid Macintosh File Type Code(s): PSID Person & email address to contact for further information: Linus Walleij triad(a)df.lth.se Intended usage: COMMON Author/Change controller: Linus Walleij

1 0

Thank you!
by moore＠cs.utk.edu 08 Sep '03

08 Sep '03

See the attached file for details

1 0

proposed media type registration: application/mathml+xml
by Max Froumentin 21 Aug '03

21 Aug '03

Hi, Please consider the attached Internet Draft submission: "The application/mathml+xml Media Type", originating from the Math Working Group of the W3C. Cheers, Max Froumentin, W3C

1 0

Re: RDF/XML Media Type registration draft
by Graham Klyne 29 Jul '03

29 Jul '03

Aaron, Following some informal discussion in the RDFcore working group, I'm sending these as personal review comments to you, and to the MIME types review list... Concerning: [1] http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-0… Broadly, I think this looks fine, but the RDFcore working group has made a number of changes to the RDF specifications in response to last call comments since the above MIME type registration draft was issued. The following comments would, in my view, help to bring the proposed MIME type registration more closely in line with the current RDF specification status. Section 2, 3: The citation for the RDF data model is to the RDF Semantics document [2]: the definition of the abstract syntax has now been moved to the RDF Concepts [3], and I think that would now be a more helpful citation. Section 3: Would it be appropriate to cite the RDF Semantics in the interoperability considerations section? E.g. [[ RDF is intended to allow common information to be exchanged between disparate applications. A basis for building common understanding is provided by a formal semantics [2?], and applications that use RDF should do so in ways that are consistent with this. ]] Section 4: In response to last-call feedback, we decided to pull the "social context" material from Concepts. I think that it would be appropriate to also pull it from the MIME type registration; i.e. remove all of section 4. Section 5: Would it be appropriate to cite RDF Concepts here? cf: http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/#section-frag… Regards, #g -- [1] http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-0… [2] http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-mt-20030117/ (current editor's working draft) [3] http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/ (current editors' working draft) At 10:23 24/07/03 -0500, Aaron Swartz wrote: >I'm soliciting comments on the media type registration draft for >RDF/XML: > >http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml- >mediatype-02.txt >http://www.aaronsw.com/2002/draft-swartz-rdfcore-rdfxml-mediatype -02.html > >As required by section 2.3.1 of RFC 2048, I've sent it for review to >ietf-types and ietf-xml-mime. Dan Connolly says the document has >undergone sufficient W3C review because it is [referenced from the >syntax draft]. However, I'm happy to take any comments from the WG or >other W3Cers/RDFers at the same time. Do folks think sending a note to >www-rdf-interest or something would be in order? > >[ref] >http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/#section-MIME- Type > >I plan to fold in all the comments I receive and release a new version >in two weeks. (After that, I need to ask the IESG if they want to do >their own Last Call, wait for RDF to go to Recommendation, update the >draft to refer to the Recommendation, and then submit it to be >published as an RFC.) > >-- >Aaron Swartz: http://www.aaronsw.com/ ------------------- Graham Klyne <GK(a)NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

1 0

Proposed new MIME type classifications
by Dr. Brian Coomes 26 Jul '03

26 Jul '03

Phaser Scientific Software, LLC (www.phaser.com) proposes the creation of two new MIME type classifications for proprietary "document" files used by the Phaser program. The MIME types proposed are: application/vnd.phaser.gallery application/vnd.phaser.project We are attempting to comply with the procedures for MIME type registration outlined in rfc1590. If there is more to be done, please let us know. We appreciate your feedback. Best regards, Dr. Brian Coomes Department of Mathematics University of Miami Coral Gables, Florida 33124 (305) 284-6987 coomes(a)math.miami.edu

1 0

for review: RDF/XML Media Type registration draft
by Aaron Swartz 24 Jul '03

24 Jul '03

In accordance with section 2.3.1 of RFC 2048, I'd like your comments and feedback on our draft registration of a media type for the W3C's RDF/XML format. The Internet-Draft is at: http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml- mediatype-02.txt or, more permanently, http://www.aaronsw.com/2002/draft-swartz-rdfcore-rdfxml-mediatype -02.html (or .txt or .xml) RFC 2048 recommends comments "on the choice of type/subtype name, the unambiguity of the references with respect to versions and external profiling information, and a review of any interoperability or security considerations." I'll respond to feedback for two weeks and on August 8th I'll release an updated Internet-Draft folding in all the changes. Thanks, -- Aaron Swartz: http://www.aaronsw.com/ww

1 0

Request for advice: sbml+xml Media Type
by Ben Kovitz 20 Jul '03

20 Jul '03

Hi, I work on SBML (Systems Biology Markup Language) at Caltech. We are thinking of proposing a new XML MIME media type. When learning about the process for getting a new IETF-tree media type approved, I was strongly advised to consult the members of the ietf-types and ietf-xml-mime discussion lists for advice before diving in. So here I am. I'll appreciate any advice you can give me, especially any that saves us from making some stupid mistakes that the biological modeling community will regret for years to come. Please forgive me if I reveal my ignorance in some questions below. First, a little background. SBML is an XML format for representing systems of biochemical reactions. Making it a MIME media type would enable browser-based simulation tools to conveniently download, run, and edit models. Work is now beginning on a web infrastructure to make it easy for biological researchers to share models on the web, download models used in published papers, etc. Two "levels" of SBML have been defined so far. Specifications, including the XML schemas, are at: http://www.sbw-sbml.org/sbml/docs/papers/sbml-level-1-version-2/sbml-level-… http://www.sbw-sbml.org/sbml/docs/papers/sbml-level-2-version-1/sbml-level-… We are thinking that the ideal name would be either: application/sbml+xml or: model/sbml+xml Now, here are a few questions. 1. Would it be a bad idea if we used RFC3236 (The application/xhtml+xml Media Type) as a model for the document w write? I'm hoping that we don't need to explain the full semantics of SBML in the RFC, since there are already some weighty papers that do that (referenced above). At only 8 pages, RFC3236 seems like a model of simplicity and clarity that we would like to emulate. Or is it possible to get even simpler? Some of the docs I found for XML MIME media types seemed to do little more than list the name of the type and who submitted it. 2. We are thinking of including required parameters of "level" and "version". Anything to watch out for here? Is this a wrong idea? SBML has multiple levels to enable different simulation tools to interoperate at different levels of complexity and sophistication. Each level can come in different versions. More levels are planned. 3. Is it completely stupid to even consider model/sbml+xml? The other model/ media types have been for spatial models. SBML is primarily used for spatial models of reactions that occur within biological cells, and has some notions of spatial relation, but an SBML model does not necessarily have the minimum 3 orthogonal dimensions specified in RFC2077. We're wondering if SBML is still within the spirit of the model/ top-level content type, though. RFC2077 speaks of economic models, behavioral models, and so on, and seems to encourage a situation where modeling tools might work successfully on models from radically different domains. 4. Any other advice you'd care to offer? Thanks in advance for your assistance, Ben -- Ben Kovitz Systems Biology Workbench (SBW) Development Group, Caltech http://www.sbw-sbml.org bkovitz at caltech.edu

3 2

RE: XHTML, XML, fancy text, and applications
by Dan Kohn 21 Apr '03

21 Apr '03

>> As I have some programming background I think >> application/xhtml|xml would have been much better and the pipe was >> available in addition to the plus sign. For historical curiosity, I'll mention that as a co-author of RFC 3023, I was in favor of using the pipe | (e.g., application/xhtml|xml, which was used in an earlier draft), but I was convinced by my co-authors that it could be too easily confused with capital I and lowercase l in many fonts. I suspect it didn't really matter, and the delimiter is in any event now firmly established as +. - dan -- Dan Kohn <mailto:dan@dankohn.com> <http://www.dankohn.com/> <tel:+1-650-327-2600>

1 0

Please review ietf-draft of the "application/soap+xml" media type
by Yves Lafon 17 Apr '03

17 Apr '03

This email serves to instantiate the two weeks discussion period on "ietf-types(a)iana.org" of the ietf-draft describing the "application/soap+xml" media type registration. You can find the draft at http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-02.txt Thank you. -- Yves Lafon - W3C "Baroula que barouleras, au tiéu toujou t'entourneras."

1 0

XHTML, XML, fancy text, and applications
by Etan Wexler 14 Apr '03

14 Apr '03

Mikko Rantalainen wrote to <mailto:www-html@w3.org> on 9 April 2003 in "Re: XHTML2 MIME type" (<mid:3E94185F.10003@cc.jyu.fi>): > [This is getting a bit offtopic and I'm not really expecting any > replies. I'll post some thoughts to help future archive diggers.] I'm steering the discussion into the MIME media types list, <mailto:ietf-types@alvestrand.no>. Please send public replies there. > OK. This is the first time I actually viewed RFC 3023 and I want to say > that I consider "+xml" extension as an ugly hack. I consider it an elegant solution. Our difference leads me to conclude that this is at least partly a matter of taste. De gustibus non disputandum. > I'm still wondering why they choose > to use "+" as a separator if the meaning is "this file can be considered > as something OR xml". I would see it as "This resource is of such-and-such type AND it is XML in terms of syntax." > When I first time saw application/xhtml+xml I > immediatly thought that it meant it's an xhtml file with possible > additional namespaces. While I affirm the principle that MIME media type names should be as clear as is possible within the limited character repertoire and some reasonable length, we have IANA registrations and Requests For Comments that define each type. Those documents are meant for reading, not for ignoring. > As I have some programming background I think > application/xhtml|xml would have been much better and the pipe was > available in addition to the plus sign. As I know that non-programmer lay people encounter MIME media type names with some frequency on the Web (by "Web" I'm including mail systems), I have to say that the pipe character ("|", vertical line, U+007C) is too devoid of well-known semantics. In my experience in the English-speaking United States, if there is any character that commonly denotes alternatives, it is the slash ("/", solidus, U+002F). (Perhaps, in that case, I should have written slash/solidus.) The slash is reserved and will not find its way into a MIME media subtype name. > After reading the references you provided I still feel that we need a > new top level mime type. We have various file types that are basically > text but not plain text. Right, and those should be subtypes of "text" if they can reasonably be treated as "text/plain", or subtypes of "application" if they contain non-textual markup. > If the reason for not having another top level MIME type for xml/* is > that we want to specify TYPE instead of SYNTAX then the text/* shouldn't > be considered as plain text syntax either and it should be used for all > file types that mostly contain text. I think that the principle in effect is that treatment as "text/plain" has to be a reasonable fallback for any "text" subtype. What constitutes reasonable is a matter for debate. I suspect that most people could not make sense of Postscript source code (hence "application/postscript"), even though it is textual. HTML source code, on the other hand, is likely to contain passages of readable text (hence "text/html"), even if it leaves the reader wondering what all the symbols mean. > I think the application/* top level type shouldn't be used for XHTML 2 > just because one needs an application to easily read the content. My understanding is that the MIME media type name "application" describes the content itself, not the necessary processing software. It's like "This resource is an application of some sort", not like "Start an application to handle this resource". > Following the same logic we should move all of image/*, video/* and > audio/* types to application/* because you cannot view any of those > without an application either. Again, the term "application" describes the resource, not the handler. > Perhaps application/* should be renamed to misc/* or other/*? That sounds like a terrible idea, given the installed base of software that understands and expects the "application" name. -- Etan Wexler: stuffed but not satiated, damn it. <mailto:ewexler@stickdog.com>

5 5