Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS
From: Brian Clubb <[email-masked]>
To: Paul Libbrecht <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Mon, 21 Mar 2011 20:27:12 +0000
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>

No worries!  I appreciate the feedback!

Here is the corrected template:
Name : Brian Clubb

Email : [email-masked]

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 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 provided as part of the OpenXPS format.  The consumer must ensure that no malicious 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/Ecma-388.htm)

Also see section E.3 of ECMA-388 specification (http://www.ecma-international.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. Implementations may use the 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 §9.2 of the Open Packaging Conventions  

b. First four bytes correspond to the local file header signature defined in 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 required by §8.3.4 of the Open Packaging Conventions b. Check that the content type for the package relationships zip item is correctly defined in the Content Types stream (see OPC §8.1.2) as a relationships part 3. Test that the Package Relationships Part contains a relationship (see OPC §8.3) whose Target attribute points to a valid FixedDocumentSequence Part a. As required by §10.2 of this Standard b. Check that the content type for the FixedDocumentSequence 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 content cannot directly produce/consume OpenXPS.  Changes are required to address differences in the two specifications, such as namespace, print ticket usage, 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 can currently produce/consume Microsoft XPS to also adopt OpenXPS.  Examples of such applications would include but are not limited to:  Microsoft XPS Viewer, Microsoft XPS Document Writer, Microsoft Internet Explorer 9.

Additional information :

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 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
[email-masked]

Person to contact for further information :

1. Name : Ecma International Helpdesk
2. Email : [email-masked]

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:[email-masked]] 
Sent: Monday, March 21, 2011 1:25 PM
To: Brian Clubb
Cc: [email-masked]
Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS

Thank you Brian,

Le 16 mars 2011 à 21:14, Brian Clubb a écrit :

> 3. Macintosh file type code : org.ecma.oxps conforms to com.pkware.zip-archive
> 

should read:

3. Macintosh uniform type identifier : org.ecma.oxps conforms to com.pkware.zip-archive

I promise this is my last word.. ;-).

paul

From: Paul Libbrecht <[email-masked]>
Date: Mon, 21 Mar 2011 21:25:05 +0100
To: Brian Clubb <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS

Thank you Brian,

Le 16 mars 2011 à 21:14, Brian Clubb a écrit :

> 3. Macintosh file type code : org.ecma.oxps conforms to com.pkware.zip-archive
> 

should read:

3. Macintosh uniform type identifier : org.ecma.oxps conforms to com.pkware.zip-archive

I promise this is my last word.. ;-).

paul

From: Brian Clubb <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 16 Mar 2011 20:14:40 +0000
Accept-Language: en-US
Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS

--_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 template.  Having received no further feedback, I am making a "Last Call" request for comment before sending this on.

Thanks!
Brian

TEMPLATE:

Name : Brian Clubb

Email : [email-masked]

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 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 provided as part of the OpenXPS format.  The consumer must ensure that no malicious 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/Ecma-388.htm)

