- Ietf-types - alvestrand.no

Proposed new MIME type
by tim.ocock＠symbian.com 10 Mar '03

10 Mar '03

Here at Symbian, our subsidiary, UIQ Technologies (www.uiq.com) would like to propose the creation of a new MIME type for classification of "theme" (or "skin") files used for personalisation of the user interface. The MIME type we are proposing is: application/vnd.uiq.theme I offer my apologies if at any time we have mistakenly not followed any correct procedure. We have found it difficult to find information about MIME type registration and are following the instructions in rfc1590, having not been able to ascertain if there are any more recent instructions than that. I appreciate your feedback. Best regards, Tim Ocock Technology Acquisition Specialist Symbian Ltd Tel: +44 (0) 20 7563 2039 ********************************************************************** Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK. This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify postmaster(a)symbian.com and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy. **********************************************************************

1 0

Missing postings on ietf-types and ietf-languages
by Harald Tveit Alvestrand 04 Jan '03

04 Jan '03

I messed up a mailing list software upgrade on Friday. As a result, there has been a number of missed messages on ietf-types and ietf-languages - 28 on ietf-types and 4 on ietf-languages. Most of those were probably spam (the ietf-types list, in particular, gets about 25 spams per day). But some may not be. All of you who sent mail should have gotten bounces back. If you have - the problem is fixed now - please resend! Harald

1 0

jpeg 2000
by Marc Mutz 20 Dec '02

20 Dec '02

Hi! Does anyone here have an overview of what mime type JPEG 2000 will have/has? I've found draft-singer-jp2-0{0,1}.txt, which registers image/jp{2,x} and some others for movie formats. But then, I've encountered image/j2k and a whole bunch of other mimetypes in the IETF branch. Nothing of that is listed as registered at IANA. Marc -- Ein Grundrecht auf Sicherheit steht bewusst nicht in der Verfassung. -- Sabine Leutheusser-Schnarrenberger (ehem. Bundesjustizministerin)

1 0

Re: draft-wilde-text-fragment-01 (was: Including 'fragment identifier semantics' ...)
by Mark Nottingham 23 Sep '02

23 Sep '02

[ trimmed distribution ] my .02 - > so, apart from the minor fixes, does anybody have an opinion about the > prantheses vs. equals syntax issue? Equals syntax is more URI-ish; it's easier to write a parser for correctly, and it's more likely that current code can be reused. > i also thought about adding a > checksum facility (md5 or something along these lines), so that fragment > identifiers could recognize a particular version of a resource. any > opinions about this feature (it would be optional, so that applications > would be allowed to ignore the checksum)? The fragment identifier doesn't seem like a good place to put this functionality, IMHO. If people want to version their docs, they should have different URIs for them.

1 0

RE: Including 'fragment identifier semantics' in MIME media type registration?
by Dan Kohn 12 Sep '02

12 Sep '02

