- Ietf-types - alvestrand.no

Re: [cellml-discussion] Review solicited for application/cellml+xml
by Matt Halstead 10 May '06

10 May '06

There is nothing stopping anyone from storing the file with any extension, so my vote is ideally to have no extension at all since all we are doing is serving these files across a system that supports mime-types. I would prefer mounting a webdav folder than a local folder so that mime-type is available. People should be free to call it what they want. If they have more advanced file systems then various metadata frameworks can be employed automatically to determine file types and application installers can add their signatures to these local systems. A useful summary of some concepts is here : http://en.wikipedia.org/ wiki/File_type Lets just drop file extension altogether. They look ugly in RDF metadata URIs anyway :-) cheers Matt On 10/05/2006, at 5:55 PM, Alan Garny wrote: > Dear all, > > Please find my 2 cents worth of comments regarding Andrew's > Internet draft. > >> We have several reasons for not encouraging anything other >> than .xml as the file >> extension: >> 1) We have used .cml (which conflicted with other markup >> languages, like Chemical Markup Language) in the past, and >> changed to .xml. Having a history of too many file extensions >> makes it hard to encourage software vendors to stick with a >> particular one. > > Just for accuracy, I believe to be the one who started using .cml > in my > software (http://cor.physiol.ox.ac.uk/) Are there others who do so > too now? > > You mention that .cml conflicts with other markup languages, but I > would > argue that .xml conflicts with even more markup languages. > Personally, .cml > is not used on my system by anything else but for CellML files, so > I don't > have that conflict you mention, while it wouldn't be the case if my > CellML > files were to have the .xml extension. > > As for a history of file extensions, again, as far I can recall > (please > correct me if I am wrong), .xml has been the extension chosen for > CellML > files from day one. It's just me who has been some kind of a > dissident for > going for .cml from day one too (more on the reasons below). > >> 2) There is currently repository software which uses .xml, >> and changing this will likely create problems for (some) >> client software using the repositories. > > You will always have problems of some sort or another. To go from > CellML 1.0 > to 1.1 is not a trivial thing either, be it for the software > developer or > modeller. To change the file extension from .xml to whatever surely > is a > very trivial problem, at least of the kind that I would be glad to > deal with > on a daily basis, if they were to be the only problems I had to have! > >> 3) Many users of CellML like to edit their models as XML in a >> text editor. Using the XML extension allows this to work on >> systems which know nothing about CellML. > > Many CellML users like to edit their models as XML in a text > editor? Is that > really true? I certainly don't want to start an argument here, but > I somehow > think that my users would feel very strongly about having to modify > CellML > files using a simple text editor. I am, personally, very glad that > I don't > have to use a text editor, nothing worse than modifying a CellML > file than > using such an editor (very much error prone!). Allow me another > quick plug > in: have a look at COR and you might change your mind and never use > a text > editor in the future (though you might still want to do that once > in a while > for whatever reason). > > Also, it is very simple, on any operating system, to associate a > particular > extension to a particular problem. > >> 4) Using a specific extension encourages software vendors to >> rely on this file extension. Although all software developed >> at the Bioengineering Institute does not rely on a specific >> file extension, there is software developed elsewhere that >> will not open files which do not have a .cml file extension >> (even when the user specifically tries to open that file in >> the program), and I have heard that this is creating problems >> for users. > > I believe that it would have to be my software indeed... I have had > several > email exchanges with David Nickerson about this over the last few > years. In > a nutshell, the main reason I am rather reluctant about the idea of > using > .xml for CellML files is that by having using .cml, I can associate > that > extension to COR, while the same cannot really be done with .xml. > > My point is that COR has been designed from the beginning to be as > user > friendly as possible. It is something that is very high on our > agenda and > that has surely been very much appreciated by our users (from what I > know/understand, there is no way they would use a text editor to > edit CellML > files for instance). > > To make COR user friendly involved associating .cml files to COR, > because > all the users have to do to open a CellML file is, for instance, to > double > click on it rather than opening a program, then opening a CellML > file. It > may not be too much to do the latter, but why not make the user's life > easier if all that takes is associate an extension to a particular > program? > >> By having only a more generic file extension, we >> encourage software developers not to use the file extension >> to determine whether they should open a certain file, and >> instead look at the MIME type (where available) and/or the >> XML namespace. > > Yes, that could easily be done, but... :) > > Best regards, Alan. > > -- > University of Oxford, Department of Physiology, Anatomy and Genetics > Sherrington Building, Parks Road, Oxford, OX1 3PT, England > http://noble.physiol.ox.ac.uk/people/agarny/ > > _______________________________________________ > cellml-discussion mailing list > cellml-discussion(a)cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion

2 2

Review solicited for application/cellml+xml
by Andrew Miller 10 May '06

10 May '06

