April 2006 - Ietf-types - alvestrand.no

Preliminary Community Review: text/json
by Douglas Crockford 15 Apr '07

15 Apr '07

This is notice of a potential media type registration. The details may be found here: http://www.ietf.org/internet-drafts/draft-crockford-jsonorg-json-02.txt

10 11

Request for review of 9 MIME type for 3GPP SA4
by Magnus Westerlund 29 Mar '07

29 Mar '07

Hi, attached is a word document with a proposal for 9 MIME type that will go into the 3GPP Technical Specification 26.346 and when present in that be requested to registered. Most of these media types are for XML formats, although not all of them. Please review them, comments received within a week can be directly addressed at the 3GPP SA4 meeting. TS 26.346 can in its latest form be fetched here: http://www.3gpp.org/ftp/Specs/archive/26_series/26.346/26346-610.zip However some of the references in the chapter relate to text that are being specified and added. They are available in the following document: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_36/Docs/S4-050514.zip Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

3 8

W3C Last Call and Media Type request for comments: XQuery and XQueryX
by Liam Quin 18 Jan '07

18 Jan '07

[ Notes: (1) - I'm trying to follow a new procedure here. Becasue not everything is in place, the documents I refer to probably don't have perfect wording. The documentation on the process was released after the documents were frozen for Last Call, but we can make any needed changes for the next round of publication. I see that we failed to define the correct syntax for parameters, and would welcome comments on any other areas wheer we need to improve. (2) The following text will be inserted in the next published versions of the documents: This registration is for community review and will be (or has been) submitted to the IESG for review, approval, and registration with IANA. (3) We are using Bugzilla to track comments on these documents; comments on these MIME-related pats of the documents may be made on the ietf-types mailing list or in Bugzilla. See the individual documents and their respective "Status of this Document" sections for further information. - Liam ] In accordance with the draft Media Type Specifications and Registration Procedures [1], and on behalf of the W3C XML Query Working Group [2], I hereby give notice that W3C has published two specifications at the stage "Last Call Working Draft" which each incorporate definitions of a standards-tree MIME media type, as allowed for in section 3.1 of [1], and request comments on these definitions. The types and subtypes are application/xquery defined in "XQuery 1.0: An XML Query Language" [3] optional parameter: charset application/xquery+xml defined in "XML Syntax for XQuery 1.0 (XQueryX)" [4] optional parameter: charset **** Registration for application/xquery also at [3] I The application/xquery Media Type (Non-Normative) --------------------------------------------------- This Appendix specifies the media type for XQuery Version 1.0. XQuery is a language for querying over collections of data from XML data sources, as specified in the main body of this document. I.1 Introduction ---------------- This document, together with its normative references, defines the language XQuery Version 1.0. This Appendix provides information about the application/xquery media type, which is intended to be used for transmitting queries written in the XQuery language. This document was prepared by members of the W3C XML Query Working Group. Please send comments to public-qt-comments [at] w3.org, a public mailing list with archives at http://lists.w3.org/Archives/Public/public-qt-comments. I.2 Registration of MIME Media Type application/xquery ------------------------------------------------------ MIME media type name: application MIME subtype name: xquery Required parameters: none Optional parameters: charset The syntax of XQuery is expressed in Unicode but may be written with any Unicode-compatible character encoding, including UTF-8 or UTF-16, or transported as US-ASCII or Latin-1 with Unicode characters outside the range of the given encoding represented using an XML-style ෝ syntax. I.2.1 Interoperability Considerations None known. I.2.2 Applications Using this Media Type The public XQuery Web page lists more than two dozen implementations of the XQuery language, both proprietary and open source. This new media type is being registered to allow for deployment of XQuery on the World Wide Web. I.2.3 File Extensions The most common file extensions in use for XQuery are .xq and .xquery. The appropriate Macintosh file type code is TEXT. I.2.4 Intended Usage The intended usage of this media type is for interchange of XQuery expressions. I.2.5 Author/Change Controller XQuery was produced by, and is maintained by, the World Wide Web Consortium's XML Query Working Group. The W3C has change control over this specification. I.3 Encoding Considerations For use with transports that are not 8-bit clean, quoted-printable encoding is recommended since the XQuery syntax itself uses the US-ASCII-compatible subset of Unicode. An XQuery document may contain an encoding declaration as part of its version declaration: xquery version "1.0" encoding "utf-8"; If an XQuery document contains an encoding declaration, it overrides the default encoding specified by the MIME charset parameter. I.4 Recognizing XQuery Files An XQuery file may have the string xquery version "V.V" near the beginning of the document, where "V.V" is a version number. Currently the version number, if present, must be "1.0". I.5 Charset Default Rules XQuery documents use the Unicode character set and, by default, the UTF-8 encoding. I.6 Security Considerations Queries written in XQuery may cause arbitrary URIs to be dereferenced. Therefore, the security issues of [Uniform Resource Locators (URL)] Section 6 should be considered. In addition, the contents of file: URIs can in some cases be accessed, processed and returned as results. Furthermore, because the XQuery language permits extensions, it is possible that application/xquery may describe content that has security implications beyond those described here. The XML Query Working group is working on a facility to allow XQuery expressions to be used to create and update persistent data. Untrusted queries should not be given write access to data. **** Registration for application/xquery+xml also at [4] C The application/xquery+xml Media Type (Non-Normative) ------------------------------------------------------- This Appendix specifies the media type for XQueryX Version 1.0. XQueryX is the XML syntax of a language, XQuery, for querying over data from XML data sources, as specified in [XQuery 1.0: An XML Query Language]. C.1 Introduction ---------------- This document, together with its normative references, defines the XML syntax for the XML Query language XQuery Version 1.0. This Appendix specifies the application/xquery+xml media type, which is intended to be used for transmitting queries expressed in the XQueryX syntax. This document was prepared by members of the W3C XML Query Working Group. Please send comments to public-qt-comments [at] w3.org, a public mailing list with archives at http://lists.w3.org/Archives/Public/public-qt-comments. C.2 Registration of MIME Media Type application/xquery+xml MIME media type name: application MIME subtype name: xquery+xml Required parameters: none Optional parameters: charset This parameter has identical semantics to the charset parameter of the application/xml media type as specified in [RFC3023]. C.2.1 Encoding Considerations The considerations as specified in RFC 3023 [XMLMIME] also hold for 'application/xquery+xml'. C.2.2 Fragment Identifiers For documents labeled as 'application/xquery+xml', fragment identifiers are handled as specified in RFC 3023 [XMLMIME]. C.2.3 Restrictions on usage The intended usage of this media type is for interchange of XQueryX expressions. C.2.4 Security Considerations Queries written in XQueryX may cause arbitrary URIs to be dereferenced. Therefore, the security issues of [Uniform Resource Locators (URL)] Section 6 should be considered. In addition, the contents of file: URIs can in some cases be accessed, processed and returned as results. Furthermore, because the XQuery language (and thus the XQueryX language) permits extensions, it is possible that application/xquery+xml may describe content that has security implications beyond those described here. However, if the processor follows only the normative semantics of this specification, this content will be ignored. Only in the case where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues arise. The XML Query Working group is working on a facility to allow XQuery (and thus XQueryX) expressions to be used to create and update persistent data. Untrusted queries should not be given write access to data. C.2.5 Interoperability Considerations See Section 5 ConformanceXQ. C.2.6 Applications That Use This Media Type The public XQuery Web page lists more than two dozen implementations of the XQuery language, both proprietary and open source. Some of these are known to support XQueryX. This new media type is being registered to allow for deployment of XQueryX on the World Wide Web. There is no experimental, vendor specific, or personal tree predecessor to "application/xquery+xml", reflecting the fact that no applications currently recognize it. This new type is being registered in order to allow for the expected deployment of XQueryX 1.0 on the World Wide Web, as a first class XML application. C.2.7 Additional Information C.2.7.1 Recognizing XQuery Files ("Magic Numbers") Although no byte sequences can be counted on to consistently identify XQueryX, XQueryX documents will have the sequence "http://www.w3.org/yyyy/mm/XQueryX" to identify the XQueryX namespace (where "yyyy" is exactly four decimal digits and "mm" is exactly two decimal digits). This sequence will normally be found in a namespace attribute of the first element in the document. C.2.7.2 File Extensions The most common file extension in use for XQueryX is .xqx. C.2.7.3 Macintosh File Type Code(s) The appropriate Macintosh file type code is TEXT. C.2.8 Person and Email Address to Contact For Further Information Jim Melton, Oracle Corp., jim.melton [at] oracle.com C.2.9 Intended Usage COMMON C.2.10 Author/Change Controller XQuery was produced by, and is maintained by, the World Wide Web Consortium's XML Query Working Group. The W3C has change control over this specification. [1] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-02.txt [2] http://www.w3.org/XML/Query [3] http://www.w3.org/TR/2005/WD-xquery-20050404/#id-mime-type [4] http://www.w3.org/TR/2005/WD-xqueryx-20050404/#xqueryx-id-mime-type -- Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/ http://www.holoweb.net/~liam/