Note that section 5 of RFC 3023 is probably due for an update based on the W3C work you're considering. http://www.ietf.org/rfc/rfc3023.txt It would also be worth noting and/or commenting on this draft: http://www.ietf.org/internet-drafts/draft-wilde-text-fragment-01 - dan -- Dan Kohn <mailto:dan@dankohn.com> <http://www.dankohn.com/> <tel:+1-650-327-2600> The mass of men lead lives of quiet desperation. - Henry David Thoreau -----Original Message----- From: Chris Lilley [mailto:chris@w3.org] Sent: Thursday, September 05, 2002 06:44 To: www-tag(a)w3.org; Larry Masinter Cc: uri(a)w3.org; ietf-types(a)iana.org Subject: Re: Including 'fragment identifier semantics' in MIME media type registration? On Wednesday, September 4, 2002, 5:57:01 PM, Larry wrote: LM> The URI specification notes that the interpretation LM> of a fragment identifier (the part of a URI reference LM> after a '#') depends on the media type. LM> However, the template for media type registration LM> doesn't have a place to document the meaning of LM> fragment identifiers within the media type. LM> Originally, fragment identifiers were only used within LM> HTML documents, so the point was somewhat moot. However, LM> now there are several specifications -- mainly from LM> the W3C -- that use fragment identifiers more explicitly, LM> as well as proposals for changing or adding semantics LM> for fragment identifiers for existing media types LM> (such as a recent proposal for a fragment identifier LM> for plain text.) LM> Should the registration form for media types include LM> a statement about the semantics of fragment identifiers LM> for that media type? Yes, your well presented summary above clearly indicates that the addition of such a section would be a desirable enhancement and close the lgap between media types and the URI specification. LM> Is there a consistent policy or design for 'good' LM> fragment identifier use? Previously I would have said yes; current discussions indicate that there is some disagreement, but it is being actively discussed. I hope that it will be possible, fairly soon, for the Architecture document to specify 'best practice' and 'common idiom' and to clarify, in a way that covers the majority of existing specifications, what fragment identifiers do and how best to construct them and how they may be used or their use may affect other stages of processing such as presentation. Currently, I believe that we may have to note that there are existing exceptions that have an entirely different model. Although I am hoping that by appropriate layering, we may be able to have a low level and universally applicable "syntactic" processing that says "this portion/fragment of the content has been linked to" and higher levels ('presentation', and 'semantic') that say, respectively what the effect of traversing a link including a fragment has on presentation and what effect it has on application semantics (hoping that covers the RDF case). There is some initial wording to that effect in the Architecture document, though it needs further discussion. http://www.w3.org/TR/2002/WD-webarch-20020830/#fragid -- Chris mailto:chris@w3.org _______________________________________________ Ietf-types mailing list Ietf-types(a)eikenes.alvestrand.no http://www.alvestrand.no/mailman/listinfo/ietf-types

3 3

Including 'fragment identifier semantics' in MIME media type registration?
by Larry Masinter 07 Sep '02

07 Sep '02

The URI specification notes that the interpretation of a fragment identifier (the part of a URI reference after a '#') depends on the media type. However, the template for media type registration doesn't have a place to document the meaning of fragment identifiers within the media type. Originally, fragment identifiers were only used within HTML documents, so the point was somewhat moot. However, now there are several specifications -- mainly from the W3C -- that use fragment identifiers more explicitly, as well as proposals for changing or adding semantics for fragment identifiers for existing media types (such as a recent proposal for a fragment identifier for plain text.) Should the registration form for media types include a statement about the semantics of fragment identifiers for that media type? Is there a consistent policy or design for 'good' fragment identifier use? Larry -- http://larry.masinter.net

4 3

Re: CORRECTION: Please review ietf-draft of SMIL media-type registration
by Philipp Hoschka 27 Aug '02

27 Aug '02

Kari, good catches ! See inline for more Kari Pihkala wrote: > > Hi, > > I noticed some inconsistencies with the SMIL namespaces in the > draft. In section 4: > > All SMIL 2.0 files must also include a declaration of the SMIL 2.0 > namespace. This should appear shortly after the string "<smil", and > should read 'xmlns="http://www.w3.org/2001/SMIL20/PR/Language"'. Fixed this to use http://www.w3.org/2001/SMIL20/Language as namespace. > However, a different namespace in the end of section 5: > > An example use of this parameter as part of a HTTP GET transaction > would be: > > Accept: application/smil+xml; > profile="http://www.w3.org/2001/SMIL20/REC/HostLanguage" Removed the REC part. The namespace should be different, I think, since this is the way that a client informs a server that it supports SMIL basic. I'm not sure that people actually use the following URI to identify SMIL basic, however http://www.w3.org/2001/SMIL20/REC/HostLanguage or that anyone uses the "accept" header at all - I'll send a seperate message to the www-smil list on that. > Also, either of these namespaces match the one in SMIL 2.0 spec > (http://www.w3.org/TR/2001/REC-smil20-20010807/smil20-profile.html) > 13.3.2 SMIL 2.0 Language Conformance > > 5. A document must declare a default namespace for its elements with an > xmlns attribute on the smil root element with its identifier URI: > <smil xmlns="http://www.w3.org/2001/SMIL20/Language"> > ... > </smil> > > You may want to check these... > > - Kari ...

1 0

CORRECTION: Please review ietf-draft of SMIL media-type registration
by Philipp Hoschka 22 Aug '02

22 Aug '02

[the previous mail contained a superfluous and inappropriate attachment, and an errouneous "reply-to" header - Apologies] ------ This email serves to instantiate the two week discussion period on "ietf-types(a)iana.org" of the ietf-draft describing the SMIL media-type registration. You can find the draft at http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-10.txt The expected course of advancement for this specification is: 1. I have notified one of the Application area directors (Ned Freed) 2. Request publication as an Informational RFC as specified: ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt 3. Ensure IANA is aware of the publication and posts the registration as specified: ftp://ftp.isi.edu/in-notes/rfc2048.txt The changes in this specification since the last version discussed on "ietf-xml-mime(a)imc.org" include: 1. Registration of application/xml+smil in addition to application/smil 2. Addition of optional "profile" parameter 3. Addition of paragraph describing how to recognize SMIL files by looking into the file. Thank you. -- -Philipp Hoschka

1 0

Please review ietf-draft of SMIL media-type registration
by Philipp Hoschka 22 Aug '02

22 Aug '02

This email serves to instantiate the two week discussion period on "ietf-types(a)iana.org" of the ietf-draft describing the SMIL media-type registration. You can find the draft at http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-10.txt The expected course of advancement for this specification is: 1. I have notified one of the Application area directors (Ned Freed) 2. Request publication as an Informational RFC as specified: ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt 3. Ensure IANA is aware of the publication and posts the registration as specified: ftp://ftp.isi.edu/in-notes/rfc2048.txt The changes in this specification since the last version discussed on "ietf-xml-mime(a)imc.org" include: 1. Registration of application/xml+smil in addition to application/smil 2. Addition of optional "profile" parameter 3. Addition of paragraph describing how to recognize SMIL files by looking into the file. Thank you. -- -Philipp Hoschka J. Reagle Internet-Draft W3C/LCS/MIT Expires: October 2002 June 2002 application/xenc+xml Media Type Registration draft-reagle-xenc-mediatype-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 22, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes a media type (application/xenc+xml) for use with the XML Encryption specification. Table of Contents 1. Discussion of this Document 2. Introduction 3. application/xenc+xml Registration 4. References 5. Author's Address 6. Full Copyright Statement Reagle, J. Expires October 2002 [Page 1] Internet-Draft XML Encryption Media-Type June 2002 1. Discussion of this Document Please send comments to xml-encryption(a)w3.org. To subscribe, send a message with the body 'subscribe' to xml-encryption(a)w3.org. The mailing list is publicly archived at http://lists.w3.org/Archives/Public/xml-encryption/ . 2. Introduction The XML Encryption Syntax and Processing document [XENC] specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data. The application/xenc+xml media type allows XENC applications to identify XENC documents for processing. Additionally it allows applications cognizant of this media-type (even if they are not XENC implementations) to note that the media type of the decrypted (original) object might a type other than XML. This media-type is only used for documents in which the XENC EncyptedData and EncryptedKey element types appear as the root element of the XML document. XML documents which contain XENC element types in places other than the root element can be described using facilities such as [XML-schema] or [StLaurent]. 3. application/xenc+xml Registration This is a media type registration as defined in Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [MIME-REG] MIME media type name: application MIME subtype name: xenc+xml Required parameters: none Optional parameters: charset Same as charset parameter of application/xml as specified in RFC 3023 [XML-MT] or the most recent specification that supersedes it. Encoding considerations: Same as charset parameter of application/xml as specified in RFC 3023 [XML-MT] or the most recent specification that supersedes it. Security considerations: Security considerations include many of those described in the Reagle, J. Expires October 2002 [Page 2] Internet-Draft XML Encryption Media-Type June 2002 Security Considerations of [XENC]. Interoperability considerations: none Published specification: [XENC]. Applications which use this media type: XENC is device-, platform-, and vendor-neutral and is supported by a range of Web applications. Additional Information: Magic number(s): none Although no byte sequences can be counted on to consistently identify XENC documents, they will be XML documents in which the root element's QName's LocalPart is 'EncryptedData' with an associated namespace name of 'http://www.w3.org/2001/04/xmlenc#'. The application/xenc+xml type name MUST only be used for data objects in which the root element is from the XENC namespace. File extension(s): .xml Macintosh File Type Code(s): "TEXT" Person & email address to contact for further information: Joseph Reagle <reagle(a)w3.org> XENC Working Group <xml-encryption(a)w3.org> Intended usage: COMMON Author/Change controller: The XENC specification is a work product of the World Wide Web Consortium. The W3C and the W3C XENC Working Group have change control over the specification. 4. References Glossary RFC 2828. Internet Security Glossary. Informational. R Shirey. 2000 http://www.ietf.org/rfc/rfc2828.txt HTTP RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1. Internet Official Protocol Standards. J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 1999. Reagle, J. Expires October 2002 [Page 3] Internet-Draft XML Encryption Media-Type June 2002 http://www.ietf.org/rfc/rfc2616.txt KEYWORDS RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. Best Current Practice. S. Bradner. March 1997. http://www.ietf.org/rfc/rfc2119.txt MIME RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. Standards Track. N. Freed & N. Borenstein. November 1996. http://www.ietf.org/rfc/rfc2045.txt StLaurent Registration of xmlns Media Feature Tag. S. St.Laurent, and I. Graham. Draft. http://simonstl.com/ietf/draft-stlaurent-feature-xmlns-02.txt XENC XML Encryption Syntax and Processing. D. Eastlake, and J. Reagle. W3C Candidate Recommendation, 2002. http://www.w3.org/TR/2002/CR-xmlenc-core-20020304/ XML Extensible Markup Language (XML) 1.0 (Second Edition). T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler. W3C Recommendation, October 2000. XML-MT RFC 3023: XML Media Types. Informational. M. Murata, S. St.Laurent, D Kohn. January 2001. http://www.ietf.org/rfc/rfc2376.txt XML-NS Namespaces in XML. T. Bray, D. Hollander, A. Layman. W3C Recommendation, January 1999. http://www.w3.org/TR/1999/REC-xml-names-19990114 XML-schema XML Schema Part 1: Structures D. Beech, M. Maloney, N. Mendelsohn. W3C Recommendation, May 2001. http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ XML Schema Part 2: Datatypes. P. Biron, A. Malhotra. W3C Recommendation, May 2001. http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ 5. Authors' Address Joseph M. Reagle Jr., W3C Massachusetts Institute of Technology Laboratory for Computer Science Reagle, J. Expires October 2002 [Page 4] Internet-Draft XML Encryption Media-Type June 2002 NE43-358, 200 Technology Square Cambridge, MA 02139 Phone: + 1.617.258.7621 Email: reagle(a)w3.org 6. Full Copyright Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1 0