Dear all, I have submitted a new Internet draft, http://www.ietf.org/internet-drafts/draft-miller-media-type-cellml-02.txt, for the CellML family of formats. Following comments on the ietf-types and cellml-discussion mailing lists regarding draft-miller-media-type-cellml-01, the new draft has gone back to having a single MIME type for all versions of CellML. Instead of referencing individual versions of the specification, the new draft references a new CellML standard called the CellML Umbrella Specification. This specification contains the lowest common denominator of CellML that will remain unchanged, and estabilishes a repository listing all versions of CellML at a given time. If there are no objections to the new draft, it will be submitted to the IESG for approval on the 23 May, 2006. Please note: cellml-discussion is an open list, but it does not accept posts from non-subscribers. ietf-types subscribers may just send to the ietf-types list, and I will forward it on to cellml-discussion. Best regards, Andrew Miller ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

3 4

Request for IESG approval of audio/sp-midi and audio/mobile-xmf mediatypes
by timo.kosonen＠nokia.com 03 May '06

03 May '06

Below you can find new versions of internet-drafts for audio/sp-midi and audio/mobile-xmf mediatypes. SP-MIDI and Mobile XMF are standards of MIDI Manufacturers Association (www.midi.org) http://www.ietf.org/internet-drafts/draft-kosonen-sp-midi-mediatype-01.t xt http://www.ietf.org/internet-drafts/draft-kosonen-mobile-xmf-mediatype-0 1.txt The changes are non-technical as follows: -Dates and years have been updated -Change controller corrected to be "MIDI Manufacturers Association" -No other changes A request for review for the first versions of the above mediatypes was posted on ietf-types@alvestrand.no/ietf-types@iana.org on 11 Nov 2005. Further, last call for comments was posted on 16 Feb 2006. There have been no opposing comments or emails. I am requesting for IESG approval of the above audio/sp-midi and audio/mobile-xmf mediatypes with SDO status. Please, consider them in your next board meeting. Best Regards, Timo Kosonen Nokia Research Center Visiokatu 1, 33720 Tampere, Finland P.O. Box 100, 33721 Tampere, Finland Phone: +358 50 483 5206

1 0

Re: Request for review of Media Type Registration of RTP Payload Formats
by Colin Perkins 02 May '06

02 May '06

On 2 May 2006, at 19:30, Chris Lilley wrote: > On Monday, May 1, 2006, 7:01:33 PM, Colin wrote: > > CP> The AVT working group requests media types review of draft-ietf- > avt- > CP> rfc3555bis-04.txt and > CP> draft-ietf-avt-rfc3555bis-part2-00.txt. Both drafts are > currently in > CP> working group last call. We would be grateful if any comments > could > CP> be made by 15th May 2006. > > Clarifying question- all of the formats listed below are only for > use over RTP and do not make sense over non-streaming protocols? The majority are currently only defined for use with RTP; the exception is audio/L16. See the Restrictions on usage section of each registration template for details. Colin

1 0

Request for review of Media Type Registration of RTP Payload Formats
by Colin Perkins 02 May '06

02 May '06

The AVT working group requests media types review of draft-ietf-avt- rfc3555bis-04.txt and draft-ietf-avt-rfc3555bis-part2-00.txt. Both drafts are currently in working group last call. We would be grateful if any comments could be made by 15th May 2006. The first document (draft-ietf-avt-rfc3555bis-04.txt) specifies a procedure to register RTP payload formats as audio, video or other media subtype names. The procedure updates RFC 3555 to codify existing registration practices, in line with RFC 4288. The second document (draft-ietf-avt-rfc3555bis-part2-00.txt) updates the registrations for the following media types to match the templates from RFC 4288 and draft-ietf-avt-rfc3555bis-04.txt: audio/DVI4 audio/G722 audio/G723 audio/G726-16 audio/G726-24 audio/G726-32 audio/G726-40 audio/G728 audio/G729 audio/G729D audio/G729E audio/GSM audio/GSM-EFR audio/L8 audio/L16 audio/LPC audio/PCMA audio/PCMU audio/VDVI video/nv There are no technical changes to those media types, just an updating of the boilerplate and registration templates to current standards. Colin Perkins (AVT co-chair)

2 1

Request for review of audio/g729ev media type
by Colin Perkins 01 May '06

01 May '06

The AVT working group requests media type review for the audio/g729ev media type defined in section 6.1 of draft-ietf-avt-rtp-g729-scal-wb- ext-04.txt. This draft is currently in working group last call. We would be grateful if any comments could be made by 15th May 2006. Thanks, Colin Perkins (AVT co-chair)

1 0

Request for review of audio/evrc media types
by Colin Perkins 01 May '06

01 May '06

The AVT working group requests media type review for the audio/evrc, audio/evrc0, audio/evrc1, audio/evrcb, audio/evrcb0, and audio/evrcb1 media types defined in section 6 of draft-ietf-avt-compact-bundled- evrc-04.txt. This draft is currently in working group last call. We would be grateful if any comments could be made by 15th May 2006. Thanks, Colin Perkins (AVT co-chair)

1 0