8 16

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

Request for review: draft-ietf-mmusic-sdp-media-content-03.txt
by Colin Perkins 13 Apr '06

13 Apr '06

The MMUSIC working group is considering draft-ietf-mmusic-sdp-media- content-03.txt: This document defines a new Session Description Protocol (SDP) media- level attribute, 'content'. The 'content' attribute defines the content of the media stream in more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big screen or small screen) based on its content. It has been suggested that members of the ietf-types list may have experience with this type of attribute in other areas. Accordingly, this message is to solicit cross-area review of the draft. We would be grateful if any comments could be provided before 1st May 2006. Thanks, Colin (mmusic co-chair)

1 0

Re: media type review requested for application/auth-policy+xml
by Mark Baker 13 Apr '06

13 Apr '06

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. > > - 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 Cheers, Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca

1 0

Media Type Dilution
by Greg Smith 13 Apr '06

13 Apr '06

I was pointed to this mailing list as the most appropriate to post the following email. These originally were two postings made previously to the AVT working group. My first post of this on Sunday prior to my subscription resulted in moderation-land. My apologies if you receive this multiple times. It appears that alternate means are being deployed to differentiate between major media types in part because the original uses of the Media Type are not being strictly followed. Please exuse me if these issues have been addressed before, I would appreciate a link or two to the appropriate postings. I have recently been asked about the Media Type being able to distinguish between audio and video. It was stated to me that, for example, application/ogg, application/smil, and application/smil+xml each can contain either audio, video, or test, and these Media Type registrations do not distinguish between audio and video. My response was that the Media Type *should* differentiate between audio, video, and other major types of media. But the top-level Media Types appear to be suffering from dilution. RSS Media (excerpt from version 1.1.0) In addition the latest draft of the Media RSS Specification justifies the addition of a "medium" attribute that differentiates between major "mediums" (image | audio | video | document | executable) because "it simplifies decision making on the reader side, as well as flushes out any ambiguities between MIME type and object type" This appears to model EXACTLY the original purpose of the Media Type (section 3 of http://www.isi.edu/in-notes/rfc2046.txt where we see: text | image | audio | video | application, as well as composite types: multipart | message, and later-adopted "model"). ATOM While ATOM (http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt) Proposes to differentiate between an "entry" (in ATOM format) and all other "media". It seems like a very useful construct (within ATOM) to be able to differentiate collections based on both Top-level Media Type and Sub-type. Further dilution of the Top-level Media Types seems contradictory to the entire purpose of Media Type registrations. RSS and Atom Feed Auto-Discovery for Internet TV http://maketelevision.com/log/rss_and_atom_feed_auto-discovery_for_internet… Makes use of an attribute: media="tv", to differentiate between what (in my opinion) should be Top-level Media Type (using for example, "video/*"). Granted that these examples are not standards (yet), they substantiate the view that Top-level Media Types are not sufficient for media differentiation for purposes of dispatch. Ogg As a concrete example of the dilution, application/ogg is the Media Type for use of all audio and/or video that is in the Ogg file format. Ogg often contains vorbis-encoded audio or theora-encoded video. It seems appropriate, then, that either audio/ogg and video/ogg, or audio/vorbis and video/theora, be appropriated for use for files using the Ogg format. I found that in Feb 2006, there was an application that included appropriation of audio/vorbis, specifically for RTP transport, and not for Ogg file format. This concerns me only because audio/vorbis seems very appropriate to use for Ogg file format Vorbis-encoded audio and its appropriation for use only using RTP "container" format seems premature or somehow misguided. Over the past year, I've had quite an introduction to video container formats vs. encoding formats. I maintain the "Media Chart" for Pocket PCs at http://www.feederreader.com/mediachart.html , which attempts to sort out some of the confusion. Part of the issue is that Major Type, Media Container, and Media Encoding are variously intertwined and mixed. But not essentially addressed by the Media Type specification. And because these issues are at a level above individual Media Types, it seems they would need to be addressed outside any Media Type application. These issues appear to me to be ripe for "de-confusioning" and it occurred to me that the organization responsible for Media Types would be the place to start. I'm open the the suggestion that I am not fully aware of how Media Types are used in their entirety. I am, however, suggesting that there is a growing problem with use of Media Types in determining dispatch requirements. Functional Interpretation Although I have not seen dispatching based on Media Types generically described in the RFCs that I reviewed, I have found the description in a w3c document "Client handling of MIME headers" [1] and RFC3023 Section 13 (Appendix A) [2]. This seems to me to be a major use and benefit of defining appropriate Media Types, especially with respect to the assignment of Sub-types within the appropriate Top-level types. Common browsers and operating systems both allow dispatching based on Media Types, in addition to the "similar-to-dispatching" uses I mentioned previously in ATOM, RSS Media, and Autodiscovery. Even at the operating system or the browser level, this sometimes run into problems for the user where a particular audio or video Media Container contains a Media Encoding that is not decodable by the application that has been associated based on the Media Type. Terminology Interpretation RFC4288 Section 4.1 "Functionality Requirement" states that "Media types MUST function as an actual media format." The next sentence states "Registration of things that are better thought of as a transfer encoding...are not allowed." and then goes on to give base64 as an example of a transfer encoding. It is still unclear which, if any, of the following categories (using my prior terminology) are construed as a "transfer encoding": Major Type, Media Container, and Media Encoding. To me, these "categories" are the logical way of distinguishing audio and video media simply because these are the broad categories determining how and if a particular file can be played on any particular system. "Major Type" clearly corresponds to top-level Media Type (audio, video, etc.). Media Containers (such as Ogg, MPEG-4 Part 14, "AVI", "MOV") clearly do *not* correspond to RFC4288 Section 4.1 "Transfer Encoding" and clearly correspond to actual media formats. So the remaining question is: do Media Encodings commonly in use correspond to "transfer encodings", in which case they do not qualify as distinct Media Types. As examples of Media Encoding I offer: Vorbis (audio), Theora (video), MPEG-4 Part 2 (video), MPEG-4 Part 3 (audio), MPEG-4 Part 10 (video). A deeper and more exhaustive survey of current actual Media Type registrations would be useful here. Part of the issue may be that "transfer encoding" in the sense of RFC4288 Section 4.1 seems to refer to "lossless," "reversible," and "universally decodable". Such is not the case with many audio and/or video encodings. Based on this interpretation, I would argue that Transfer Encodings do not refer to the common audio and/or video encodings, and therefore that these audio and video encodings qualify for Media Type registration. Possible Solution The danger is that if every combination of Media Containers and Media Encodings were registered as distinct Media Types, the result would be an astronomical increase in the number of Media Types and it would increase the number, if not the complexity, of the dispatch rules within operating systems and browsers. It seems one way around this might be to use a "+suffix" mechanism (obviously specified such that it is backward compatible with RFC3023), or some other "extension". It could be specified that only Media Containers qualify as a Media Sub-type, and that one or more (optional) suffixes would indicate the contained media encodings. And that for containers that can contain or do commonly contain only audio, then they be registered under the audio top-level type. For contains that can contain or do commonly contain video (with synchronized audio), they should be registered as a video top-level Media Type. For Media Containers that serve both functions (including audio only), they should be registered as audio and video top-level Media Types. With the added "Encoding extension" mechanism, there may be complications in that current dispatching mechanisms are "fixed" meaning that the media dispatchers expect a fixed string match of Media Type to dispatchee. This does not easily permit interpretation of added-in-arbitrary-order suffixes. To solve this problem, the order of suffixes could be programmatically determined (for example, either absolute alphabetical or alphabetical within major groups of audio, video, other). This way, only one permutation of each combination of Media Encodings would need to be added. Summary I'm not sure if this is viewed as a problem by others, but it seems to be a serious issue that is beginning to be "worked around" outside of, and parallel to, the Media Type definitions in several different and incompatible ways. Inclusion of more strict interpretation and differentiation of top-level types and/or formal recognition of Media Containers and Media Encodings within the Media Type system seems like significant and appropriate improvements to Media Type registration. References [1] "Client handling of MIME headers" http://www.w3.org/2001/tag/doc/mime-respect-20030709 "The architecture of the Web depends on applications making dispatching and security decisions for resources based on their Internet Media Types and other MIME headers." http://www.w3.org/2001/tag/doc/mime-respect.html The current version states "For example, HTTP and MIME use the value of the "Content-Type" header field to indicate the Internet media type of the representation, which influences the dispatching of handlers and security-related decisions made by recipients of the message." Section 3.1 A media type is not simply an indication of data format; it also refers to a preferred interpretation of that data format. This preferred interpretation may impact the recipient's functional decisions, such as whether the data is rendered, stored, or executed. In practice, media types are often used as the key for selecting an appropriate handler to interpret the data received. It is possible for a single data format to be associated with multiple media types and for a single media type to describe a superset of many different data formats. --- end excerpt [2] http://www.ietf.org/rfc/rfc3023.txt Greg Smith __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

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

13 Apr '06

Hi Mark, thanks for your comments. > Some comments; > > - I'd suggest removing the UTF-8 default, because in the absence of a > charset parameter the XML document itself would be self-descriptive > about its encoding. I'd recommend simply punting to application/xml's > definition. Fine for me. > > - 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. > > - 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? Ciao Hannes > > Cheers, > > Mark. > -- > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca >

1 0