Re: draft-reagle-xenc-mediatype-01.txt
by Martin Duerst 20 Aug '02

20 Aug '02

Hello Aaron, dear RDF Core WG, On ietf-types(a)iana.org and some related list, we were just looking at http://www.w3.org/TR/xmlenc-core/#sec-MediaType which containes some instances of text like this: Same as ... of application/xml as specified in RFC 3023[XML-MT] or the most recent specification that supercedes it. There seemed to be general agreement that a moving target is not a good idea. Josef Reagle told us that he got that text from: http://www.aaronsw.com/2002/rdf-mediatype.html I wanted to tell you that you may want to fix this. Regards, Martin. At 14:47 02/08/19 -0400, Joseph Reagle wrote: >On Thursday 08 August 2002 06:07 pm, Larry Masinter wrote: > > # Optional parameters: charset > > # Same as charset parameter of application/xml as > > # specified in RFC 3023 [XML-MT] or the most recent > > # specification that supersedes it. > > > > I admit I was a little confused on this one, and misread > > what it said. However, I don't understand > > "or the most recent specification that supersedes it", > > though, since a specification may supercede RFC 3023 > > but not be appropriate for a reference to a particular > > section. > >I'm happy to eliminate that text as I oppose those sort of references in >general. In this case, I was merely following what I could see the rdf >folks doing for a similar type of registration: > http://www.aaronsw.com/2002/rdf-mediatype.html >

1 0