Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0MBj6Ou056396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2009 04:45:06 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0MBj626056395; Thu, 22 Jan 2009 04:45:06 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0MBirdt056368 for ; Thu, 22 Jan 2009 04:45:04 -0700 (MST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 22 Jan 2009 11:44:52 -0000 Received: from dslb-088-074-175-196.pools.arcor-ip.net (EHLO hive) [88.74.175.196] by mail.gmx.net (mp070) with SMTP; 22 Jan 2009 12:44:52 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX183ZvoIo4g3At+9AAtgAA/zTipzDSRVIkkMwP13gZ KspQf5OIN3A27J From: Bjoern Hoehrmann To: Phil Archer Cc: ietf-types@iana.org, ietf-xml-mime@imc.org, Public POWDER Subject: Re: Media Type Registration request for POWDER and POWDER-S Date: Thu, 22 Jan 2009 12:44:53 +0100 Message-ID: References: <493D3127.1080904@philarcher.org> <4978548D.1080604@philarcher.org> In-Reply-To: <4978548D.1080604@philarcher.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.66 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * Phil Archer wrote: >To whom it may concern, > >This request was submitted on 8th December last year, archived at [1], >and effectively replaced the requests sent previously that were >incorrect for various reasons [2]. > >As the POWDER WG makes its final preparations for a transition request >for W3C Proposed Recommendation status, I realise that there has been no >acknowledgement of the corrected requests, still less a resolution. Ultimately your request has to go to the IESG; the ietf-types list is only for community review of proposed registrations, and IANA will only register types in the standards tree as directed by the IESG. I believe the W3C prefers if registration requests to the IESG are made through W3C's IETF liaison (Dan Connolly and Philippe Le Hégaret). -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0MBCTvV053689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2009 04:12:29 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0MBCSIm053688; Thu, 22 Jan 2009 04:12:28 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0MBCGq6053638 for ; Thu, 22 Jan 2009 04:12:27 -0700 (MST) (envelope-from phil@philarcher.org) Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090122111215.YVJN4080.mtaout02-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Thu, 22 Jan 2009 11:12:15 +0000 Received: from [86.12.217.99] by aamtaout02-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090122111214.QOYM21638.aamtaout02-winn.ispmail.ntl.com@[86.12.217.99]>; Thu, 22 Jan 2009 11:12:14 +0000 Message-ID: <4978548D.1080604@philarcher.org> Date: Thu, 22 Jan 2009 11:12:13 +0000 From: Phil Archer User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ietf-types@iana.org CC: ietf-xml-mime@imc.org, Public POWDER Subject: Re: Media Type Registration request for POWDER and POWDER-S References: <493D3127.1080904@philarcher.org> In-Reply-To: <493D3127.1080904@philarcher.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.0 c=1 a=JvociZDhN3IA:10 a=zgnTKQX5KOQA:10 a=S89q9SsuAAAA:8 a=SSmOFEACAAAA:8 a=RFp60smDAAAA:8 a=vOyFs-Gt2QM4L5hM1bQA:9 a=l4_FmH1SqDKH7sTCvkoA:7 a=KZzjVydg05LF2WC4bAPA6C5_guwA:4 a=DFZ4TeuG6JwA:10 a=rUGnz4CYuSoA:10 a=e6IU-BRPPdS6bXfZ:21 a=x6U-xavQM-XC5ABG:21 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To whom it may concern, This request was submitted on 8th December last year, archived at [1], and effectively replaced the requests sent previously that were incorrect for various reasons [2]. As the POWDER WG makes its final preparations for a transition request for W3C Proposed Recommendation status, I realise that there has been no acknowledgement of the corrected requests, still less a resolution. The W3C Recommendations Track document that includes the registration details is available with W3C member access at [3]. The text is not expected to change before PR transition is requested (apart from removing diff marks etc.). Can I ask you to look into the matter please? Thank you. Phil Archer On behalf of the POWDER WG. [1] http://www.alvestrand.no/pipermail/ietf-types/2008-December/002122.html [2] http://www.alvestrand.no/pipermail/ietf-types/2008-December/002117.html [3] http://www.w3.org/2007/powder/Group/powder-dr/20090120-diff.html#appB Phil Archer wrote: > To whom it may concern, > > This e-mail is sent in line with "How to Register an Internet Media Type > for a W3C Spec" [1] and follows an earlier attempt to follow the IANA > process (see 2, 3). > > Having taken advice [4], the W3C POWDER Working Group requests that > consideration be given to registering two Media types for POWDER and > POWDER-S documents. > > POWDER: application/powder+xml > ============================== > > POWDER is a constrained dialect of XML that transports RDF properties > and objects that can be associated with multiple subjects. The media > type details are included in Appendix B of POWDER: Description Resources > [5] which has just completed its (second) Last Call period. The version > cited here includes changes made in response to last call comments and > is not yet published, however, it is the one (or very close to the one) > the working group will present as the Proposed Recommendation. It is > anticipated that this happen within the next 2 weeks. The relevant > section of the Description Resources document is as follows: > > Appendix B: POWDER Internet Media Type and Macintosh File Type > > The following Media Type has been submitted to the IESG for review, > approval, and registration with IANA > > contact: > Phil Archer or Matt Womer > > See also: > How to Register a Media Type for a W3C Specification > Internet Media Type registration, consistency of use > TAG Finding 3 June 2002 (Revised 4 September 2002) > > The Internet Media Type / MIME Type for POWDER is "application/powder+xml". > > It is recommended that POWDER files use the file extension of .xml (all > lowercase) on all platforms. > > It is recommended that POWDER files stored on Macintosh HFS file systems > be given a file type of "TEXT". > > Type name: > application > > Subtype name: > powder+xml > > Required parameters: > None > > Optional parameters: > None > > Encoding considerations: > Identical to those of "application/xml" as specified in [RFC3023], > section 3.2. > > Security considerations: > POWDER is used to make assertions, sometimes socially sensitive, about > web resources. Consumers of POWDER should be aware of the source and > chain of custody of this data. Security considerations for URIs > (Section 7 of RFC 3986 [RFC3986]) and IRIs (Section 8 of RFC 3987 > [RFC3987]) apply to the extent that describing resources in POWDER may > prompt consumers to retrieve those resources. > > Interoperability considerations: > There are no known interoperability issues. > > Published specification: > http://www.w3.org/TR/powder-dr/ > > Applications which use this media type: > No known applications currently use this media type. > > Additional information: > Magic number(s): > As specified for "application/xml" in RFC 3023 [RFC3023], section 3.2. > > File extension(s): > .xml > > Fragment identifiers: > Identical to that of "application/xml" as described in RFC 3023 > [RFC3023], section 5. > > Base URI: > As specified in RFC 3023 [RFC3023], section 6. > > Macintosh file type code(s): > "TEXT" > > Person & email address to contact for further information: > public-powderwg@w3.org > > Intended usage: > COMMON > > Restrictions on usage: > None > > Author/Change controller: > The POWDER specification is a work product of the World Wide Web > Consortium's Protocol for Web Description Resources (POWDER) Working > Group. The W3C has change control over these specifications. > > POWDER-S: application/powder-s+xml > ================================== > > Semantic POWDER, or POWDER-S, is typically generated by performing a > transformation on a POWDER document. Each POWDER-S document is an OWL > ontology from which properties and values can be inferred for a given > resource. In order for inferences to be drawn, however, OWL tools must > implement a semantic extension (defined separately) and it is for this > reason that a new media type is requested, rather than using the > existing RDF/OWL media types. A POWDER-S document is valid RDF/OWL but > is essentially meaningless without the semantic extension. > > The media type details are included in Appendix C of POWDER: Description > Resources [5] as follows: > > Appendix C: POWDER-S Internet Media Type and Macintosh File Type > > The following Media Type has been submitted to the IESG for review, > approval, and registration with IANA > > contact: > Phil Archer or Matt Womer > > See also: > How to Register a Media Type for a W3C Specification > Internet Media Type registration, consistency of use > TAG Finding 3 June 2002 (Revised 4 September 2002) > > The Internet Media Type / MIME Type for POWDER-S is > "application/powder-s+xml". > > It is recommended that POWDER-S files use the file extension of .rdf > (all lowercase) on all platforms. > > It is recommended that POWDER-S files stored on Macintosh HFS file > systems be given a file type of "TEXT". > > Type name: > application > > Subtype name: > powder-s+xml > > Required parameters: > None > > Optional parameters: > None > > Encoding considerations: > Identical to those of "application/xml" as specified in [RFC3023], > section 3.2. > > Security considerations: > POWDER-S is used to make assertions, sometimes socially sensitive, > about web resources. Consumers of POWDER should-S be aware of the > source and chain of custody of this data. Security considerations for > URIs (Section 7 of RFC 3986 [RFC3986]) and IRIs (Section 8 of RFC 3987 > [RFC3987]) apply to the extent that describing resources in POWDER-S > may prompt consumers to retrieve those resources. > > Interoperability considerations: > There are no known interoperability issues. > > Published specification: > http://www.w3.org/TR/powder-dr/ > > Applications which use this media type: > No known applications currently use this media type. > > Additional information: > > Magic number(s): > As specified for "application/xml" in RFC 3023 [RFC3023], section 3.2. > > File extension(s): > .rdf > > Fragment identifiers: > Identical to that of "application/xml" as described in RFC 3023 > [RFC3023], section 5. > > Base URI: > As specified in RFC 3023 [RFC3023], section 6. > > Macintosh file type code(s): > "TEXT" > > Person & email address to contact for further information: > public-powderwg@w3.org > > Intended usage: > COMMON > > Restrictions on usage: > None > > Author/Change controller: > The POWDER-S specification is a work product of the World Wide Web > Consortium's Protocol for Web Description Resources (POWDER) Working > Group. The W3C has change control over these specifications. > > Please advise if there is any missing or incorrect information in this > request. > > Yours faithfully > > Phil Archer > POWDER WG Chair. > > > [1] http://www.w3.org/2002/06/registering-mediatype > [2] http://lists.w3.org/Archives/Public/public-powderwg/2008Dec/0001.html > [3] http://lists.w3.org/Archives/Public/public-powderwg/2008Dec/0002.html > [4] For example > http://lists.w3.org/Archives/Public/public-powderwg/2008Dec/0026.html > and http://lists.w3.org/Archives/Public/public-powderwg/2008Dec/0012.html > [5] http://www.w3.org/2007/powder/Group/powder-dr/20081205.html > > > -- Phil Archer w. http://philarcher.org/ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n064B1I3072751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 21:11:01 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n064B1SV072750; Mon, 5 Jan 2009 21:11:01 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n064AnRH072719 for ; Mon, 5 Jan 2009 21:11:00 -0700 (MST) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n064AlMa016290 for ; Tue, 6 Jan 2009 13:10:48 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse2.scbb.aoyama.ac.jp with smtp id 51ed_fef091c6_dba7_11dd_8e3a_0019b9e2b3d9; Tue, 06 Jan 2009 13:10:47 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:37399) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 6 Jan 2009 13:02:43 +0900 Message-Id: <6.0.0.20.2.20090106130933.03ca2d20@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 06 Jan 2009 13:10:01 +0900 To: Sandro Hawke , ietf-types@iana.org, ietf-xml-mime@imc.org From: Martin Duerst Subject: Re: please review "text/owl-functional" and "application/owl+xml" Cc: www-archive@w3.org In-Reply-To: <23816.1231200231@ubehebe> References: <23816.1231200231@ubehebe> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello Sandro, Any reason why your Unicode reference is the outdated 3.0 (currently 5.0)? Regards, Martin. At 09:03 09/01/06, Sandro Hawke wrote: > >The following two media type registrations are currently published, each >as part a of W3C Last Call Working Draft ([1] [2]), and will soon be >submitted to the IESG for review, approval, and registration with IANA >(as per [3]). > >At this point, we would appreciate comments on this registration >information. If you see any problems, please let us know; I'll act as a >liason between these IETF lists and the W3C Working Group responsible >for these specifications. > > -- Sandro > >[1] >http://www.w3.org/TR/owl2-syntax/#Appendix:_Internet_Media_Type.2C_File_Extension.2C_and_Macintosh_File_Type >[2] >http://www.w3.org/TR/owl2-xml-serialization/#Appendix:_Internet_Media_Type.2C_File_Extension.2C_and_Macintosh_File_Type >[3] http://www.w3.org/2002/06/registering-mediatype > >================================================================ > >Type name > > text > >Subtype name > > owl-functional > >Required parameters > > None > >Optional parameters > > charset > > This parameter may be required when transfering non-ASCII > data across some protocols. If present, the value of charset > should be UTF-8. > >Encoding considerations > > The syntax of the OWL functional-style Syntax is expressed over code > points in Unicode [UNICODE]. The encoding should be UTF-8 [RFC3629], > but other encodings are allowed. > > [[ UNICODE: The Unicode Standard Version 3.0, Addison Wesley, Reading > MA, 2000, ISBN: 0-201-61633-5, > http://www.unicode.org/unicode/standard/standard.html ]] > >Security considerations > > The OWL functional-style Syntax uses IRIs as term > identifiers. Applications interpreting data expressed in the OWL > functional-style Syntax should address the security issues of > Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, > as well as Uniform Resource Identifiers (URI): Generic Syntax > [RFC3986] Section 7. Multiple IRIs may have the same > appearance. Characters in different scripts may look similar (a > Cyrillic "o" may appear similar to a Latin "o"). A character > followed by combining characters may have the same visual > representation as another character (LATIN SMALL LETTER E followed > by COMBINING ACUTE ACCENT has the same visual representation as > LATIN SMALL LETTER E WITH ACUTE). Any person or application that is > writing or interpreting data in the OWL functional-style Syntax must > take care to use the IRI that matches the intended semantics, and > avoid IRIs that may look similar. Further information about matching > of similar characters can be found in Unicode Security > Considerations [UNISEC] and Internationalized Resource Identifiers > (IRIs) [RFC3987] Section 8. > > [[ UNISEC: Unicode Security Considerations, Mark Davis and Michel > Suignard, July 2008, http://www.unicode.org/reports/tr36/ ]] > >Interoperability considerations > > There are no known interoperability issues. > >Published specification > > This specification. > > [[ http://www.w3.org/TR/owl2-syntax/ ]] > >Applications which use this media type > > No widely deployed applications are known to currently use this > media type. It is expected that OWL tools will use this media type > in the future. > >Additional information > > None. > >Magic number(s) > > OWL functional-style Syntax documents may have the strings > 'Namespace:' or 'Ontology:' (case dependent) near the beginning of > the document. > >File extension(s) > > ".ofn" > >Base IRI > > There are no constructs in the OWL functional-style Syntax to change > the Base IRI. > >Macintosh file type code(s) > > "TEXT" > >Person & email address to contact for further information > > Sandro Hawke > >Intended usage > > COMMON > >Restrictions on usage > > None > >Author/Change controller > > The OWL functional-style Syntax is the product of the W3C OWL > Working Group; W3C reserves change control over this specification. > >================================================================ > >Type name > > application > >Subtype name > > owl+xml > >Required parameters > > None > >Optional parameters > > charset > > This parameter may be required when transfering non-ascii > data across some protocols. > >Encoding considerations > > The syntax of the OWL XML Serialization is expressed over code > points in Unicode [UNICODE]. > > [[ UNICODE: The Unicode Standard Version 3.0, Addison Wesley, Reading > MA, 2000, ISBN: 0-201-61633-5, > http://www.unicode.org/unicode/standard/standard.html ]] > >Security considerations > > The OWL XML Serialization uses IRIs as term > identifiers. Applications interpreting data expressed in the OWL XML > Serialization should address the security issues of > Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, > as well as Uniform Resource Identifiers (URI): Generic Syntax > [RFC3986] Section 7. Multiple IRIs may have the same > appearance. Characters in different scripts may look similar (a > Cyrillic "o" may appear similar to a Latin "o"). A character > followed by combining characters may have the same visual > representation as another character (LATIN SMALL LETTER E followed > by COMBINING ACUTE ACCENT has the same visual representation as > LATIN SMALL LETTER E WITH ACUTE). Any person or application that is > writing or interpreting data in the OWL XML Serialization must take > care to use the IRI that matches the intended semantics, and avoid > IRIs that may look similar. Further information about matching of > similar characters can be found in Unicode Security Considerations > [UNISEC] and Internationalized Resource Identifiers (IRIs) [RFC3987] > Section 8. > > [[ UNISEC: Unicode Security Considerations, Mark Davis and Michel > Suignard, July 2008, http://www.unicode.org/reports/tr36/ ]] > >Interoperability considerations > > There are no known interoperability issues. > >Published specification > > This specification. > > [[ http://www.w3.org/TR/owl2-xml-serialization/ ]] > >Applications which use this media type > > None at current time. > >Additional information > > None. > >Magic number(s) > > OWL XML documents are XML documents and thus may have initial > strings similar to any XML document. > >File extension(s) > > ".owx" > >Base URI > > As in XML. > >Macintosh file type code(s) > > "TEXT" > >Person & email address to contact for further information > > Sandro Hawke > >Intended usage > > COMMON > >Restrictions on usage > > None > >Author/Change controller > > The OWL XML Serialization is the product of the W3C OWL Working > Group; W3C reserves change control over this specification. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp