Return-Path: X-Original-To: ietf-types@core3.amsl.com Delivered-To: ietf-types@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D1A928C175 for ; Mon, 21 Mar 2011 13:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1T1sp4dBKxb for ; Mon, 21 Mar 2011 13:26:18 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [208.77.188.36]) by core3.amsl.com (Postfix) with ESMTP id 96B9028C16D for ; Mon, 21 Mar 2011 13:26:17 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id p2LKRE37003624 for ; Mon, 21 Mar 2011 13:27:35 -0700 Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 21 Mar 2011 13:27:13 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.270.2; Mon, 21 Mar 2011 13:27:13 -0700 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.117]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Mon, 21 Mar 2011 13:27:13 -0700 From: Brian Clubb To: Paul Libbrecht Thread-Topic: [ietf-types] Request for review of standards tree registration request for OpenXPS Thread-Index: AQHL6AYuob4DYEWMX0SiOGfC8i5arZQ4PHTw Date: Mon, 21 Mar 2011 20:27:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [208.77.188.36]); Mon, 21 Mar 2011 13:27:35 -0700 (PDT) Cc: "ietf-types@iana.org" Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 20:26:47 -0000 No worries! I appreciate the feedback! Here is the corrected template: Name : Brian Clubb Email : bclubb@microsoft.com MIME media type name : application MIME subtype name : Standards Tree - openxps Required parameters : N/A Optional parameters : N/A Encoding considerations : 8-bit Security considerations : OpenXPS uses ZIP compression as specified in .ZIP File Format Specification= from PKWARE, Inc., version 6.2.0 (2004). ZIP compressed XML requires pars= ing untrusted XML data and untrusted ZIP data. consumer is responsible for= validating the .zip archive, the XML structure, and the resource content. = Per spec, there should be no active content provided as part of the OpenXP= S format. The consumer must ensure that no malicious active content is err= oneously provided in the OpenXPS document. Valid content is described in t= he EMCA-388 specification (http://www.ecma-international.org/publications/s= tandards/Ecma-388.htm) Also see section E.3 of ECMA-388 specification (http://www.ecma-internation= al.org/publications/standards/Ecma-388.htm) OpenXPS Documents follow requirements set out in this Standard, as well as = other normative references including the Open Packaging Conventions. Implem= entations may use the following steps to identify an unknown file or stream= as an OpenXPS Document within an Open Packaging Conventions payload. 1. Te= st that the file or stream is a ZIP file a. As required by =A79.2 of the Op= en Packaging Conventions =20 b. First four bytes correspond to the local file header signature defined i= n the .ZIP File Format Specification from PKWARE, Inc., version 6.2.0 (2004= ) 2. Test that a valid Package Relationships zip item exists a. As require= d by =A78.3.4 of the Open Packaging Conventions b. Check that the content t= ype for the package relationships zip item is correctly defined in the Cont= ent Types stream (see OPC =A78.1.2) as a relationships part 3. Test that th= e Package Relationships Part contains a relationship (see OPC =A78.3) whose= Target attribute points to a valid FixedDocumentSequence Part a. As requir= ed by =A710.2 of this Standard b. Check that the content type for the Fixed= DocumentSequence part is correctly defined in the Content Types stream as a= FixedDocumentSequence part=20 Interoperability considerations : application/OpenXPS documents are specified by the XML schemas standardized in ECMA-388. Applications and drivers currently producing/consuming Microsoft XPS conten= t cannot directly produce/consume OpenXPS. Changes are required to address= differences in the two specifications, such as namespace, print ticket usa= ge, use of JPEG XR, etc. Published specification : The published Standard ECMA-388 is available at: http://www.ecma-international.org/publications/standards/Ecma-388.htm Applications which use this media : The application/oxps MIME type can be used to identify CSTA XML (ECMA-388) instance documents. No published applications or print drivers = currently use OpenXPS. The intent is for any application or driver that ca= n currently produce/consume Microsoft XPS to also adopt OpenXPS. Examples = of such applications would include but are not limited to: Microsoft XPS V= iewer, Microsoft XPS Document Writer, Microsoft Internet Explorer 9. Additional information : 1. Magic number(s) : ZIP archive CRC-32: 504b 0304 per http://www.pkware.co= m/documents/APPNOTE/APPNOTE-6.2.0.txt. Note that is it a requirement of th= e consumer to ensure that the contents of the ZIP archive is a valid OpenXP= S structure. 2. File extension(s) : .oxps 3. Macintosh uniform type identifier : org.ecma.oxps conforms to com.pkware= .zip-archive 4. Object Identifiers: N/A 5. Windows clipboard name: "OpenXPS" To ensure interoperability, the clipboard format must be a complete OpenXPS= file with .oxps extension. Person & email address to contact for further information: Ecma International Helpdesk Rue du Rhone114 CH-1204 Geneva Switzerland helpdesk@ecma-international.org Person to contact for further information : 1. Name : Ecma International Helpdesk 2. Email : helpdesk@ecma-international.org Intended usage : Common This type will be used for all documents conforming to the Open XML Paper Specifcation's (ECMA-388) Open XPS Document format, published by ECMA. Author/Change controller : The ECMA-388 Standard is developed and maintained by the Ecma TC46 Working Group. -----Original Message----- From: Paul Libbrecht [mailto:paul@hoplahup.net]=20 Sent: Monday, March 21, 2011 1:25 PM To: Brian Clubb Cc: ietf-types@iana.org Subject: Re: [ietf-types] Request for review of standards tree registration= request for OpenXPS Thank you Brian, Le 16 mars 2011 =E0 21:14, Brian Clubb a =E9crit : > 3. Macintosh file type code : org.ecma.oxps conforms to com.pkware.zip-ar= chive >=20 should read: 3. Macintosh uniform type identifier : org.ecma.oxps conforms to com.pkware= .zip-archive I promise this is my last word.. ;-). paul Return-Path: X-Original-To: ietf-types@core3.amsl.com Delivered-To: ietf-types@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C9EC28B56A for ; Mon, 21 Mar 2011 13:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vm7O48YU9F5A for ; Mon, 21 Mar 2011 13:23:58 -0700 (PDT) Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:1::37]) by core3.amsl.com (Postfix) with ESMTP id 784483A687E for ; Mon, 21 Mar 2011 13:23:57 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by pechora2.lax.icann.org (8.13.8/8.13.8) with ESMTP id p2LKP9ud011077 for ; Mon, 21 Mar 2011 13:25:29 -0700 Received: from brouwer.fritz.box (srbk-5d804129.pool.mediaWays.net [93.128.65.41]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0MRvbR-1QU8RH1ja5-00SvWq; Mon, 21 Mar 2011 21:25:06 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Paul Libbrecht In-Reply-To: Date: Mon, 21 Mar 2011 21:25:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Clubb X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:gcOvtm8YHj+PNXTscr0FKFpy8Fz4k/kD7/CNONhRe6q eHDtrsmX8281q5ZND2xoyoNEUgcE6vGfMU8osSnNckOclxFbKT D3voEcugrwpr05AAs194kAyowkTUXqiX6fS2tqnYST4RjhNfgB Bv6kmPW7AiM2w0e1GB/ZRauLUPEiGmsmSvkt8txPAGJXq75FdS VOx90wOjP4/BzhDPs+GBNRD9YC0jffjqEYIItZh3O0= X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora2.lax.icann.org [208.77.188.37]); Mon, 21 Mar 2011 13:25:30 -0700 (PDT) Cc: "ietf-types@iana.org" Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 20:23:59 -0000 Thank you Brian, Le 16 mars 2011 =E0 21:14, Brian Clubb a =E9crit : > 3. Macintosh file type code : org.ecma.oxps conforms to = com.pkware.zip-archive >=20 should read: 3. Macintosh uniform type identifier : org.ecma.oxps conforms to = com.pkware.zip-archive I promise this is my last word.. ;-). paul= Return-Path: X-Original-To: ietf-types@core3.amsl.com Delivered-To: ietf-types@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D213A6997 for ; Wed, 16 Mar 2011 13:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBm+VELBoEcC for ; Wed, 16 Mar 2011 13:13:38 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) by core3.amsl.com (Postfix) with ESMTP id 8A3843A690F for ; Wed, 16 Mar 2011 13:13:37 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id p2GKEgaf018907 for ; Wed, 16 Mar 2011 16:15:03 -0400 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 16 Mar 2011 13:14:42 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 16 Mar 2011 13:14:42 -0700 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.187]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Wed, 16 Mar 2011 13:14:41 -0700 From: Brian Clubb To: "ietf-types@iana.org" Thread-Topic: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS Thread-Index: AcvkFl7V3RY9cOdPREaTMlQj/X8bbg== Date: Wed, 16 Mar 2011 20:14:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_FE6603D65048F44AB8F8955AE89A09B9172CEF73TK5EX14MBXW652w_" MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Wed, 16 Mar 2011 16:15:04 -0400 (EDT) X-Mailman-Approved-At: Mon, 21 Mar 2011 08:51:20 -0700 Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 20:13:46 -0000 --_000_FE6603D65048F44AB8F8955AE89A09B9172CEF73TK5EX14MBXW652w_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I received some feedback directly that did not include the mailing list. I= have verified the feedback and updated the "Magic Number" section in the t= emplate. Having received no further feedback, I am making a "Last Call" re= quest for comment before sending this on. Thanks! Brian TEMPLATE: Name : Brian Clubb Email : bclubb@microsoft.com MIME media type name : application MIME subtype name : Standards Tree - openxps Required parameters : N/A Optional parameters : N/A Encoding considerations : 8-bit Security considerations : OpenXPS uses ZIP compression as specified in .ZIP File Format Specification= from PKWARE, Inc., version 6.2.0 (2004). ZIP compressed XML requires pars= ing untrusted XML data and untrusted ZIP data. consumer is responsible for= validating the .zip archive, the XML structure, and the resource content. = Per spec, there should be no active content provided as part of the OpenXP= S format. The consumer must ensure that no malicious active content is err= oneously provided in the OpenXPS document. Valid content is described in t= he EMCA-388 specification (http://www.ecma-international.org/publications/s= tandards/Ecma-388.htm) Also see section E.3 of ECMA-388 specification (http://www.ecma-internation= al.org/publications/standards/Ecma-388.htm) OpenXPS Documents follow requirements set out in this Standard, as well as = other normative references including the Open Packaging Conventions. Implem= entations may use the following steps to identify an unknown file or stream= as an OpenXPS Document within an Open Packaging Conventions payload. 1. Te= st that the file or stream is a ZIP file a. As required by =A79.2 of the Op= en Packaging Conventions b. First four bytes correspond to the local file header signature defined i= n the .ZIP File Format Specification from PKWARE, Inc., version 6.2.0 (2004= ) 2. Test that a valid Package Relationships zip item exists a. As require= d by =A78.3.4 of the Open Packaging Conventions b. Check that the content t= ype for the package relationships zip item is correctly defined in the Cont= ent Types stream (see OPC =A78.1.2) as a relationships part 3. Test that th= e Package Relationships Part contains a relationship (see OPC =A78.3) whose= Target attribute points to a valid FixedDocumentSequence Part a. As requir= ed by =A710.2 of this Standard b. Check that the content type for the Fixed= DocumentSequence part is correctly defined in the Content Types stream as a= FixedDocumentSequence part Interoperability considerations : application/OpenXPS documents are specified by the XML schemas standardized in ECMA-388. Applications and drivers currently producing/consuming Microsoft XPS conten= t cannot directly produce/consume OpenXPS. Changes are required to address= differences in the two specifications, such as namespace, print ticket usa= ge, use of JPEG XR, etc. Published specification : The published Standard ECMA-388 is available at: http://www.ecma-international.org/publications/standards/Ecma-388.htm Applications which use this media : The application/oxps MIME type can be used to identify CSTA XML (ECMA-388) instance documents. No published applications or print drivers = currently use OpenXPS. The intent is for any application or driver that ca= n currently produce/consume Microsoft XPS to also adopt OpenXPS. Examples = of such applications would include but are not limited to: Microsoft XPS V= iewer, Microsoft XPS Document Writer, Microsoft Internet Explorer 9. Additional information : 1. Magic number(s) : ZIP archive CRC-32: 504b 0304 per http://www.pkware.co= m/documents/APPNOTE/APPNOTE-6.2.0.txt. Note that is it a requirement of th= e consumer to ensure that the contents of the ZIP archive is a valid OpenXP= S structure. 2. File extension(s) : .oxps 3. Macintosh file type code : org.ecma.oxps conforms to com.pkware.zip-arch= ive 4. Object Identifiers: N/A 5. Windows clipboard name: "OpenXPS" To ensure interoperability, the clipboard format must be a complete OpenXPS= file with .oxps extension. Person & email address to contact for further information: Ecma International Helpdesk Rue du Rhone114 CH-1204 Geneva Switzerland helpdesk@ecma-international.org Person to contact for further information : 1. Name : Ecma International Helpdesk 2. Email : helpdesk@ecma-international.org Intended usage : Common This type will be used for all documents conforming to the Open XML Paper Specifcation's (ECMA-388) Open XPS Document format, published by ECMA. Author/Change controller : The ECMA-388 Standard is developed and maintained by the Ecma TC46 Working Group. --_000_FE6603D65048F44AB8F8955AE89A09B9172CEF73TK5EX14MBXW652w_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I received some feedback directly that did not inclu= de the mailing list.  I have verified the feedback and updated the = 220;Magic Number” section in the template.  Having received no f= urther feedback, I am making a “Last Call” request for comment before sending this on.

 

Thanks!

Brian

 

TEMPLATE:

 

Name : Brian Clubb<= o:p>

 

Email : bclubb@micr= osoft.com

 

MIME media type nam= e : application

 

MIME subtype name := Standards Tree – openxps

 

Required parameters= : N/A

 

 

Optional parameters= :

N/A

 

 

Encoding considerat= ions : 8-bit

 

 

Security considerat= ions :

OpenXPS uses ZIP co= mpression as specified in .ZIP File Format Specification from PKWARE, Inc.,= version 6.2.0 (2004).  ZIP compressed XML requires parsing untrusted = XML data and untrusted ZIP data.  consumer is responsible for validating the .zip archive, the XML structure, and the= resource content.  Per spec, there should be no active content provid= ed as part of the OpenXPS format.  The consumer must ensure that no ma= licious active content is erroneously provided in the OpenXPS document.  Valid content is described in the EMCA-388 = specification (http://www.ecma-international.org/publications/standards/Ecm= a-388.htm)

 

 

Also see section E.= 3 of ECMA-388 specification (http://www.ecma-international.org/publications= /standards/Ecma-388.htm)

 

OpenXPS Documents f= ollow requirements set out in this Standard, as well as other normative ref= erences including the Open Packaging Conventions. Implementations may use t= he following steps to identify an unknown file or stream as an OpenXPS Document within an Open Packaging Conventions= payload. 1. Test that the file or stream is a ZIP file a. As required by = =A79.2 of the Open Packaging Conventions 

 

b. First four bytes= correspond to the local file header signature defined in the .ZIP File For= mat Specification from PKWARE, Inc., version 6.2.0 (2004)  2. Test tha= t a valid Package Relationships zip item exists a. As required by =A78.3.4 of the Open Packaging Conventions b. Che= ck that the content type for the package relationships zip item is correctl= y defined in the Content Types stream (see OPC =A78.1.2) as a relationships= part 3. Test that the Package Relationships Part contains a relationship (see OPC =A78.3) whose Target attribute point= s to a valid FixedDocumentSequence Part a. As required by =A710.2 of this S= tandard b. Check that the content type for the FixedDocumentSequence part i= s correctly defined in the Content Types stream as a FixedDocumentSequence part

 

 

Interoperability co= nsiderations :

application/OpenXPS= documents are specified by the XML schemas

   standa= rdized in ECMA-388.

Applications and dr= ivers currently producing/consuming Microsoft XPS content cannot directly p= roduce/consume OpenXPS.  Changes are required to address differences i= n the two specifications, such as namespace, print ticket usage, use of JPEG XR, etc.

 

 

Published specifica= tion :

The published Stand= ard ECMA-388 is available at:

http://www.ecma-int= ernational.org/publications/standards/Ecma-388.htm

 

 

Applications which = use this media :

The application/oxp= s MIME type can be used to identify CSTA XML

(ECMA-388) instance= documents.  No published applications or print drivers currently use = OpenXPS.  The intent is for any application or driver that can current= ly produce/consume Microsoft XPS to also adopt OpenXPS.  Examples of such applications would include but are not lim= ited to:  Microsoft XPS Viewer, Microsoft XPS Document Writer, Microso= ft Internet Explorer 9.

 

 

 

Additional informat= ion :

 

1. Magic number(s) = : ZIP archive CRC-32: 504b 0304 per http://www.pkware.com/documents/APPNOTE= /APPNOTE-6.2.0.txt.  Note that is it a requirement of the consumer to = ensure that the contents of the ZIP archive is a valid OpenXPS structure.

2. File extension(s= ) : .oxps

3. Macintosh file t= ype code : org.ecma.oxps conforms to com.pkware.zip-archive

4. Object Identifie= rs: N/A

5. Windows clipboar= d name:  "OpenXPS"

 

To ensure interoper= ability, the clipboard format must be a complete OpenXPS file with .oxps ex= tension.

 

Person & email = address to contact for further information:

Ecma International = Helpdesk

Rue du Rhone114

CH-1204 Geneva=

Switzerland

helpdesk@ecma-inter= national.org

 

 

 

Person to contact f= or further information :

 

1. Name : Ecma Inte= rnational Helpdesk

2. Email : helpdesk= @ecma-international.org

 

Intended usage : Co= mmon

This type will be u= sed for all documents conforming to the Open XML

   Paper = Specifcation's (ECMA-388) Open XPS Document format, published

   by ECM= A.

 

 

Author/Change contr= oller : The ECMA-388 Standard is developed and

   mainta= ined by the Ecma TC46 Working Group.

--_000_FE6603D65048F44AB8F8955AE89A09B9172CEF73TK5EX14MBXW652w_-- Return-Path: X-Original-To: ietf-types@core3.amsl.com Delivered-To: ietf-types@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A9D73A6926 for ; Sat, 12 Mar 2011 05:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1QCBX5UMUFm for ; Sat, 12 Mar 2011 05:45:40 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 6AAAC3A6B56 for ; Sat, 12 Mar 2011 05:45:40 -0800 (PST) Received: by qwg5 with SMTP id 5so490076qwg.31 for ; Sat, 12 Mar 2011 05:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:organization:user-agent; bh=IPEX9oyCr/oLGxh2QkqMtudeXY9V+IfYEYPB7gJ8Who=; b=El8MAJ6R2RfpJcpl73zGg1xON9TLUcnVhMFK1kQ/uzW1vwLRDxJk+/oWeP3BU+y5g7 IOxAest+uA0Uy0IpGRPVk8NsOzKaA8LlzGFxJlHVBTKNmUXl/ockgbhYkLLOlkOWfwkT ACtySBSWEauiG4+YHkGGOSDv67TNogr8He6ro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:organization:user-agent; b=YR/9sfXKOgpmMKrHlwan9YuTOoyVa3JWG7QADNRC49CMKd9vmcys+DdA8jICGdp33N pGj4JKOrCiG8bJOGZam+Jo+n42d8id2lW+7oEvduGuhP7u2w6mTgaalu+27MXBW5n0a1 s46c3CSQipb5PsQxZ9JML8so/cZr30Efa6MZc= Received: by 10.229.32.69 with SMTP id b5mr9162530qcd.266.1299937620661; Sat, 12 Mar 2011 05:47:00 -0800 (PST) Received: from w3.org (c-24-218-124-254.hsd1.ma.comcast.net [24.218.124.254]) by mx.google.com with ESMTPS id p13sm4008442qcu.29.2011.03.12.05.46.59 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2011 05:46:59 -0800 (PST) Sender: "Eric Prud'hommeaux" Date: Sat, 12 Mar 2011 08:46:57 -0500 From: Eric Prud'hommeaux To: Nathan Message-ID: <20110312134656.GA9642@w3.org> References: <20110311233325.GC7042@w3.org> <4D7ABDC0.6090509@webr3.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4D7ABDC0.6090509@webr3.org> Organization: World Wide Web Consortium (W3C) - http://www.w3.org/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ietf-types Subject: Re: [ietf-types] Request for review of text/{turtle,n3} X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 13:45:42 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit * Nathan [2011-03-12 00:26+0000] > possible bugs.. tx for vigilance > Eric Prud'hommeaux wrote: > >Believing all of the issues in > > to be resolved, I'd like a > >review of the media type text/turtle . The Published specification > >will be , > >which will be the same as > > with > >modifications to the media type sections. > > > >Contact: > > Eric Prud'hommeaux > >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 Turtle is "text/turtle". > > > >It is recommended that Turtle files have the extension ".ttl" (all lowercase) on all platforms. > > > >It is recommended that sparql query files stored on Macintosh HFS file systems be given a file type of "TEXT". > > s/sparql/Turtle ?? fixed in attached > >This information that follows has been submitted to the IESG for review, approval, and registration with IANA. > > > >Type name: > > text > >Subtype name: > > turtle > >Required parameters: > > None > >Optional parameters: > > charset — this parameter is required when transfering non-ASCII data. If present, the value of charset is always UTF-8. > > s/transfering/transferring fixed in attached > >Encoding considerations: > > The syntax of Turtle is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [RFC3629]. > > Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F] > >Security considerations: > > Turtle is a general-purpose assertion language; applications may evaluate given data to infer more assertions or to dereference URIs, invoking the security considerations of the scheme for that URI. Note in particular, the privacy issues in RFC3023 section 10 for HTTP URIs. Data obtained from an inaccurate or malicious data source may lead to inaccurate or misleading conclusions, as well as the dereferencing of unintended URIs. Care must be taken to align the trust in consulted resources with the sensitivity of the intended use of the data; inferences of potential medical treatments would likely require different trust than inferences for trip planning. > > Turtle is used to express arbitrary application data; security considerations will vary by domain of use. Security tools and protocols applicable to text (e.g. PGP encryption, MD5 sum validation, password-protected compression) may also be used on Turtle documents. Security/privacy protocols must be imposed which reflect the sensitivity of the embedded information. > > Turtle can express data which is presented to the user, for example, RDF Schema labels. Application rendering strings retrieved from untrusted Turtle documents must ensure that malignant strings may not be used to mislead the reader. The security considerations in the media type registration for XML ([RFC3023] section 10) provide additional guidance around the expression of arbitrary data and markup. > > Turtle uses IRIs as term identifiers. Applications interpreting data expressed in Turtle sould address the security issues of Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7. > > s/sould/should fixed in attached > also, should it be referencing IRIs throughout, rather than URIs and IRIs? I think the dereferencing section should talk about URIs as HTTP, and I think all, URL schemes follow RFC2718's recommendation¹ of turning non-ascii chars into bytes and %HH-encoding them. Thus, all dereferencing happens via URNs. The media type *could* talk about referencing IRIs and either explicitly call out the URI translation, or leave it as an exercise for the reader. I'm interested in editorial suggestions. ¹ http://tools.ietf.org/html/rfc2718#section-2.2.5 The other place URI is used is in the template heading "Base URI". The media type registration template effectively asks "how does your language represent base URIs?" and I've answered it with "with @base, but it may also be an IRI". Should I change the template to include "Base IRI" instead of "Base URI"? > > Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "о" 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 Turtle must take care to use the IRI that matches the intended semantics, and avoid IRIs that make 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. > >Interoperability considerations: > > There are no known interoperability issues. > >Published specification: > > http://www.w3.org/TeamSubmission/2011/SUBM-turtle-20110314/ > >Applications which use this media type: > > No widely deployed applications are known to use this media type. It may be used by some web services and clients consuming their data. > >Additional information: > >Magic number(s): > > Turtle documents may have the strings '@prefix' or '@base' (case dependent) near the beginning of the document. > > unsure this counts as magic numbers?? * Nathan [2011-03-12 00:29+0000] > as before, afaict this isn't a magic number that can reliably be > used for sniffing and detection of content type.. possibly remove I had the impression that this was a call for heuristics which would allow one to sniff a reasonable subset of the documents in the wild. I note that Turtle and Notation3 are indistinguishable by the supplied "Magic number" discriminators, and that the the real discriminator, a lexical token '{', is hard to describe without rolling a lot of the lexer into an outrageous regex: ( '<' ([^<>"{}|^`\]-[#x00-#x20])* '>' | '"' ( ([^#x22#x5C#xA#xD]) | [tbnrf\"'] )* '"' | '"""' ( ( '"' | '""' )? ( [^"\] | '\' [tbnrf\"'] ) )* '"""' )* [#x20#x9#xD#xA]* '{' Also, even this distinction doesn't discriminate n3 from trig. Oof. Do others think I should say "Magic number: None"? > >File extension(s): > > ".ttl" > >Base URI: > > The Turtle '@base ' term can change the current base URI for relative IRIrefs in the query language that are used sequentially later in the document. > >Macintosh file type code(s): > > "TEXT" > >Person & email address to contact for further information: > > Eric Prud'hommeaux > >Intended usage: > > COMMON > >Restrictions on usage: > > None > >Author/Change controller: > > The Turtle specification is the product of David Beckett and Tim Berners-Lee. A W3C Working Group may assume maintenance of this document; W3C reserves change control over this specifications. > > > > > >I'll be submitting another form for text/n3 . > >Boy I hope this is near the end. > > likewise! fingers crossed > > Best, > > Nathan -- -ericP --azLHFNyN32YCQGCU Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename=turtle Content-Transfer-Encoding: 8bit Contact: Eric Prud'hommeaux 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 Turtle is "text/turtle". It is recommended that Turtle files have the extension ".ttl" (all lowercase) on all platforms. It is recommended that Turtle files stored on Macintosh HFS file systems be given a file type of "TEXT". This information that follows has been submitted to the IESG for review, approval, and registration with IANA. Type name: text Subtype name: turtle Required parameters: None Optional parameters: charset — this parameter is required when transferring non-ASCII data. If present, the value of charset is always UTF-8. Encoding considerations: The syntax of Turtle is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [RFC3629]. Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F] Security considerations: Turtle is a general-purpose assertion language; applications may evaluate given data to infer more assertions or to dereference URIs, invoking the security considerations of the scheme for that URI. Note in particular, the privacy issues in RFC3023 section 10 for HTTP URIs. Data obtained from an inaccurate or malicious data source may lead to inaccurate or misleading conclusions, as well as the dereferencing of unintended URIs. Care must be taken to align the trust in consulted resources with the sensitivity of the intended use of the data; inferences of potential medical treatments would likely require different trust than inferences for trip planning. Turtle is used to express arbitrary application data; security considerations will vary by domain of use. Security tools and protocols applicable to text (e.g. PGP encryption, MD5 sum validation, password-protected compression) may also be used on Turtle documents. Security/privacy protocols must be imposed which reflect the sensitivity of the embedded information. Turtle can express data which is presented to the user, for example, RDF Schema labels. Application rendering strings retrieved from untrusted Turtle documents must ensure that malignant strings may not be used to mislead the reader. The security considerations in the media type registration for XML ([RFC3023] section 10) provide additional guidance around the expression of arbitrary data and markup. Turtle uses IRIs as term identifiers. Applications interpreting data expressed in Turtle should address the security issues of Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7. Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "о" 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 Turtle must take care to use the IRI that matches the intended semantics, and avoid IRIs that make 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. Interoperability considerations: There are no known interoperability issues. Published specification: http://www.w3.org/TeamSubmission/2008/SUBM-turtle-20080114/ Applications which use this media type: No widely deployed applications are known to use this media type. It may be used by some web services and clients consuming their data. Additional information: Magic number(s): Turtle documents may have the strings '@prefix' or '@base' (case dependent) near the beginning of the document. File extension(s): ".ttl" Base URI: The Turtle '@base ' term can change the current base URI for relative IRIrefs in the query language that are used sequentially later in the document. Macintosh file type code(s): "TEXT" Person & email address to contact for further information: Eric Prud'hommeaux Intended usage: COMMON Restrictions on usage: None Author/Change controller: The Turtle specification is the product of David Beckett and Tim Berners-Lee. A W3C Working Group may assume maintenance of this document; W3C reserves change control over this specifications. --azLHFNyN32YCQGCU Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename=n3 Content-Transfer-Encoding: 8bit Contact: Eric Prud'hommeaux 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 Notation3 is "text/n3". It is recommended that Notation3 files have the extension ".n3" (all lowercase) on all platforms. It is recommended that Notation3 files stored on Macintosh HFS file systems be given a file type of "TEXT". This information that follows has been submitted to the IESG for review, approval, and registration with IANA. Type name: text Subtype name: n3 Required parameters: None Optional parameters: charset — this parameter is required when transferring non-ASCII data. If present, the value of charset is always UTF-8. Encoding considerations: The syntax of Notation3 is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [RFC3629]. Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F] Security considerations: Notation3 is a general-purpose assertion and logic language; built-in functions evaluate given data to infer more assertions. Certain built-in functions may dereference URIs, invoking the security considerations of the scheme for that URI. Note in particular, the privacy issues in [RFC3023] section 10 for HTTP URIs. Data obtained from an inaccurate or malicious data source may lead to inaccurate or misleading conclusions, as well as the dereferencing of unintended URIs. Built-in functions allow one to parameterize the incorporation of data: one example of more careful behavior would be to incorporate a source document only ifs hash matches a stated value and one may incorporate only those assertions matching a stated pattern. Care must be taken to align the trust in consulted resources with the sensitivity of the intended use of the data; inferences of potential medical treatments would likely require different trust than inferences for trip planning. Notation3 is used to express arbitrary application data; security considerations will vary by domain of use. Security tools and protocols applicable to text (e.g. PGP encryption, MD5 sum validation, password-protected compression) may also be used on Notation3 documents. Security/privacy protocols must be imposed which reflect the sensitivity of the embedded information. Notation3 can express data which is presented to the user, for example, RDF Schema labels. Application rendering strings retrieved from untrusted Notation3 documents must ensure that malignant strings may not be used to mislead the reader. The security considerations in the media type registration for XML ([RFC3023] section 10) provide additional guidance around the expression of arbitrary data and markup. Notation3 uses IRIs as term identifiers. Applications interpreting data expressed in Notation3 should address the security issues of Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7. Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "о" 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 Notation3 must take care to use the IRI that matches the intended semantics, and avoid IRIs that make 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. Interoperability considerations: There are no known interoperability issues. Published specification: http://www.w3.org/TeamSubmission/2008/SUBM-n3-20080114/ Applications which use this media type: No widely deployed applications are known to use this media type. It may be used by some web services and clients consuming their data. Additional information: Magic number(s): Notation3 documents may have the strings '@prefix' or '@base' (case dependent) near the beginning of the document. File extension(s): ".n3" Base URI: The Notation3 '@base ' term can change the current base URI for relative IRIrefs in the query language that are used sequentially later in the document. Macintosh file type code(s): "TEXT" Person & email address to contact for further information: Eric Prud'hommeaux Intended usage: COMMON Restrictions on usage: None Author/Change controller: The Notation3 specification is the product of Tim Berners-Lee. A W3C Working Group may assume maintenance of this document; W3C reserves change control over this specifications. --azLHFNyN32YCQGCU-- Return-Path: X-Original-To: ietf-types@core3.amsl.com Delivered-To: ietf-types@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E4763A684E for ; Sat, 12 Mar 2011 04:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dH-iaKJuUoMk for ; Sat, 12 Mar 2011 04:49:12 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 29D573A681A for ; Sat, 12 Mar 2011 04:49:12 -0800 (PST) Received: by qyk29 with SMTP id 29so290888qyk.10 for ; Sat, 12 Mar 2011 04:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:organization:user-agent; bh=wxMfQUAXmGxNrAoRG6/usEhEsqqhub1MJbiVldxWvHk=; b=Uc+Uin573vSam+Ssb+Fcm9ktX6sOioVVUSe5lXOCgP4k7Fa1hdhqhE6AxU7XNLF8Em dmz7PcYdxyMlsH54mA5STOpyC68hwbUfHf7jZuU910DFYLR5G2vdtA58tB9weHZ7eS/n TmiUD4LWSqNxkYC+pEOW8w0Y4icSOzxOY6XYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:organization:user-agent; b=VyD2gGLGgs+Lco0E6iuHm9HZCI9IQiAczXO0b4Q235XfRrMC8lhOfbsqpdqBpAvx7R KHxLdfs9EseiGu/Z64NUsX38vPXIUYb5BvnNHnzebFOEvoY0n3JDaUDKV7/3p+a1AaGV zJiSzWRk1R5SxEQz2gR6NTqiGfgqmCMDKPZEQ= Received: by 10.229.136.144 with SMTP id r16mr8352083qct.153.1299934232517; Sat, 12 Mar 2011 04:50:32 -0800 (PST) Received: from w3.org (c-24-218-124-254.hsd1.ma.comcast.net [24.218.124.254]) by mx.google.com with ESMTPS id c27sm1274814qck.46.2011.03.12.04.50.30 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2011 04:50:31 -0800 (PST) Sender: "Eric Prud'hommeaux" Date: Sat, 12 Mar 2011 07:50:29 -0500 From: Eric Prud'hommeaux To: ietf-types Message-ID: <20110312125028.GB9716@w3.org> References: <20110311233645.GD7042@w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110311233645.GD7042@w3.org> Organization: World Wide Web Consortium (W3C) - http://www.w3.org/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: www-archive@w3.org Subject: [ietf-types] minor editorial correction in text/n3 review request type: text/n3 X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 12:49:13 -0000 * Eric Prud'hommeaux [2011-03-11 18:36-0500] > Believing all of the issues in > to be resolved, I'd like a > review of the media type text/n3 . The Published specification > will be , > which will be the same as > with > modifications to the media type sections. Contact: Eric Prud'hommeaux 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 Notation3 is "text/n3". It is recommended that Notation3 files have the extension ".n3" (all lowercase) on all platforms. It is recommended that Notation3 files stored on Macintosh HFS file systems be given a file type of "TEXT". This information that follows has been submitted to the IESG for review, approval, and registration with IANA. Type name: text Subtype name: n3 Required parameters: None Optional parameters: charset — this parameter is required when transfering non-ASCII data. If present, the value of charset is always UTF-8. Encoding considerations: The syntax of Notation3 is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [RFC3629]. Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F] Security considerations: Notation3 is a general-purpose assertion and logic language; built-in functions evaluate given data to infer more assertions. Certain built-in functions may dereference URIs, invoking the security considerations of the scheme for that URI. Note in particular, the privacy issues in [RFC3023] section 10 for HTTP URIs. Data obtained from an inaccurate or malicious data source may lead to inaccurate or misleading conclusions, as well as the dereferencing of unintended URIs. Built-in functions allow one to parameterize the incorporation of data: one example of more careful behavior would be to incorporate a source document only ifs hash matches a stated value and one may incorporate only those assertions matching a stated pattern. Care must be taken to align the trust in consulted resources with the sensitivity of the intended use of the data; inferences of potential medical treatments would likely require different trust than inferences for trip planning. Notation3 is used to express arbitrary application data; security considerations will vary by domain of use. Security tools and protocols applicable to text (e.g. PGP encryption, MD5 sum validation, password-protected compression) may also be used on Notation3 documents. Security/privacy protocols must be imposed which reflect the sensitivity of the embedded information. Notation3 can express data which is presented to the user, for example, RDF Schema labels. Application rendering strings retrieved from untrusted Notation3 documents must ensure that malignant strings may not be used to mislead the reader. The security considerations in the media type registration for XML ([RFC3023] section 10) provide additional guidance around the expression of arbitrary data and markup. Notation3 uses IRIs as term identifiers. Applications interpreting data expressed in Notation3 sould address the security issues of Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7. Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "о" 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 Notation3 must take care to use the IRI that matches the intended semantics, and avoid IRIs that make 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. Interoperability considerations: There are no known interoperability issues. Published specification: http://www.w3.org/TeamSubmission/2008/SUBM-n3-20080114/ Applications which use this media type: No widely deployed applications are known to use this media type. It may be used by some web services and clients consuming their data. Additional information: Magic number(s): Notation3 documents may have the strings '@prefix' or '@base' (case dependent) near the beginning of the document. File extension(s): ".n3" Base URI: The Notation3 '@base ' term can change the current base URI for relative IRIrefs in the query language that are used sequentially later in the document. Macintosh file type code(s): "TEXT" Person & email address to contact for further information: Eric Prud'hommeaux Intended usage: COMMON Restrictions on usage: None Author/Change controller: The Notation3 specification is the product of Tim Berners-Lee. A W3C Working Group may assume maintenance of this document; W3C reserves change control over this specifications. > Note, this follows a request for a similar media type text/turtle . > -- > -ericP -- -ericP Return-Path: X-Original-To: ietf-types@core3.amsl.com Delivered-To: ietf-types@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4213A684E for ; Sat, 12 Mar 2011 04:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtBjcOLGgQXk for ; Sat, 12 Mar 2011 04:47:59 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 6E6DE3A681A for ; Sat, 12 Mar 2011 04:47:59 -0800 (PST) Received: by qyk7 with SMTP id 7so3024023qyk.10 for ; Sat, 12 Mar 2011 04:49:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:organization:user-agent; bh=A98UN/fv58igoXdUhdffIG81dB15ch/k2+LJiVE7pGQ=; b=N1Zmv/Rs9RPfo3ZmRtoiS1CJck7v1CBDUpHe+1VTZqItm3GknKEMEP2QWxZ8pcgNJy vi2qyi9fFqViFYvtAeV7OVOyslbb+CMGcbQ/Nbmfw+8fDFqaS8VicusZC8WI6IwRD9e7 AN10+pik/sDg0TrB9bf9MSTsmpJGRe1Z6qwgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:organization:user-agent; b=VmluqRM04mLxC4KbTrUE+ZZGXbYqH2s73zLMCU2DnbTZTNsaBLOMiZPm5ZbFYOoxsr 7H3+2rd93ChaqU69nbHnnp9s3aup+3gzh2L25FzDv71E84CxGNw4+mNN8Rr2MsVMy3Om IrOp9gSqZ7WQ+0FTHnsoZSGy/LylGQUs7nQq0= Received: by 10.229.73.81 with SMTP id p17mr8575456qcj.43.1299934159431; Sat, 12 Mar 2011 04:49:19 -0800 (PST) Received: from w3.org (c-24-218-124-254.hsd1.ma.comcast.net [24.218.124.254]) by mx.google.com with ESMTPS id s9sm3988645qco.0.2011.03.12.04.49.18 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2011 04:49:18 -0800 (PST) Sender: "Eric Prud'hommeaux" Date: Sat, 12 Mar 2011 07:49:16 -0500 From: Eric Prud'hommeaux To: ietf-types Message-ID: <20110312124915.GA9716@w3.org> References: <20110311233325.GC7042@w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110311233325.GC7042@w3.org> Organization: World Wide Web Consortium (W3C) - http://www.w3.org/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: www-archive@w3.org Subject: [ietf-types] minor editorial correction in text/turtle review request X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 12:48:01 -0000 updated to fix a pasto: s/sparql query files/Turtle files/ * Eric Prud'hommeaux [2011-03-11 18:33-0500] > Believing all of the issues in > to be resolved, I'd like a > review of the media type text/turtle . The Published specification > will be , > which will be the same as > with > modifications to the media type sections. Contact: Eric Prud'hommeaux 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 Turtle is "text/turtle". It is recommended that Turtle files have the extension ".ttl" (all lowercase) on all platforms. It is recommended that Turtle files stored on Macintosh HFS file systems be given a file type of "TEXT". This information that follows has been submitted to the IESG for review, approval, and registration with IANA. Type name: text Subtype name: turtle Required parameters: None Optional parameters: charset — this parameter is required when transfering non-ASCII data. If present, the value of charset is always UTF-8. Encoding considerations: The syntax of Turtle is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [RFC3629]. Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F] Security considerations: Turtle is a general-purpose assertion language; applications may evaluate given data to infer more assertions or to dereference URIs, invoking the security considerations of the scheme for that URI. Note in particular, the privacy issues in RFC3023 section 10 for HTTP URIs. Data obtained from an inaccurate or malicious data source may lead to inaccurate or misleading conclusions, as well as the dereferencing of unintended URIs. Care must be taken to align the trust in consulted resources with the sensitivity of the intended use of the data; inferences of potential medical treatments would likely require different trust than inferences for trip planning. Turtle is used to express arbitrary application data; security considerations will vary by domain of use. Security tools and protocols applicable to text (e.g. PGP encryption, MD5 sum validation, password-protected compression) may also be used on Turtle documents. Security/privacy protocols must be imposed which reflect the sensitivity of the embedded information. Turtle can express data which is presented to the user, for example, RDF Schema labels. Application rendering strings retrieved from untrusted Turtle documents must ensure that malignant strings may not be used to mislead the reader. The security considerations in the media type registration for XML ([RFC3023] section 10) provide additional guidance around the expression of arbitrary data and markup. Turtle uses IRIs as term identifiers. Applications interpreting data expressed in Turtle sould address the security issues of Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7. Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "о" 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 Turtle must take care to use the IRI that matches the intended semantics, and avoid IRIs that make 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. Interoperability considerations: There are no known interoperability issues. Published specification: http://www.w3.org/TeamSubmission/2008/SUBM-turtle-20080114/ Applications which use this media type: No widely deployed applications are known to use this media type. It may be used by some web services and clients consuming their data. Additional information: Magic number(s): Turtle documents may have the strings '@prefix' or '@base' (case dependent) near the beginning of the document. File extension(s): ".ttl" Base URI: The Turtle '@base ' term can change the current base URI for relative IRIrefs in the query language that are used sequentially later in the document. Macintosh file type code(s): "TEXT" Person & email address to contact for further information: Eric Prud'hommeaux Intended usage: COMMON Restrictions on usage: None Author/Change controller: The Turtle specification is the product of David Beckett and Tim Berners-Lee. A W3C Working Group may assume maintenance of this document; W3C reserves change control over this specifications. > I'll be submitting another form for text/n3 . and another pasto fix... > Boy I hope this is near the end. > -- > -ericP -- -ericP Return-Path: X-Original-To: ietf-types@core3.amsl.com Delivered-To: ietf-types@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509143A6A25 for ; Fri, 11 Mar 2011 15:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv0LUjApDMzo for ; Fri, 11 Mar 2011 15:35:29 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 5281A3A6A33 for ; Fri, 11 Mar 2011 15:35:29 -0800 (PST) Received: by vxg33 with SMTP id 33so3686128vxg.31 for ; Fri, 11 Mar 2011 15:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :mime-version:content-type:content-disposition :content-transfer-encoding:organization:user-agent; bh=c5xR1XukY/gEKERNFN7A1Vwa0KjrWcwxvkqk0CU/0ow=; b=SfjKDVB5Ye8kZfjSyhUGhVC5e2sSeOojpiQh/HFwdabSK+QBHiACEuHgqDkcKuvRkl jIGyx5cvV6JGYZbU3BHigwZE/XbRV9LuL47zlZQvFuLb/duC/0wVEn4kWkufEiCzoktr 6tCzGV8cdDgodMpXgmh7N9xLqqSL0fZNrP2cM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:content-transfer-encoding:organization :user-agent; b=YgMwtyMB/Hr7eMBvtzPpU1zMnQBqIMW0IUyivyRo22zxRtlTlFmygUODsLRE2fI+fb lNMP6GFpqSCXea23BCfICLgMYWyM1SdBuuXBedESR7rQIOabMQtahLDZsjligAWV7y42 I3qU3FkQ+WQ/LavDUWOmF4WwGdL/C1eGO0N/k= Received: by 10.52.158.74 with SMTP id ws10mr14577089vdb.29.1299886609008; Fri, 11 Mar 2011 15:36:49 -0800 (PST) Received: from w3.org (31-34-245.wireless.csail.mit.edu [128.31.34.245]) by mx.google.com with ESMTPS id cc3sm263338vdb.0.2011.03.11.15.36.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Mar 2011 15:36:48 -0800 (PST) Sender: "Eric Prud'hommeaux" Date: Fri, 11 Mar 2011 18:36:46 -0500 From: Eric Prud'hommeaux To: ietf-types Message-ID: <20110311233645.GD7042@w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Organization: World Wide Web Consortium (W3C) - http://www.w3.org/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: www-archive@w3.org Subject: [ietf-types] Request for review of Notation3 (an RDF serialization) media type: text/n3 X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 23:38:39 -0000 Believing all of the issues in to be resolved, I'd like a review of the media type text/n3 . The Published specification will be , which will be the same as with modifications to the media type sections. Contact: Eric Prud'hommeaux 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 Notation3 is "text/n3". It is recommended that Notation3 files have the extension ".n3" (all lowercase) on all platforms. It is recommended that sparql query files stored on Macintosh HFS file systems be given a file type of "TEXT". This information that follows has been submitted to the IESG for review, approval, and registration with IANA. Type name: text Subtype name: n3 Required parameters: None Optional parameters: charset — this parameter is required when transfering non-ASCII data. If present, the value of charset is always UTF-8. Encoding considerations: The syntax of Notation3 is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [RFC3629]. Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F] Security considerations: Notation3 is a general-purpose assertion and logic language; built-in functions evaluate given data to infer more assertions. Certain built-in functions may dereference URIs, invoking the security considerations of the scheme for that URI. Note in particular, the privacy issues in [RFC3023] section 10 for HTTP URIs. Data obtained from an inaccurate or malicious data source may lead to inaccurate or misleading conclusions, as well as the dereferencing of unintended URIs. Built-in functions allow one to parameterize the incorporation of data: one example of more careful behavior would be to incorporate a source document only ifs hash matches a stated value and one may incorporate only those assertions matching a stated pattern. Care must be taken to align the trust in consulted resources with the sensitivity of the intended use of the data; inferences of potential medical treatments would likely require different trust than inferences for trip planning. Notation3 is used to express arbitrary application data; security considerations will vary by domain of use. Security tools and protocols applicable to text (e.g. PGP encryption, MD5 sum validation, password-protected compression) may also be used on Notation3 documents. Security/privacy protocols must be imposed which reflect the sensitivity of the embedded information. Notation3 can express data which is presented to the user, for example, RDF Schema labels. Application rendering strings retrieved from untrusted Notation3 documents must ensure that malignant strings may not be used to mislead the reader. The security considerations in the media type registration for XML ([RFC3023] section 10) provide additional guidance around the expression of arbitrary data and markup. Notation3 uses IRIs as term identifiers. Applications interpreting data expressed in Notation3 sould address the security issues of Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7. Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "о" 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 Notation3 must take care to use the IRI that matches the intended semantics, and avoid IRIs that make 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. Interoperability considerations: There are no known interoperability issues. Published specification: http://www.w3.org/TeamSubmission/2011/SUBM-n3-20110314/ Applications which use this media type: No widely deployed applications are known to use this media type. It may be used by some web services and clients consuming their data. Additional information: Magic number(s): Notation3 documents may have the strings '@prefix' or '@base' (case dependent) near the beginning of the document. File extension(s): ".n3" Base URI: The Notation3 '@base ' term can change the current base URI for relative IRIrefs in the query language that are used sequentially later in the document. Macintosh file type code(s): "TEXT" Person & email address to contact for further information: Eric Prud'hommeaux Intended usage: COMMON Restrictions on usage: None Author/Change controller: The Notation3 specification is the product of Tim Berners-Lee. A W3C Working Group may assume maintenance of this document; W3C reserves change control over this specifications. Note, this follows a request for a similar media type text/turtle . -- -ericP Return-Path: X-Original-To: ietf-types@core3.amsl.com Delivered-To: ietf-types@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23803A6AB2 for ; Fri, 11 Mar 2011 15:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neL2o72bD+bS for ; Fri, 11 Mar 2011 15:32:17 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 6B24A3A6AAC for ; Fri, 11 Mar 2011 15:32:17 -0800 (PST) Received: by vxg33 with SMTP id 33so3684222vxg.31 for ; Fri, 11 Mar 2011 15:33:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :mime-version:content-type:content-disposition :content-transfer-encoding:organization:user-agent; bh=ADfnfCWUpsPTG2nxiWsd2usHt7FRwRvc8CX1R50WEfA=; b=Bd6AiZD7UwP4RdNmhQGofPWqXz/9In5xA7MPi01C0UrCN4BOK9jmZmSyFQDRbrSzR0 DBZIx1k/cJKpOMuWVB5bIKW3uGdYhsGgXXLxPGr7gAAMBXbsoorrwD4MrqX/y1/YcuS0 MY7NaY30+NfeVK7p/HG+ZVvLQn4tgiI03sd08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:content-transfer-encoding:organization :user-agent; b=gYs3q0sJQ7erGJ74iLIc2ksIK3TlJyasGVy0jwJtDypkL9Le76zVUWoT8XowthSeIA eGLWcyYPc2x6iPOclrnqQS4R4gvT7J38EQ13zIUC0V0V5+do1Y7Z8KhnP4qsgDM+Bo4y slaZdWpspCHuLcOg2g7H4F4iAcE9+S6EvIz7E= Received: by 10.52.74.106 with SMTP id s10mr4928189vdv.150.1299886416976; Fri, 11 Mar 2011 15:33:36 -0800 (PST) Received: from w3.org (31-34-245.wireless.csail.mit.edu [128.31.34.245]) by mx.google.com with ESMTPS id 8sm1185877vdd.30.2011.03.11.15.33.35 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Mar 2011 15:33:36 -0800 (PST) Sender: "Eric Prud'hommeaux" Date: Fri, 11 Mar 2011 18:33:34 -0500 From: Eric Prud'hommeaux To: ietf-types Message-ID: <20110311233325.GC7042@w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Organization: World Wide Web Consortium (W3C) - http://www.w3.org/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: www-archive@w3.org Subject: [ietf-types] Request for review of Turtle (an RDF serialization) media type: text/turtle X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 23:37:58 -0000 Believing all of the issues in to be resolved, I'd like a review of the media type text/turtle . The Published specification will be , which will be the same as with modifications to the media type sections. Contact: Eric Prud'hommeaux 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 Turtle is "text/turtle". It is recommended that Turtle files have the extension ".ttl" (all lowercase) on all platforms. It is recommended that sparql query files stored on Macintosh HFS file systems be given a file type of "TEXT". This information that follows has been submitted to the IESG for review, approval, and registration with IANA. Type name: text Subtype name: turtle Required parameters: None Optional parameters: charset — this parameter is required when transfering non-ASCII data. If present, the value of charset is always UTF-8. Encoding considerations: The syntax of Turtle is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [RFC3629]. Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F] Security considerations: Turtle is a general-purpose assertion language; applications may evaluate given data to infer more assertions or to dereference URIs, invoking the security considerations of the scheme for that URI. Note in particular, the privacy issues in RFC3023 section 10 for HTTP URIs. Data obtained from an inaccurate or malicious data source may lead to inaccurate or misleading conclusions, as well as the dereferencing of unintended URIs. Care must be taken to align the trust in consulted resources with the sensitivity of the intended use of the data; inferences of potential medical treatments would likely require different trust than inferences for trip planning. Turtle is used to express arbitrary application data; security considerations will vary by domain of use. Security tools and protocols applicable to text (e.g. PGP encryption, MD5 sum validation, password-protected compression) may also be used on Turtle documents. Security/privacy protocols must be imposed which reflect the sensitivity of the embedded information. Turtle can express data which is presented to the user, for example, RDF Schema labels. Application rendering strings retrieved from untrusted Turtle documents must ensure that malignant strings may not be used to mislead the reader. The security considerations in the media type registration for XML ([RFC3023] section 10) provide additional guidance around the expression of arbitrary data and markup. Turtle uses IRIs as term identifiers. Applications interpreting data expressed in Turtle sould address the security issues of Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7. Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "о" 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 Turtle must take care to use the IRI that matches the intended semantics, and avoid IRIs that make 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. Interoperability considerations: There are no known interoperability issues. Published specification: http://www.w3.org/TeamSubmission/2011/SUBM-turtle-20110314/ Applications which use this media type: No widely deployed applications are known to use this media type. It may be used by some web services and clients consuming their data. Additional information: Magic number(s): Turtle documents may have the strings '@prefix' or '@base' (case dependent) near the beginning of the document. File extension(s): ".ttl" Base URI: The Turtle '@base ' term can change the current base URI for relative IRIrefs in the query language that are used sequentially later in the document. Macintosh file type code(s): "TEXT" Person & email address to contact for further information: Eric Prud'hommeaux Intended usage: COMMON Restrictions on usage: None Author/Change controller: The Turtle specification is the product of David Beckett and Tim Berners-Lee. A W3C Working Group may assume maintenance of this document; W3C reserves change control over this specifications. I'll be submitting another form for text/n3 . Boy I hope this is near the end. -- -ericP Return-Path: X-Original-To: ietf-types@core3.amsl.com Delivered-To: ietf-types@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36F13A6B1E for ; Wed, 9 Mar 2011 17:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlYeRq20aGe0 for ; Wed, 9 Mar 2011 17:03:06 -0800 (PST) Received: from pechora6.dc.icann.org (pechora6.icann.org [192.0.46.72]) by core3.amsl.com (Postfix) with ESMTP id 656AE3A6937 for ; Wed, 9 Mar 2011 17:03:06 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pechora6.dc.icann.org (8.13.8/8.13.8) with SMTP id p2A13lhm024393 for ; Wed, 9 Mar 2011 20:04:07 -0500 Received: (qmail invoked by alias); 10 Mar 2011 01:03:45 -0000 Received: from dslb-094-222-129-148.pools.arcor-ip.net (EHLO HIVE) [94.222.129.148] by mail.gmx.net (mp038) with SMTP; 10 Mar 2011 02:03:45 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18p2ZsVxDIpddwLkGtTefwquzsYv/yQjsFx8zYz5t n8FDStwYaju7JE From: Bjoern Hoehrmann To: ietf-types@iana.org Date: Thu, 10 Mar 2011 02:03:46 +0100 Message-ID: References: <4D776889.2010709@isode.com> In-Reply-To: <4D776889.2010709@isode.com> 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-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora6.dc.icann.org [192.0.46.72]); Wed, 09 Mar 2011 20:04:08 -0500 (EST) Subject: Re: [ietf-types] [Fwd: Possible IESG statement on IESG processing of MIME type registrations from other SDOs] X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 01:03:08 -0000 * Alexey Melnikov wrote: >I already have some pending changes on this, but here is the original >version I proposed. >To keep all discussions in one place, please send any comments to >apps-discuss@ietf.org, or directly to me. http://www.ietf.org/mail-archive/web/apps-discuss/current/threads.html#02300 for the thread and https://www.ietf.org/mailman/listinfo/apps-discuss to subscribe if using the web interface. People of the future: sorry about the broken link above, I do not know how to make stable MHonArc links... http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02300.html should be the original message though... -- 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/ Return-Path: X-Original-To: ietf-types@core3.amsl.com Delivered-To: ietf-types@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 546CE3A683E for ; Wed, 9 Mar 2011 08:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnDqoXHpU6Tx for ; Wed, 9 Mar 2011 08:30:38 -0800 (PST) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:1::39]) by core3.amsl.com (Postfix) with ESMTP id 822E63A6881 for ; Wed, 9 Mar 2011 08:30:22 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:144::148]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id p29GVHtM031302 for ; Wed, 9 Mar 2011 08:31:38 -0800 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:208::212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id E92A1BDC18; Thu, 10 Mar 2011 01:03:27 +0900 (JST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id CE02370525; Thu, 10 Mar 2011 01:03:27 +0900 (JST) Message-ID: <4D77A4D2.6060401@nttv6.jp> Date: Thu, 10 Mar 2011 01:03:30 +0900 From: Makoto Saito User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: ietf-types@iana.org Content-Type: multipart/mixed; boundary="------------010104030503070702060007" X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [IPv6:2620:0:2d0:1::39]); Wed, 09 Mar 2011 08:31:38 -0800 (PST) Cc: Masashi TOYAMA , Dan Wing Subject: [ietf-types] Registration of media type application/ike-esp X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 16:30:39 -0000 This is a multi-part message in MIME format. --------------010104030503070702060007 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Dear Administrators, I'd like to register a media subtype application/ike-esp from draft-saito-mmusic-sdp-ike. The template is attached. Let me know if I'm missing something to do. Best regards, Makoto --------------010104030503070702060007 Content-Type: text/plain; name="mime subtype ike-esp registration.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mime subtype ike-esp registration.txt" ICAgVG86IGlldGYtdHlwZXNAaWFuYS5vcmcNCiAgIFN1YmplY3Q6IFJlZ2lzdHJhdGlvbiBv ZiBtZWRpYSB0eXBlIGFwcGxpY2F0aW9uL2lrZS1lc3ANCg0KICAgVHlwZSBuYW1lOg0KDQog ICAgICAgIGFwcGxpY2F0aW9uDQoNCiAgIFN1YnR5cGUgbmFtZToNCg0KICAgICAgICBTdGFu ZGFyZHMgdHJlZSAtIGlrZS1lc3ANCg0KICAgUmVxdWlyZWQgcGFyYW1ldGVyczoNCg0KICAg ICAgICBObyBwYXJhbWV0ZXJzDQoNCiAgIE9wdGlvbmFsIHBhcmFtZXRlcnM6DQoNCiAgICAg ICAgTm8gcGFyYW1ldGVycw0KDQogICBFbmNvZGluZyBjb25zaWRlcmF0aW9uczoNCg0KICAg ICAgICBiaW5hcnkgKHRoaXMgbWVkaWEgdHlwZSBtYXkgcmVxdWlyZSBlbmNvZGluZyBvbiB0 cmFuc3BvcnRzIG5vdCBjYXBhYmxlIG9mIGhhbmRsaW5nIGJpbmFyeSkNCg0KICAgU2VjdXJp dHkgY29uc2lkZXJhdGlvbnM6DQoNCiAgICAgICAgVGhlIHNhbWUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgYXBwbHkgYXMgZm9yIHRoZSBJS0UgcHJvdG9jb2wsDQogICAgICAgIHdoaWNo IGlzIHNwZWNpZmllZCBpbiBSRkM1OTk2IC1JbnRlcm5ldCBLZXkgRXhjaGFuZ2UgUHJvdG9j b2wgVmVyc2lvbiAyIChJS0V2MikuDQoNCiAgIEludGVyb3BlcmFiaWxpdHkgY29uc2lkZXJh dGlvbnM6DQoNCiAgICAgICAgSW50ZXJvcGVyYWJpbGl0eSBvZiB0aGUgSUtFIGlzIHNwZWNp ZmllZCBpbiBSRkM1OTk2IC1JbnRlcm5ldCBLZXkgRXhjaGFuZ2UgUHJvdG9jb2wgVmVyc2lv biAyIChJS0V2MikuDQoNCiAgIFB1Ymxpc2hlZCBzcGVjaWZpY2F0aW9uOg0KDQogICAgICAg IFJGQzU5OTYgLUludGVybmV0IEtleSBFeGNoYW5nZSBQcm90b2NvbCBWZXJzaW9uIDIgKElL RXYyKQ0KICAgICAgICBkcmFmdC1zYWl0by1tbXVzaWMtc2RwLWlrZSAtTWVkaWEgRGVzY3Jp cHRpb24gZm9yIElLRSBpbiB0aGUgU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQ KQ0KDQogICBBcHBsaWNhdGlvbnMgdGhhdCB1c2UgdGhpcyBtZWRpYSB0eXBlOg0KDQogICAg ICAgIFRoZSBpa2UtZXNwIG1lZGlhIHR5cGUgaW5kaWNhdGVzIGEgc2VxdWVuY2Ugb2YgSUtF IHBhY2tldHMgd2hpY2ggc2V0cyB1cCBhbiBJUHNlYyBFU1Agc2Vzc2lvbi4NCiAgICAgICAg QW4gSUtFIGNvbnRyb2wgY2hhbm5lbCBpcyBpbml0aWF0ZWQgdXNpbmcgU0lQIGFuZCBTRFAg b2ZmZXIvYW5zd2VyIG1vZGVsLg0KDQogICBBZGRpdGlvbmFsIGluZm9ybWF0aW9uOg0KDQog ICAgIE1hZ2ljIG51bWJlcihzKToNCg0KICAgICAgICBUaGVyZSBpcyBubyBzaW5nbGUgc3Ry aW5nIHRoYXQgaXMgYWx3YXlzIHByZXNlbnQuDQoNCiAgICAgRmlsZSBleHRlbnNpb24ocyk6 DQoNCiAgICAgICAgTm8gc3BlY2lmaWMgZmlsZSBleHRlbnNpb24gaXMgcmVjb21tZW5kZWQg Zm9yIHRoaXMgdHlwZS4NCg0KICAgICBNYWNpbnRvc2ggZmlsZSB0eXBlIGNvZGUocyk6DQoN CiAgICAgICAgTm8gc3BlY2lmaWMgTWFjaW50b3NoIGZpbGUgdHlwZSBjb2RlcyBhcmUgcmVj b21tZW5kZWQNCiAgICAgICAgZm9yIHRoaXMgdHlwZS4NCg0KICAgICBPYmplY3QgSWRlbnRp ZmllcihzKToNCg0KICAgICAgICBObyBzcGVjaWZpYyBvYmplY3QgaWRlbnRpZmllciBpcyBk ZWZpbmVkLg0KDQogICBQZXJzb24gJiBlbWFpbCBhZGRyZXNzIHRvIGNvbnRhY3QgZm9yIGZ1 cnRoZXIgaW5mb3JtYXRpb246DQoNCiAgICAgTmFtZToNCg0KICAgICAgICBNYWtvdG8gU2Fp dG8NCg0KICAgICBFLW1haWw6DQoNCiAgICAgICAgbWEuc2FpdG9AbnR0djYuanANCg0KICAg SW50ZW5kZWQgdXNhZ2U6DQoNCiAgICAgICAgQ09NTU9ODQoNCiAgIFJlc3RyaWN0aW9ucyBv biB1c2FnZToNCg0KICAgICAgICBObyByZXN0cmljdGlvbnMgYXBwbHkuDQoNCiAgIEF1dGhv cnM6DQoNCiAgICAgICAgTWFrb3RvIFNhaXRvIChtYS5zYWl0b0BudHR2Ni5qcCkNCiAgICAg ICAgRGFuIFdpbmcgKGR3aW5nQGNpc2NvLmNvbSkNCiAgICAgICAgTWFzYXNoaSBUb3lhbWEg KHRveWFtYS5tYXNhc2hpQGxhYi5udHQuY28uanApDQoNCiAgIENoYW5nZSBjb250cm9sbGVy Og0KDQogICAgICAgIElFU0cNCg== --------------010104030503070702060007-- Return-Path: X-Original-To: ietf-types@core3.amsl.com Delivered-To: ietf-types@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79CBE3A683E for ; Wed, 9 Mar 2011 08:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kw7sTbuertDY for ; Wed, 9 Mar 2011 08:20:22 -0800 (PST) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:1::39]) by core3.amsl.com (Postfix) with ESMTP id 42A5D3A6859 for ; Wed, 9 Mar 2011 08:20:21 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:144::148]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id p29GLGp8030797 for ; Wed, 9 Mar 2011 08:21:36 -0800 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:208::212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 8A91CBDC20; Thu, 10 Mar 2011 01:04:53 +0900 (JST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 64CD270525; Thu, 10 Mar 2011 01:04:53 +0900 (JST) Message-ID: <4D77A528.7010901@nttv6.jp> Date: Thu, 10 Mar 2011 01:04:56 +0900 From: Makoto Saito User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: ietf-types@iana.org Content-Type: multipart/mixed; boundary="------------070305060909020502020408" X-Greylist: Delayed for 00:17:42 by milter-greylist-4.0 (pechora4.lax.icann.org [IPv6:2620:0:2d0:1::39]); Wed, 09 Mar 2011 08:21:37 -0800 (PST) X-Mailman-Approved-At: Wed, 09 Mar 2011 08:26:27 -0800 Cc: Masashi TOYAMA , Dan Wing Subject: [ietf-types] Registration of media type application/ike-esp-udpencap X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 16:20:23 -0000 This is a multi-part message in MIME format. --------------070305060909020502020408 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Dear Administrators, I'd like to register a media subtype application/ike-esp-udpencap from draft-saito-mmusic-sdp-ike. The template is attached. Let me know if I'm missing something to do. Best regards, Makoto --------------070305060909020502020408 Content-Type: text/plain; name="mime subtype ike-esp-udpencap registration.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mime subtype ike-esp-udpencap registration.txt" ICAgVG86IGlldGYtdHlwZXNAaWFuYS5vcmcNCiAgIFN1YmplY3Q6IFJlZ2lzdHJhdGlvbiBv ZiBtZWRpYSB0eXBlIGFwcGxpY2F0aW9uL2lrZS1lc3AtdWRwZW5jYXANCg0KICAgVHlwZSBu YW1lOg0KDQogICAgICAgIGFwcGxpY2F0aW9uDQoNCiAgIFN1YnR5cGUgbmFtZToNCg0KICAg ICAgICBTdGFuZGFyZHMgdHJlZSAtIGlrZS1lc3AtdWRwZW5jYXANCg0KICAgUmVxdWlyZWQg cGFyYW1ldGVyczoNCg0KICAgICAgICBObyBwYXJhbWV0ZXJzDQoNCiAgIE9wdGlvbmFsIHBh cmFtZXRlcnM6DQoNCiAgICAgICAgTm8gcGFyYW1ldGVycw0KDQogICBFbmNvZGluZyBjb25z aWRlcmF0aW9uczoNCg0KICAgICAgICBiaW5hcnkgKHRoaXMgbWVkaWEgdHlwZSBtYXkgcmVx dWlyZSBlbmNvZGluZyBvbiB0cmFuc3BvcnRzIG5vdCBjYXBhYmxlIG9mIGhhbmRsaW5nIGJp bmFyeSkNCg0KICAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6DQoNCiAgICAgICAgVGhlIHNh bWUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYXBwbHkgYXMgZm9yIHRoZSBJS0UgcHJvdG9j b2wsDQogICAgICAgIHdoaWNoIGlzIHNwZWNpZmllZCBpbiBSRkM1OTk2IC1JbnRlcm5ldCBL ZXkgRXhjaGFuZ2UgUHJvdG9jb2wgVmVyc2lvbiAyIChJS0V2MikuDQoNCiAgIEludGVyb3Bl cmFiaWxpdHkgY29uc2lkZXJhdGlvbnM6DQoNCiAgICAgICAgSW50ZXJvcGVyYWJpbGl0eSBv ZiB0aGUgSUtFIGlzIHNwZWNpZmllZCBpbiBSRkM1OTk2IC1JbnRlcm5ldCBLZXkgRXhjaGFu Z2UgUHJvdG9jb2wgVmVyc2lvbiAyIChJS0V2MikuDQoNCiAgIFB1Ymxpc2hlZCBzcGVjaWZp Y2F0aW9uOg0KDQogICAgICAgIFJGQzU5OTYgLUludGVybmV0IEtleSBFeGNoYW5nZSBQcm90 b2NvbCBWZXJzaW9uIDIgKElLRXYyKQ0KICAgICAgICBkcmFmdC1zYWl0by1tbXVzaWMtc2Rw LWlrZSAtTWVkaWEgRGVzY3JpcHRpb24gZm9yIElLRSBpbiB0aGUgU2Vzc2lvbiBEZXNjcmlw dGlvbiBQcm90b2NvbCAoU0RQKQ0KDQogICBBcHBsaWNhdGlvbnMgdGhhdCB1c2UgdGhpcyBt ZWRpYSB0eXBlOg0KDQogICAgICAgIFRoZSBpa2UtZXNwLXVkcGVuY2FwIG1lZGlhIHR5cGUg aW5kaWNhdGVzIGEgc2VxdWVuY2Ugb2YgSUtFIHBhY2tldHMgd2hpY2ggc3VwcG9ydHMgTkFU LVRyYXZlcnNhbA0KICAgICAgICBhbmQgc2V0cyB1cCBhbiBJUHNlYyBFU1Agc2Vzc2lvbiBv ciBhIFVEUCBlbmNhcHN1bGF0aW9uIG9mIElQc2VjIEVTUCBzZXNzaW9uLCB1c2luZyBwcm9j ZWR1cmVzDQogICAgICAgIGRlc2NyaWJlZCBpbiBSRkMzOTQ3Lg0KICAgICAgICBBbiBJS0Ug Y29udHJvbCBjaGFubmVsIGlzIGluaXRpYXRlZCB1c2luZyBTSVAgYW5kIFNEUCBvZmZlci9h bnN3ZXIgbW9kZWwuDQoNCiAgIEFkZGl0aW9uYWwgaW5mb3JtYXRpb246DQoNCiAgICAgTWFn aWMgbnVtYmVyKHMpOg0KDQogICAgICAgIFRoZXJlIGlzIG5vIHNpbmdsZSBzdHJpbmcgdGhh dCBpcyBhbHdheXMgcHJlc2VudC4NCg0KICAgICBGaWxlIGV4dGVuc2lvbihzKToNCg0KICAg ICAgICBObyBzcGVjaWZpYyBmaWxlIGV4dGVuc2lvbiBpcyByZWNvbW1lbmRlZCBmb3IgdGhp cyB0eXBlLg0KDQogICAgIE1hY2ludG9zaCBmaWxlIHR5cGUgY29kZShzKToNCg0KICAgICAg ICBObyBzcGVjaWZpYyBNYWNpbnRvc2ggZmlsZSB0eXBlIGNvZGVzIGFyZSByZWNvbW1lbmRl ZA0KICAgICAgICBmb3IgdGhpcyB0eXBlLg0KDQogICAgIE9iamVjdCBJZGVudGlmaWVyKHMp Og0KDQogICAgICAgIE5vIHNwZWNpZmljIG9iamVjdCBpZGVudGlmaWVyIGlzIGRlZmluZWQu DQoNCiAgIFBlcnNvbiAmIGVtYWlsIGFkZHJlc3MgdG8gY29udGFjdCBmb3IgZnVydGhlciBp bmZvcm1hdGlvbjoNCg0KICAgICBOYW1lOg0KDQogICAgICAgIE1ha290byBTYWl0bw0KDQog ICAgIEUtbWFpbDoNCg0KICAgICAgICBtYS5zYWl0b0BudHR2Ni5qcA0KDQogICBJbnRlbmRl ZCB1c2FnZToNCg0KICAgICAgICBDT01NT04NCg0KICAgUmVzdHJpY3Rpb25zIG9uIHVzYWdl Og0KDQogICAgICAgIE5vIHJlc3RyaWN0aW9ucyBhcHBseS4NCg0KICAgQXV0aG9yczoNCg0K ICAgICAgICBNYWtvdG8gU2FpdG8gKG1hLnNhaXRvQG50dHY2LmpwKQ0KICAgICAgICBEYW4g V2luZyAoZHdpbmdAY2lzY28uY29tKQ0KICAgICAgICBNYXNhc2hpIFRveWFtYSAodG95YW1h Lm1hc2FzaGlAbGFiLm50dC5jby5qcCkNCg0KICAgQ2hhbmdlIGNvbnRyb2xsZXI6DQoNCiAg ICAgICAgSUVTRw0K --------------070305060909020502020408-- Return-Path: X-Original-To: ietf-types@core3.amsl.com Delivered-To: ietf-types@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92103A6948 for ; Wed, 9 Mar 2011 03:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL9Pk2LJ5JKB for ; Wed, 9 Mar 2011 03:46:26 -0800 (PST) Received: from pechora1.lax.icann.org (pechora1.icann.org [208.77.188.36]) by core3.amsl.com (Postfix) with ESMTP id CAAB33A684A for ; Wed, 9 Mar 2011 03:46:26 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id p29Bl7ib008625 for ; Wed, 9 Mar 2011 03:47:27 -0800 Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 9 Mar 2011 11:47:05 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D776889.2010709@isode.com> Date: Wed, 09 Mar 2011 11:46:17 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ietf-types@iana.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------050907050905070900080906" X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [208.77.188.36]); Wed, 09 Mar 2011 03:47:28 -0800 (PST) Subject: [ietf-types] [Fwd: Possible IESG statement on IESG processing of MIME type registrations from other SDOs] X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 11:46:27 -0000 This is a multi-part message in MIME format. --------------050907050905070900080906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I already have some pending changes on this, but here is the original version I proposed. To keep all discussions in one place, please send any comments to apps-discuss@ietf.org, or directly to me. Thanks, Alexey -- IETF Application Area Director, Internet Messaging Team Lead, JID: same as my email address --------------050907050905070900080906 Content-Type: message/rfc822; name="Possible IESG statement on IESG processing of MIME type registrationsfrom other SDOs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Possible IESG statement on IESG processing of MIME type registrationsfrom other SDOs" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine.isode.net (Isode M-Box/14.6a5) with LMTP; Thu, 03 Mar 2011 16:15:04 +0000 (GMT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 3 Mar 2011 16:15:03 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D6FBE4D.10602@isode.com> Date: Thu, 03 Mar 2011 16:14:05 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org Subject: Possible IESG statement on IESG processing of MIME type registrations from other SDOs MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I am working with the rest of IESG on issuing the following IESG statement: ------------------------ BCP 13 (currently RFC 4288) specifies that Media Type registrations from other Standards Organizations (SDOs) can be submitted directly to IESG for approval, without a need to submit an Internet Draft and to ask an Area Director to shepherd its publication. While this IESG statement doesn't change that, IESG would like to encourage other SDOs to submit their registriation as Internet Drafts, as this tends to improve quality of final registrations, and sometimes even improves quality of the underlying format itself. IESG would also like to remind that as per BCP 13, other SDOs are not excluded from the requirement to post their Media Type registrations for 2 weeks review on the ietf-types@iana.org mailing list. When reviewing Media Type registrations IESG checks that the Media Type registration template is correct and reasonably complete. When reviewing Media Type registrations (including those from other SDOs) IESG also checks that references to documents describing details of the Media Type format are stable, i.e. - a) the references are reasonably long lived and - b1) the document pointed to by the reference is either immutable (i.e. if an updated document is approved for publication by the SDO, then it will be posted at a different URI) or can only change in insignificant ways (e.g. to correct typos, clarify text without changing the media type format, etc.) - b2) the media type format contains some internal fields for versioning that can be used to distingiush 2 incompatible versions of the Media Type format - b3) there is some guaranty that future revisions of the format are going to be backward compatible Note that the choices b1, b2 and b3 are not mutually exclusive. If the Media Type format specification has licensing restrictions, the Internet Assigned Numbers Authority (IANA) must be granted express permission to make archival copies of the Media Type format specification, and to redistribute such a copy in the event that the link to the format specification becomes inoperative and it is determined that it will not be repaired. ------------------------ Please let me know if you have any corrections or major objections to this before March 17th. Thanks, Alexey --------------050907050905070900080906--