Community Review & IESG Approval of Media Type for OEBPS package standard
by Nick Bogaty 01 May '06

01 May '06

To whom it may concern, As per the instructions for registering MIME types in the Standards tree with the IETG/IANA ( <ftp://ftp.rfc-editor.org/in-notes/rfc4288.txt> ftp://ftp.rfc-editor.org/in-notes/rfc4288.txt) I am submitting the following potential media type registration for preliminary community review with the aim of IESG approval before submission to the IANA. I am the Executive Director of a small standards organization devoted to digital texts and electronic books called the International Digital Publishing Forum (www.idpf.org) We created and maintain a standard widely used by the publishing industry to create electronic books called the Open eBook Publication Structure (OEBPS). That specification can be found at http://www.idpf.org/oebps/oebps1.2/index.htm. The OEBPS specification states that there must be something called an OEBPS package file which specifies OEBPS documents, images, and other objects that make up an entire OEBPS publication. What we are looking to do is to formally register a MIME Type for this package file in the standards tree. Specifically, we are seeking to register the following MIME Type for the OEBPS package: "application/oebps-package+xml". If this submission requires additional information for community review and IESG approval, please let me know. Best, Nick Bogaty -- Nick Bogaty Executive Director International Digital Publishing Forum (IDPF) nbogaty(a)idpf.org www.idpf.org (212) 924-9081 direct (212) 208-0978 fax

3 3

Review solicited for application/cellml-1.0+xml and application/cellml-1.1+xml
by Andrew Miller 24 Apr '06

24 Apr '06

Hi all, I have produced a revised Internet draft, http://www.ietf.org/internet-drafts/draft-miller-media-type-cellml-01.txt, following the earlier draft for the registration of application/cellml+xml reviewed on this list. This draft replaces the MIME type being registered, application/cellml+xml, with two MIME types application/cellml-1.0+xml and application/cellml-1.1+xml, based on the recommendations of several ietf-types list members. While CellML versions are not substantially different from each other in terms of the XML element localNames, the changes between 1.0 and 1.1(and likely any future versions) will make backwards compatibility for impossible for most, if not all, CellML processing tools. As such, a new media type for each version is justified. Similarly, the version parameter and the section on determining the version from the XML has been dropped. Both versions of the CellML specification are now referenced as normative references. There was a recommendation on the list that a file extension other than .xml be used for CellML files. This has been discussed with the CellML community on the CellML mailing list, and at the last (and earlier) CellML meetings. However, the consensus was that we should keep the convention of using .xml, as this is currently in wide use. A lot of CellML content currently being served is done by scripts, which can arbitrarily set the MIME type. Most other CellML content served over HTTP would be in its own directory, and so mechanisms like .htaccess(or content based type determination) supported by most popular webservers will be available. In addition, it is probably better that existing software be able to at least determine that it is an XML file, and so using an XML extension will result in text/xml or application/xml. As such, the section on File extension(s) has been left unchanged. Due to the fact that the names of MIME types have changed, I am restarting the two-week review period from today. If there are no new objections, I will submit the document for IESG approval on the 25th April, 2006. Please Note: cellml-discussion(a)cellml.org is a public list for the CellML community, but only accepts postings from list members. I am on the cellml-types mailing list, and will forward any responses posted there to the cellml-discussion list. Best regards, Andrew Miller ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

5 13

AW: media type review requested for application/auth-policy+xml
by Tschofenig, Hannes 13 Apr '06

13 Apr '06

Hi Mark, thanks for the quick response. Please find some comments inline: > Hi, > > On 4/13/06, Tschofenig, Hannes <hannes.tschofenig(a)siemens.com> wrote: > > > - security section should also reference sec 10 of RFC 3023. > > > > Why do you think so? > > I read through Section 10 of RFC 3023 and I don't think > that the aspects > > there are applicable for our usage environment. > > The aspects of security described in that section are quite generic, > so I'd be surprised if that were the case. Just as one example, do > you rule out the use of external entities with auth-policy+xml? If > not, then that section is relevant as it describes some potential > security problems with their use. > > FWIW, I think any +xml type should reference it as a matter of course. We have external entities updating and receiving the authorization policies. However, we capture this issue already in the security consideration section in the Common Policy draft. The additional issues listed in RFC 3023 regarding * validation, * system level command execution * CSS style sheets, XSL transformations, * xmldsig usage * change the display processor environment Still, I can, if you want, make a reference to RFC 3023 if you think that this is, in general, a good idea. > > > > - I'd recommend picking a file extension specific to this > media type, > > > as many Web servers come pre-configured to serve .xml files as > > > application/xml, or even an RSS media type. > > I don't care about the file extension. Can you > > suggest something reasonable? > > How about "apxml"? I checked "apx", but it's been used before; > > http://filext.com/detaillist.php?extdetail=apx&Search=Search For me this sounds good. Still, I sent a mail to the Geopriv ML. Ciao Hannes > Cheers, > > Mark. > -- > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca >

2 1