Also see section E.3 of ECMA-388 specification (http://www.ecma-international.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. Implementations may use the 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 §9.2 of the Open Packaging Conventions

b. First four bytes correspond to the local file header signature defined in 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 required by §8.3.4 of the Open Packaging Conventions b. Check that the content type for the package relationships zip item is correctly defined in the Content Types stream (see OPC §8.1.2) as a relationships part 3. Test that the Package Relationships Part contains a relationship (see OPC §8.3) whose Target attribute points to a valid FixedDocumentSequence Part a. As required by §10.2 of this Standard b. Check that the content type for the FixedDocumentSequence 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 content cannot directly produce/consume OpenXPS.  Changes are required to address differences in the two specifications, such as namespace, print ticket usage, 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 can currently produce/consume Microsoft XPS to also adopt OpenXPS.  Examples of such applications would include but are not limited to:  Microsoft XPS Viewer, Microsoft XPS Document Writer, Microsoft Internet Explorer 9.

Additional information :

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 type code : 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
[email-masked]

Person to contact for further information :

1. Name : Ecma International Helpdesk
2. Email : [email-masked]

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

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">I received some feedback directly that did not include the mailing list.&nbsp; I have verified the feedback and updated the &#8220;Magic Number&#8221; section in the template.&nbsp; Having received no further feedback, I am making a &#8220;Last Call&#8221; request for comment
 before sending this on.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Thanks!<o:p></o:p></p>
<p class="MsoNormal">Brian<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">TEMPLATE:<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Name : Brian Clubb<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Email : [email-masked]<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">MIME media type name : application<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">MIME subtype name : Standards Tree &#8211; openxps<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Required parameters : N/A<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Optional parameters :<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">N/A<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Encoding considerations : 8-bit<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Security considerations :<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">OpenXPS uses ZIP compression as specified in .ZIP File Format Specification from PKWARE, Inc., version 6.2.0 (2004).&nbsp; ZIP compressed XML requires parsing untrusted XML data and untrusted ZIP data.&nbsp; consumer
 is responsible for validating the .zip archive, the XML structure, and the resource content.&nbsp; Per spec, there should be no active content provided as part of the OpenXPS format.&nbsp; The consumer must ensure that no malicious active content is erroneously provided
 in the OpenXPS document.&nbsp; Valid content is described in the EMCA-388 specification (http://www.ecma-international.org/publications/standards/Ecma-388.htm)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Also see section E.3 of ECMA-388 specification (http://www.ecma-international.org/publications/standards/Ecma-388.htm)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">OpenXPS Documents follow requirements set out in this Standard, as well as other normative references including the Open Packaging Conventions. Implementations may use the 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 §9.2 of the Open Packaging Conventions&nbsp;
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">b. First four bytes correspond to the local file header signature defined in the .ZIP File Format Specification from PKWARE, Inc., version 6.2.0 (2004)&nbsp; 2. Test that a valid Package Relationships zip item
 exists a. As required by §8.3.4 of the Open Packaging Conventions b. Check that the content type for the package relationships zip item is correctly defined in the Content Types stream (see OPC §8.1.2) as a relationships part 3. Test that the Package Relationships
 Part contains a relationship (see OPC §8.3) whose Target attribute points to a valid FixedDocumentSequence Part a. As required by §10.2 of this Standard b. Check that the content type for the FixedDocumentSequence part is correctly defined in the Content Types
 stream as a FixedDocumentSequence part <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Interoperability considerations :<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">application/OpenXPS documents are specified by the XML schemas<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">&nbsp;&nbsp; standardized in ECMA-388.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Applications and drivers currently producing/consuming Microsoft XPS content cannot directly produce/consume OpenXPS.&nbsp; Changes are required to address differences in the two specifications, such as namespace,
 print ticket usage, use of JPEG XR, etc.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Published specification :<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">The published Standard ECMA-388 is available at:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">http://www.ecma-international.org/publications/standards/Ecma-388.htm<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Applications which use this media :<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">The application/oxps MIME type can be used to identify CSTA XML<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">(ECMA-388) instance documents.&nbsp; No published applications or print drivers currently use OpenXPS.&nbsp; The intent is for any application or driver that can currently produce/consume Microsoft XPS to also adopt
 OpenXPS.&nbsp; Examples of such applications would include but are not limited to:&nbsp; Microsoft XPS Viewer, Microsoft XPS Document Writer, Microsoft Internet Explorer 9.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Additional information :<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">1. Magic number(s) : ZIP archive CRC-32: 504b 0304 per http://www.pkware.com/documents/APPNOTE/APPNOTE-6.2.0.txt.&nbsp; Note that is it a requirement of the consumer to ensure that the contents of the ZIP archive
 is a valid OpenXPS structure.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">2. File extension(s) : .oxps<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">3. Macintosh file type code : org.ecma.oxps conforms to com.pkware.zip-archive<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">4. Object Identifiers: N/A<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">5. Windows clipboard name:&nbsp; &quot;OpenXPS&quot;<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">To ensure interoperability, the clipboard format must be a complete OpenXPS file with .oxps extension.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Person &amp; email address to contact for further information:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Ecma International Helpdesk<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Rue du Rhone114<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">CH-1204 Geneva<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Switzerland<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">[email-masked]<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Person to contact for further information :<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">1. Name : Ecma International Helpdesk<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">2. Email : [email-masked]<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Intended usage : Common<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">This type will be used for all documents conforming to the Open XML<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">&nbsp;&nbsp; Paper Specifcation's (ECMA-388) Open XPS Document format, published<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">&nbsp;&nbsp; by ECMA.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Author/Change controller : The ECMA-388 Standard is developed and<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">&nbsp;&nbsp; maintained by the Ecma TC46 Working Group.<o:p></o:p></span></p>
</div>
</body>
</html>

--_000_FE6603D65048F44AB8F8955AE89A09B9172CEF73TK5EX14MBXW652w_--

Sender: "Eric Prud'hommeaux" <[email-masked]>
Date: Sat, 12 Mar 2011 08:46:57 -0500
From: Eric Prud'hommeaux <[email-masked]>
To: Nathan <[email-masked]>
Organization: World Wide Web Consortium (W3C) - http://www.w3.org/
Cc: ietf-types <[email-masked]>
Subject: Re: [ietf-types] Request for review of text/{turtle,n3}

--azLHFNyN32YCQGCU
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

* Nathan <[email-masked]> [2011-03-12 00:26+0000]
> possible bugs..

tx for vigilance

> Eric Prud'hommeaux wrote:
> >Believing all of the issues in
> ><http://www.w3.org/2008/01/rdf-media-types> to be resolved, I'd like a
> >review of the media type text/turtle . The Published specification
> >will be <http://www.w3.org/TeamSubmission/2011/SUBM-turtle-20110314/>,
> >which will be the same as
> ><http://www.w3.org/TeamSubmission/2008/SUBM-turtle-20080114/> 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 <[email-masked]> [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 <IRIref>' 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 <[email-masked]>
> >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 <IRIref>' 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 <[email-masked]>
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 <IRIref>' 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 <[email-masked]>
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--

Sender: "Eric Prud'hommeaux" <[email-masked]>
Date: Sat, 12 Mar 2011 07:50:29 -0500
From: Eric Prud'hommeaux <[email-masked]>
To: ietf-types <[email-masked]>
Organization: World Wide Web Consortium (W3C) - http://www.w3.org/
Cc: [email-masked]
Subject: [ietf-types] minor editorial correction in text/n3 review request type: text/n3

* Eric Prud'hommeaux <[email-masked]> [2011-03-11 18:36-0500]
> Believing all of the issues in
> <http://www.w3.org/2008/01/rdf-media-types> to be resolved, I'd like a
> review of the media type text/n3 . The Published specification
> will be <http://www.w3.org/TeamSubmission/2011/SUBM-n3-20110314/>,
> which will be the same as
> <http://www.w3.org/TeamSubmission/2008/SUBM-n3-20080114/> 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 <IRIref>' 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 <[email-masked]>
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

Sender: "Eric Prud'hommeaux" <[email-masked]>
Date: Sat, 12 Mar 2011 07:49:16 -0500
From: Eric Prud'hommeaux <[email-masked]>
To: ietf-types <[email-masked]>
Organization: World Wide Web Consortium (W3C) - http://www.w3.org/
Cc: [email-masked]
Subject: [ietf-types] minor editorial correction in text/turtle review request

updated to fix a pasto:
  s/sparql query files/Turtle files/

* Eric Prud'hommeaux <[email-masked]> [2011-03-11 18:33-0500]
> Believing all of the issues in
> <http://www.w3.org/2008/01/rdf-media-types> to be resolved, I'd like a
> review of the media type text/turtle . The Published specification
> will be <http://www.w3.org/TeamSubmission/2011/SUBM-turtle-20110314/>,
> which will be the same as
> <http://www.w3.org/TeamSubmission/2008/SUBM-turtle-20080114/> 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 <IRIref>' 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 <[email-masked]>
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

Sender: "Eric Prud'hommeaux" <[email-masked]>
Date: Fri, 11 Mar 2011 18:36:46 -0500
From: Eric Prud'hommeaux <[email-masked]>
To: ietf-types <[email-masked]>
Organization: World Wide Web Consortium (W3C) - http://www.w3.org/
Cc: [email-masked]
Subject: [ietf-types] Request for review of Notation3 (an RDF serialization) media type: text/n3

Believing all of the issues in
<http://www.w3.org/2008/01/rdf-media-types> to be resolved, I'd like a
review of the media type text/n3 . The Published specification
will be <http://www.w3.org/TeamSubmission/2011/SUBM-n3-20110314/>,
which will be the same as
<http://www.w3.org/TeamSubmission/2008/SUBM-n3-20080114/> 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 <IRIref>' 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 <[email-masked]>
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

Sender: "Eric Prud'hommeaux" <[email-masked]>
Date: Fri, 11 Mar 2011 18:33:34 -0500
From: Eric Prud'hommeaux <[email-masked]>
To: ietf-types <[email-masked]>
Organization: World Wide Web Consortium (W3C) - http://www.w3.org/
Cc: [email-masked]
Subject: [ietf-types] Request for review of Turtle (an RDF serialization) media type: text/turtle

Believing all of the issues in
<http://www.w3.org/2008/01/rdf-media-types> to be resolved, I'd like a
review of the media type text/turtle . The Published specification
will be <http://www.w3.org/TeamSubmission/2011/SUBM-turtle-20110314/>,
which will be the same as
<http://www.w3.org/TeamSubmission/2008/SUBM-turtle-20080114/> 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 <IRIref>' 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 <[email-masked]>
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

From: Bjoern Hoehrmann <[email-masked]>
To: [email-masked]
Date: Thu, 10 Mar 2011 02:03:46 +0100
Subject: Re: [ietf-types] [Fwd: Possible IESG statement on IESG processing of MIME type registrations from other SDOs]

* 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 
>[email-masked], 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:[email-masked] · 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/ 

Date: Thu, 10 Mar 2011 01:03:30 +0900
From: Makoto Saito <[email-masked]>
To: [email-masked]
Cc: Masashi TOYAMA <[email-masked]>, Dan Wing <[email-masked]>
Subject: [ietf-types] Registration of media type application/ike-esp

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"

--------------010104030503070702060007--

Date: Thu, 10 Mar 2011 01:04:56 +0900
From: Makoto Saito <[email-masked]>
To: [email-masked]
Cc: Masashi TOYAMA <[email-masked]>, Dan Wing <[email-masked]>
Subject: [ietf-types] Registration of media type application/ike-esp-udpencap

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"

--------------070305060909020502020408--

Date: Wed, 09 Mar 2011 11:46:17 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [ietf-types] [Fwd: Possible IESG statement on IESG processing of MIME type registrations from other SDOs]

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 
[email-masked], or directly to me.

Thanks,
Alexey

-- 
IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
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"

Date: Thu, 03 Mar 2011 16:14:05 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Possible IESG statement on IESG processing of MIME type
         registrations from other SDOs

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 [email-masked] 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--