Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json
From: Jan Algermissen <[email-masked]>
To: Ben Longden <[email-masked]>
Cc: [email-masked]
Date: Sun, 29 Apr 2012 22:55:24 +0200
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>

On Apr 29, 2012, at 3:06 PM, Ben Longden wrote:

> Hi Jan,
> 
> On 29 Apr 2012, at 01:29, Jan Algermissen wrote:
> 
>> E.g. instead of having some "Order does not exist error" design an 'order' resource semantic and use 404. There is no error condition that you cannot express that way, in terms of the uniform interface that HTTP provides.
> 
> Yes and in that situation (Order does not exist), 404 would be the correct response. What if you POST an order for an item, however there is a validation error that prevents the request from being processed. I'd return a 422, perhaps with a text/plain response containing a simple error message. The problem is that without any extra semantics, I cannot for example link to a document that explains what the correct parameters are (accepted values etc), or identify which field contained the error message along side the human readable error.

Ah - I see. Thanks for clarifying. I really thought you meant to use id for the kind of error. Sorry for misunderstanding.

> 
>>> Even your example below is doing that.
>> 
>> How so?
>> 
>>> If you have a web api's then you *must* communicate using media types over HTTP. In the case of a web client, adopting this proposed standard means this is understood and disparate clients can understand the same message.
>> 
>> The uniformity of HTTPs applies to the visibility components have in the *absence* of understanding the entity media types. A cache or monitoring intermediary can take action upon a 404, they cannot do that upon e.g. your proposed id="" attribute.
> 
> Agreed. I'm not advocating this as a replacement to the status code header. The id attribute is for carrying the specific reference to an error log entry on the server. This could be a URL (and perhaps should be a link with a defined rel in the spec, since out of bands information would be required to do anything with it!), but could be a database id with more specific information.

URL sounds best. But I'll take a look at the issue from the 'new' angle. Might not be until Tuesday though.

Again, sorry for the confusion.

Jan

> 
>>> 
>>> If I just use text/plain then I run into problems when I want to represent anything other than just the message (i.e, the id), and then have a requirement for a media type that can represent it.
>> 
>> Hmm, but it is exactly the error-id that I am arguing against :-)
> 
> Does that still hold true now that I have explained how I intended the id to be used? Perhaps changing this to a link with rel='service' (http://www.iana.org/assignments/link-relations/link-relations.xml) would make more sense.
> 
> Ben.
> 
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

From: Ben Longden <[email-masked]>
Date: Sun, 29 Apr 2012 14:10:08 +0100
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json

On 29 Apr 2012, at 02:50, Bjoern Hoehrmann wrote:

> * Ben Longden wrote:
>>  Optional parameters: charset (matching the specification for text/xml)
> 
> This should say `application/xml`.

Yes it should. Amended. Thank you.

Ben

From: Ben Longden <[email-masked]>
Date: Sun, 29 Apr 2012 14:06:19 +0100
To: Jan Algermissen <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json

--Apple-Mail=_12E56E8E-E1A7-4A96-901D-2F7462E3BF05
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Jan,

On 29 Apr 2012, at 01:29, Jan Algermissen wrote:

> E.g. instead of having some "Order does not exist error" design an 'order' resource semantic and use 404. There is no error condition that you cannot express that way, in terms of the uniform interface that HTTP provides.

Yes and in that situation (Order does not exist), 404 would be the correct response. What if you POST an order for an item, however there is a validation error that prevents the request from being processed. I'd return a 422, perhaps with a text/plain response containing a simple error message. The problem is that without any extra semantics, I cannot for example link to a document that explains what the correct parameters are (accepted values etc), or identify which field contained the error message along side the human readable error.

>> Even your example below is doing that.
> 
> How so?
> 
>> If you have a web api's then you *must* communicate using media types over HTTP. In the case of a web client, adopting this proposed standard means this is understood and disparate clients can understand the same message.
> 
> The uniformity of HTTPs applies to the visibility components have in the *absence* of understanding the entity media types. A cache or monitoring intermediary can take action upon a 404, they cannot do that upon e.g. your proposed id="" attribute.

Agreed. I'm not advocating this as a replacement to the status code header. The id attribute is for carrying the specific reference to an error log entry on the server. This could be a URL (and perhaps should be a link with a defined rel in the spec, since out of bands information would be required to do anything with it!), but could be a database id with more specific information.

>> 
>> If I just use text/plain then I run into problems when I want to represent anything other than just the message (i.e, the id), and then have a requirement for a media type that can represent it.
> 
> Hmm, but it is exactly the error-id that I am arguing against :-)

Does that still hold true now that I have explained how I intended the id to be used? Perhaps changing this to a link with rel='service' (http://www.iana.org/assignments/link-relations/link-relations.xml) would make more sense.

Ben.

--Apple-Mail=_12E56E8E-E1A7-4A96-901D-2F7462E3BF05
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true">Hi Jan,</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">On 29 Apr 2012, at 01:29, Jan Algermissen wrote:</div><div><div><br></div><blockquote type="cite"><div>E.g. instead of having some "Order does not exist error" design an 'order' resource semantic and use 404. There is no error condition that you cannot express that way, in terms of the uniform interface that HTTP provides.<br></div></blockquote><div><br></div><div>Yes and in that situation (Order does not exist), 404 would be the correct response. What if you POST an order for an item, however there is a validation error that prevents the request from being processed. I'd return a 422, perhaps with a text/plain response containing a simple error message. The problem is that without any extra semantics, I cannot for example link to a document that explains what the correct parameters are (accepted values etc), or identify which field contained the error message along side the human readable error.</div><br><blockquote type="cite"><div><blockquote type="cite">Even your example below is doing that.<br></blockquote><br>How so?<br><br><blockquote type="cite">If you have a web api's then you *must* communicate using media types over HTTP. In the case of a web client, adopting this proposed standard means this is understood and disparate clients can understand the same message.<br></blockquote><br>The uniformity of HTTPs applies to the visibility components have in the *absence* of understanding the entity media types. A cache or monitoring intermediary can take action upon a 404, they cannot do that upon e.g. your proposed id="" attribute.<br></div></blockquote><div><br></div><div>Agreed. I'm not advocating this as a replacement to the status code header. The id attribute is for carrying the specific reference to an error log entry on the server. This could be a URL (and perhaps should be a link with a defined rel in the spec, since out of bands information would be required to do anything with it!), but could be a database id with more specific information.</div><div><br></div><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite">If I just use text/plain then I run into problems when I want to represent anything other than just the message (i.e, the id), and then have a requirement for a media type that can represent it.<br></blockquote><br>Hmm, but it is exactly the error-id that I am arguing against :-)<br></div></blockquote></div><br><div>Does that still hold true now that I have explained how I intended the id to be used? Perhaps changing this to a link&nbsp;with rel='service' (<a href="http://www.iana.org/assignments/link-relations/link-relations.xml">http://www.iana.org/assignments/link-relations/link-relations.xml</a>) would make more sense.</div><div><br></div><div>Ben.</div><div><br></div></body></html>
--Apple-Mail=_12E56E8E-E1A7-4A96-901D-2F7462E3BF05--

From: Bjoern Hoehrmann <[email-masked]>
To: Ben Longden <[email-masked]>
Date: Sun, 29 Apr 2012 03:50:10 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json

* Ben Longden wrote:
>   Optional parameters: charset (matching the specification for text/xml)

This should say `application/xml`.
-- 
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/ 

From: Jan Algermissen <[email-masked]>
Date: Sun, 29 Apr 2012 02:29:27 +0200
To: Ben Longden <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json

Bi Ben,

On Apr 28, 2012, at 11:09 PM, Ben Longden wrote:

> Hi Jan,
> 
> Thanks for your comments.
> 
>> If I understand your intention correctly, these two media types are specifically designed to support the anti pattern of tunneling application specific semantics through HTTP.
> 
> I understand what you're saying... But I don't know how to respond to that. You could argue that point about any media type... How could you get application specific semantics from the server to the client without using HTTP?

The key here is that there is no application semantics *on top of HTTP* because HTTP already is a layer 7 protocol. The request and response entities are there to transfer data and controls (links, forms) but not additional (=beyond HTTP) methods or failure codes. If you do that, you have pure old RPC, not Web arch.

In stead of using such methods and codes, we need to design resource semantics in a way that the HTTP protocol is sufficient to realize the uses cases we want to build.

E.g. instead of having some "Order does not exist error" design an 'order' resource semantic and use 404. There is no error condition that you cannot express that way, in terms of the uniform interface that HTTP provides.

> Even your example below is doing that.

How so?

> If you have a web api's then you *must* communicate using media types over HTTP. In the case of a web client, adopting this proposed standard means this is understood and disparate clients can understand the same message.

The uniformity of HTTPs applies to the visibility components have in the *absence* of understanding the entity media types. A cache or monitoring intermediary can take action upon a 404, they cannot do that upon e.g. your proposed id="" attribute.

> 
>> The error communicated of an HTTP error response is specifically indicated by the HTTP status codes (4xx and 5xx). If you feel you need more specific error semantics, you are probably applying HTTP in the wrong way (as a transport to tunnel application semantics).
> 
> I am absolutely advocating the use of the HTTP status code - that's why I have excluded it from the proposed media type(s).
> 
>> From the POV of playing nice with Web architecture I suggest you think about designing proper resource semantics instead.
>> 
>> Regarding the name vnd.error... I think this is an incorrect naming pattern in the vnd-tree, please check.
> 
> There are approved examples of excluding the vendor name from the vnd tree, (http://www.amundsen.com/media-types/collection/) being one. I shall check this out though.
> 
>> Having said that, I think you can achieve pretty much the same with a combination of Link-headers and text/html or text/plain and content negotiation to handle the i18n issue. What do you think?
> 
> I'd argue that a JSON representation with embedded links (_links in application/vnd.error+json) is a lot easier for javascript (one of the main consumers of this media type) to parse than link headers. Totally agree with con-neg to handle the i18n issue and have dropped the multi-lang stuff from the spec.

Ok.

> 
> If I just use text/plain then I run into problems when I want to represent anything other than just the message (i.e, the id), and then have a requirement for a media type that can represent it.

Hmm, but it is exactly the error-id that I am arguing against :-)

Jan

> 
> BenLongden
> http://nocarrier.co.uk

From: Ben Longden <[email-masked]>
Date: Sat, 28 Apr 2012 22:12:37 +0100
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json

--Apple-Mail=_DD9A209D-F4BF-4FEF-8CE0-E88E50D75056
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hi Bjoern,

On 28 Apr 2012, at 00:24, Bjoern Hoehrmann wrote:

> This is using an outdated version of the template. The current one is in
> RFC 4288, some field names are different and others are organized a bit
> differently.

Thanks for that. I have incorporated your changes. Here is the updated document. Again - I wont repost the json equivalent as the differences should be fairly apparent!

   Type name: application

   Subtype name: vnd.error+xml

   Required parameters: none

   Optional parameters: charset (matching the specification for text/xml)

   Encoding considerations: binary

   Security considerations: This media type provides a read only representation of an error state in an application. It does not contain any executable content. No privacy or integrity protection is provided; if either is needed they must be provided by some external service.

   Interoperability considerations: none

   Published specification: https://github.com/blongden/vnd.error

   Applications that use this media type: Web applications

   Additional information:

     Magic number(s):
     File extension(s):
     Macintosh file type code(s):

   Person & email address to contact for further information: Ben Longden <[email-masked]>

   Intended usage: common

   Restrictions on usage: none

   Author: Ben Longden

   Change controller: Ben Longden

BenLongden
http://nocarrier.co.uk

--Apple-Mail=_DD9A209D-F4BF-4FEF-8CE0-E88E50D75056
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Hi Bjoern,</div><div><br></div><div>On 28 Apr 2012, at 00:24, Bjoern Hoehrmann wrote:</div><div><br></div><blockquote type="cite"><div>This is using an outdated version of the template. The current one is in<br>RFC 4288, some field names are different and others are organized a bit<br>differently.<br></div></blockquote><br></div><div>Thanks for that. I have incorporated your changes. Here is the updated document. Again - I wont repost the json equivalent as the differences should be fairly apparent!</div><div><br></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp; &nbsp;Type name: application</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; Subtype name: vnd.error+xml</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; Required parameters: none</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; Optional parameters: charset (matching the specification for text/xml)</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; Encoding considerations: binary</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; Security considerations: This media type provides a read only representation of an error state in an application. It does not contain any executable content. No privacy or integrity protection is provided; if either is needed they must be provided by some external service.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; Interoperability considerations: none</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; Published specification: <a href="https://github.com/blongden/vnd.error">https://github.com/blongden/vnd.error</a></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; Applications that use this media type: Web applications</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; Additional information:</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; &nbsp; Magic number(s):</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; &nbsp; File extension(s):</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; &nbsp; Macintosh file type code(s):</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; Person &amp; email address to contact for further information: Ben Longden &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; Intended usage: common</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; Restrictions on usage: none</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; Author: Ben Longden</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; ">&nbsp;&nbsp; Change controller: Ben Longden</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Courier; "><div apple-content-edited="true" style="font-family: Helvetica; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 18px/normal 'Arial Black'; color: rgb(170, 170, 170); "><span style="color: rgb(0, 0, 0); ">Ben</span>Longden</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal 'Arial Black'; "><span style="color: rgb(170, 170, 170); ">http://</span><a href="http://nocarrier.co.uk">nocarrier.co.uk</a></div></span></div><span class="Apple-style-span" style="font-family: Helvetica; font-size: medium; "><br></span><div style="font-family: Helvetica; font-size: medium; "></div></div></div></body></html>
--Apple-Mail=_DD9A209D-F4BF-4FEF-8CE0-E88E50D75056--

From: Ben Longden <[email-masked]>
Date: Sat, 28 Apr 2012 22:09:45 +0100
To: Jan Algermissen <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json

--Apple-Mail=_D52E6268-5AC4-49B5-905C-E3D8D5AE67D3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Jan,

Thanks for your comments.

> If I understand your intention correctly, these two media types are specifically designed to support the anti pattern of tunneling application specific semantics through HTTP.

I understand what you're saying... But I don't know how to respond to that. You could argue that point about any media type... How could you get application specific semantics from the server to the client without using HTTP? Even your example below is doing that. If you have a web api's then you *must* communicate using media types over HTTP. In the case of a web client, adopting this proposed standard means this is understood and disparate clients can understand the same message.

> The error communicated of an HTTP error response is specifically indicated by the HTTP status codes (4xx and 5xx). If you feel you need more specific error semantics, you are probably applying HTTP in the wrong way (as a transport to tunnel application semantics).

I am absolutely advocating the use of the HTTP status code - that's why I have excluded it from the proposed media type(s).

> From the POV of playing nice with Web architecture I suggest you think about designing proper resource semantics instead.
> 
> Regarding the name vnd.error... I think this is an incorrect naming pattern in the vnd-tree, please check.

There are approved examples of excluding the vendor name from the vnd tree, (http://www.amundsen.com/media-types/collection/) being one. I shall check this out though.

> Having said that, I think you can achieve pretty much the same with a combination of Link-headers and text/html or text/plain and content negotiation to handle the i18n issue. What do you think?

I'd argue that a JSON representation with embedded links (_links in application/vnd.error+json) is a lot easier for javascript (one of the main consumers of this media type) to parse than link headers. Totally agree with con-neg to handle the i18n issue and have dropped the multi-lang stuff from the spec.

If I just use text/plain then I run into problems when I want to represent anything other than just the message (i.e, the id), and then have a requirement for a media type that can represent it.

BenLongden
http://nocarrier.co.uk
--Apple-Mail=_D52E6268-5AC4-49B5-905C-E3D8D5AE67D3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Hi Jan,</div><div><br></div><div>Thanks for your comments.</div><div><br></div><blockquote type="cite"><div>If I understand your intention correctly, these two media types are specifically designed to support the anti pattern of tunneling application specific semantics through HTTP.<br></div></blockquote><div><br></div><div>I understand what you're saying... But I don't know how to respond to that. You could argue that point about any media type... How could you get application specific semantics from the server to the client without using HTTP? Even your example below is doing that. If you have a web api's then you *must* communicate using media types over HTTP. In the case of a web client, adopting this proposed standard means this is understood and disparate clients can understand the same message.</div><br><blockquote type="cite"><div>The error communicated of an HTTP error response is specifically indicated by the HTTP status codes (4xx and 5xx). If you feel you need more specific error semantics, you are probably applying HTTP in the wrong way (as a transport to tunnel application semantics).</div></blockquote><div><br></div><div>I am absolutely advocating the use of the HTTP status code - that's why I have excluded it from the proposed media type(s).</div><br><blockquote type="cite"><div>From the POV of playing nice with Web architecture I suggest you think about designing proper resource semantics instead.<br><br>Regarding the name vnd.error... I think this is an incorrect naming pattern in the vnd-tree, please check.<br></div></blockquote><div><br></div><div>There are approved examples of excluding the vendor name from the vnd tree, (<a href="http://www.amundsen.com/media-types/collection/">http://www.amundsen.com/media-types/collection/</a>) being one. I shall check this out though.</div><br><blockquote type="cite"><div>Having said that, I think you can achieve pretty much the same with a combination of Link-headers and text/html or text/plain and content negotiation to handle the i18n issue. What do you think?<br></div></blockquote><br></div><div>I'd argue that a JSON representation with embedded links (_links in application/vnd.error+json) is a lot easier for javascript (one of the main consumers of this media type) to parse than link headers. Totally agree with con-neg to handle the i18n issue and have dropped the multi-lang stuff from the spec.</div><div><br></div><div>If I just use text/plain then I run into problems when I want to represent anything other than just the message (i.e, the id), and then have a requirement for a media type that can represent it.</div><div><br></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 18px/normal 'Arial Black'; color: rgb(170, 170, 170); "><span style="color: rgb(0, 0, 0); ">Ben</span>Longden</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal 'Arial Black'; "><span style="color: rgb(170, 170, 170); ">http://</span><a href="http://nocarrier.co.uk">nocarrier.co.uk</a></div></div></body></html>
--Apple-Mail=_D52E6268-5AC4-49B5-905C-E3D8D5AE67D3--

From: Bjoern Hoehrmann <[email-masked]>
To: Ben Longden <[email-masked]>
Date: Sat, 28 Apr 2012 01:24:51 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json

* Ben Longden wrote:
>Name : Ben Longden
>
>Email : [email-masked]
>
>MIME media type name : Application
>
>MIME subtype name : Vendor Tree - vnd.error+xml

This is using an outdated version of the template. The current one is in
RFC 4288, some field names are different and others are organized a bit
differently.

>Required parameters : None
>
>Optional parameters : None

You should provide a rationale for using the "+xml" convention while
omitting the optional "charset" parameter of application/xml. The "+xml"
convention is meant to support "generic" processing, but if your type
does not have an optional 'charset' parameter, "generic" software would
not know how to process something like

  Content-Type: application/vnd.error+xml;charset=iso-8859-1

correctly, which I think is a problem.

>Applications which use this media : None

This is supposed to give people an idea whether this is a type that you
would use with word processing software, 3d rendering software, or some
such category of programs. It is not supposed to list individual pro-
ducts.
-- 
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/ 

From: Jan Algermissen <[email-masked]>
Date: Fri, 27 Apr 2012 19:08:52 +0200
To: Ben Longden <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json

Hi Ben,

On Apr 27, 2012, at 5:32 PM, Ben Longden wrote:

> Hi all,
> 
> I'm currently in the process of getting these two mime types registered - a blog post introducing the mime type is available at http://nocarrier.co.uk/2012/04/the-error-hypermedia-type/ and the standard itself is available at https://github.com/blongden/vnd.error

If I understand your intention correctly, these two media types are specifically designed to support the anti pattern of tunneling application specific semantics through HTTP.

The error communicated of an HTTP error response is specifically indicated by the HTTP status codes (4xx and 5xx). If you feel you need more specific error semantics, you are probably applying HTTP in the wrong way (as a transport to tunnel application semantics).

From the POV of playing nice with Web architecture I suggest you think about designing proper resource semantics instead.

Regarding the name vnd.error... I think this is an incorrect naming pattern in the vnd-tree, please check.

Having said that, I think you can achieve pretty much the same with a combination of Link-headers and text/html or text/plain and content negotiation to handle the i18n issue. What do you think?

Jan

> 
> I'm looking for any feedback you may have to offer at this stage (changes, enhancements etc). The registration is as follows (I have only included the xml variant here - the json one has a sub mimetype name of vnd.error+json - otherwise the registration is identical).
> 
> Name : Ben Longden
> 
> Email : [email-masked]
> 
> MIME media type name : Application
> 
> MIME subtype name : Vendor Tree - vnd.error+xml
> 
> Required parameters : None
> 
> Optional parameters : None
> 
> Encoding considerations : binary
> 
> Security considerations : 
> This media type provides a read only representation of an error state in an application. It does not contain any executable content. No privacy or integrity protection is provided; if either is needed they must be provided by some external service.
> 
> Interoperability considerations : None
> 
> Published specification :  https://github.com/blongden/vnd.error
> 
> Applications which use this media : None
> 
> Additional information :
> 1. Magic number(s) : N/A
> 2. File extension(s) : N/A
> 3. Macintosh file type code : N/A
> 4. Object Identifiers: N/A
> 
> Person to contact for further information :
> 1. Name : Ben Longden
> 2. Email : [email-masked]
> 
> Intended usage : Common
> Author/Change controller : Ben Longden
> 
> --
> Ben Longden
> http://nocarrier.co.uk
> 
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

From: Ben Longden <[email-masked]>
Date: Fri, 27 Apr 2012 16:32:45 +0100
To: [email-masked]
Subject: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json

Hi all,

I'm currently in the process of getting these two mime types registered - a blog post introducing the mime type is available at http://nocarrier.co.uk/2012/04/the-error-hypermedia-type/ and the standard itself is available at https://github.com/blongden/vnd.error

I'm looking for any feedback you may have to offer at this stage (changes, enhancements etc). The registration is as follows (I have only included the xml variant here - the json one has a sub mimetype name of vnd.error+json - otherwise the registration is identical).

Name : Ben Longden

Email : [email-masked]

MIME media type name : Application

MIME subtype name : Vendor Tree - vnd.error+xml

Required parameters : None

Optional parameters : None

Encoding considerations : binary

Security considerations : 
This media type provides a read only representation of an error state in an application. It does not contain any executable content. No privacy or integrity protection is provided; if either is needed they must be provided by some external service.

Interoperability considerations : None

Published specification :  https://github.com/blongden/vnd.error

Applications which use this media : None

Additional information :
1. Magic number(s) : N/A
2. File extension(s) : N/A
3. Macintosh file type code : N/A
4. Object Identifiers: N/A

Person to contact for further information :
1. Name : Ben Longden
2. Email : [email-masked]

Intended usage : Common
Author/Change controller : Ben Longden

--
Ben Longden
http://nocarrier.co.uk

Date: Thu, 26 Apr 2012 17:10:02 +0200
From: Magnus Westerlund <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [ietf-types] Review of text/parameters

The MMUSIC WG is currently doing an WG Last Call on RTSP 2.0. The WG
last call ends on May 16th, 2012.

https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/

This document includes the definition (Appendix F) and registration of
the text/parameters format.

22.16.  Media Type Registration for text/parameters

   Type name:  text

   Subtype name:  parameters

   Required parameters:

   Optional parameters:

   Encoding considerations:

   Security considerations:  This format may carry any type of
      parameters.  Some can have security requirements, like privacy,
      confidentiality or integrity requirements.  The format has no
      built in security protection.  For the usage it was defined the
      transport can be protected between server and client using TLS.
      However, care must be take to consider if also the proxies are
      trusted with the parameters in case hop-by-hop security is used.
      If stored as file in file system the necessary precautions needs
      to be taken in relation to the parameters requirements including
      object security such as S/MIME [RFC5751].

   Interoperability considerations:  This media type was mentioned as a
      fictional example in RFC 2326 but was not formally specified.
      This has resulted in usage of this media type which may not match
      its formal definition.

   Published specification:  RFC XXXX, Appendix F.

   Applications that use this media type:  Applications that use RTSP
      and have additional parameters they like to read and set using the
      RTSP GET_PARAMETER and SET_PARAMETER methods.

   Additional information:

   Magic number(s):

   File extension(s):

   Macintosh file type code(s):

   Person & email address to contact for further information:  Magnus
      Westerlund ([email-masked])

   Intended usage:   Common

   Restrictions on usage:   None

   Author:  Magnus Westerlund ([email-masked])

   Change controller:  IETF

   Addition Notes:

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
F�r�gatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

Date: Mon, 23 Apr 2012 09:43:23 -0600
From: Peter Saint-Andre <[email-masked]>
To: =?UTF-8?B?SmVzw7pzIEhlcm7DoW5kZXogR29ybWF6?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Request of new MIME type for Python.

On 4/22/12 4:35 PM, Jesús Hernández Gormaz wrote:
> Hello I am Jesús Hernández Gormaz, I would like to propose that the
> MIME type text / x-python pass to register with the IANA and thus
> switch to a text / python completelystandard and accepted. Also, as
> I guess will know, Python handles files .pyc besides the .py and
> .pyc are your bytecode, so I propose a typoapplication /
> x-python-bytecode to begin to give these files its own MIME type ,
> and encourage as in the previous case to formalize an application
> /bytecode-python as it seems important formalziar Python MIME
> types.

I see no reason for the x- names. See Section 3.4 of RFC 4288 as well
as draft-ietf-appsawg-xdash.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+VeJsACgkQNL8k5A2w/vxBSgCfcfqgAhBE+NXOChNpQyYQDopp
bWIAn306zif19hSz4LAZdpwDR9Ku0Hm8
�VF
-----END PGP SIGNATURE-----

Date: Sun, 22 Apr 2012 23:35:00 +0100
From: =?UTF-8?B?SmVzw7pzIEhlcm7DoW5kZXogR29ybWF6?= <[email-masked]>
To: [email-masked]
Subject: [ietf-types] Request of new MIME type for Python.

--20cf3056430dc8652404be4c21b2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello I am Jesús Hernández Gormaz, I would like to propose
 that the MIME type text / x-python pass to register with the
 IANA and thus switch to a text / python completelystandard
 and accepted. Also, as I guess will know, Python handles
 files .pyc besides the .py and .pyc are your bytecode, so I
 propose a typoapplication / x-python-bytecode to begin to
 give these files its own MIME type , and encourage as in the
 previous case to formalize an application /bytecode-python
 as it seems important formalziar Python MIME types.

Greetings.

-- 
JHG.

--20cf3056430dc8652404be4c21b2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">Hello I am Jesús Hernández Gormaz</span><span class="" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">, I would like</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">to propose</span><div>
<span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> that</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">the MIME type</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">text /</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">x</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">-python</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">pass</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">to register with the</span></div>
<div><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">IANA</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">and thus</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">switch to a</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">text /</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">python</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">completely</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"></span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">standard</span></div>
<div><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">and accepted.</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">Also, as</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">I guess</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">will know</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">, Python</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">handles</span></div>
<div><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> files </span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">.</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"></span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">pyc</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">besides the </span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">.py</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">and </span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">.p</span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">yc</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">are your</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">bytecode</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">, so</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">I</span></div>
<div><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> propose a</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">typo</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"></span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">application /</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">x</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">-python</span><span class="atn" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">-</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">bytecode</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">to begin to</span></div>
<div><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">give these</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">files</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">its own MIME type</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">,</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">and encourage</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">as</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">in the</span></div>
<div><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> previous case</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">to</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">formalize</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">an</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">application /</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"></span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">bytecode</span><span class="" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">-python</span></div>
<div><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">as</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">it seems important</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">formalziar</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">Python</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"> </span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">MIME types</span><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">.</span><br style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">
<br style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)"></span><span class="hps" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">Greetings</span><span class="" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:16px;background-color:rgb(245,245,245)">.</span><br clear="all">
<div><br></div>-- <br>JHG.<br><br>
</div>

--20cf3056430dc8652404be4c21b2--

Sender: "Eric Prud'hommeaux" <[email-masked]>
Date: Wed, 18 Apr 2012 11:36:30 -0400
From: Eric Prud'hommeaux <[email-masked]>
To: [email-masked]
Organization: World Wide Web Consortium (W3C) - http://www.w3.org/
Subject: [ietf-types] Request for review of N-Triples (an RDF serialization) media type: application/n-triples

Hi all, we're about to publish a last call of an RDF representation called N-Triples.
<http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/index.html#sec-mediaReg-n-triples>
(Yes, the contact and the subtype in this email are not in synch with those in the editor's draft -- the email documents plan A and will be reflected to the editor's draft before publication.)
One question is whether to use "application/ntriples" or "application/n-triples", with a preference for the latter.
It'd be great to get feedback on the subtype and registration before last call publication.

Contact:
    World Wide Wed Consortium <[email-masked]>
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 N-Triples is "application/n-triples".

It is recommended that N-Triples files have the extension ".nt" (all lowercase) on all platforms.

It is recommended that N-Triples files stored on Macintosh HFS file systems be given a file type of "TEXT".

This information that follows will be submitted to the IESG for review, approval, and registration with IANA.

Type name:
    application
Subtype name:
    n-triples
Required parameters:
    None
Optional parameters:
    None
Encoding considerations:
    The syntax of N-Triples is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [UTF-8].
    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:
    N-Triples is a general-purpose assertion language; applications may evaluate given data to infer more assertions or to dereference IRIs, invoking the security considerations of the scheme for that IRI. Note in particular, the privacy issues in [RFC3023] section 10 for HTTP IRIs. Data obtained from an inaccurate or malicious data source may lead to inaccurate or misleading conclusions, as well as the dereferencing of unintended IRIs. 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.
    N-Triples 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 N-Triples documents. Security/privacy protocols must be imposed which reflect the sensitivity of the embedded information.
    N-Triples can express data which is presented to the user, for example, RDF Schema labels. Application rendering strings retrieved from untrusted N-Triples 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.
    N-Triples uses IRIs as term identifiers. Applications interpreting data expressed in N-Triples 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:
    This specification.
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):
    None.
File extension(s):
    ".nt"
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 N-Triples specification is the product of the RDF WG. The W3C reserves change control over this specifications.

-- 
-ericP

Date: Tue, 10 Apr 2012 10:07:33 +0200
From: Magnus Westerlund <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: Miguel Garcia A <[email-masked]>, "[email-masked]" <[email-masked]>, Gonzalo Camarillo <[email-masked]>, Hadriel Kaplan <[email-masked]>, Flemming Andreasen <[email-masked]>, Robert Sparks <[email-masked]>
Subject: Re: [ietf-types] Review of

On 2012-04-06 01:30, Bjoern Hoehrmann wrote:
> * Hadriel Kaplan wrote:
> 
>>           Intended usage: COMMON 
> 
> My impression is that RTP-only types typically use LIMITED USE, but I
> might be mistaken about that.

I think you are wrong Bjoern, most have been using Common:

I looked at the five RFC published by the Payload WG and the following
RFCs use common and are RTP payload formats:

RFC6190
RFC6262
RFC6295
RFC6416
RFC6469

All of these used common.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
F�r�gatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

From: Hadriel Kaplan <[email-masked]>
To: Miguel Garcia A <[email-masked]>
Date: Fri, 6 Apr 2012 12:16:48 +0000
Accept-Language: en-US
Subject: Re: [ietf-types] Review of

Yup, will do!
Thanks,

-hadriel

On Apr 6, 2012, at 7:38 AM, Miguel Garcia A wrote:

> Thank you Bj�rn for your review. Please Hadriel, consider Bj�rn 's comments for the next version of the document.
> 
> /Miguel
> ________________________________________
> From: Bjoern Hoehrmann [[email-masked]]
> Sent: Friday, April 06, 2012 1:30 AM
> To: Hadriel Kaplan
> Cc: Martin J. D�rst; [email-masked]; Miguel Garcia A; Flemming Andreasen; Gonzalo Camarillo; Robert Sparks
> Subject: Re: [ietf-types] Review of
> 
> * Hadriel Kaplan wrote:
>> 13.2.1    audio/encaprtp
>>          Encoding considerations: This media type is framed
>>               binary data.
> 
> This should just say "framed".
> 
>>          Published specification: This MIME type is described fully
>>               within this document.
> 
> It might be better to use just "this document" or "RFC XXXX". Note the
> inconsistency in nomenclature, above you have "media type" and here you
> have "MIME type", at least that should be fixed.
> 
>>          Person & email address to contact for further information:
>> 
>>               Kaynam Hedayat
>>               EMail: [email-masked]
> 
> The typical rendering is `Name <[email-masked]>`.
> 
>>          Intended usage: COMMON
> 
> My impression is that RTP-only types typically use LIMITED USE, but I
> might be mistaken about that.
> --
> 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/

From: Miguel Garcia A <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>, Hadriel Kaplan <[email-masked]>
Date: Fri, 6 Apr 2012 13:38:39 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: Flemming Andreasen <[email-masked]>, Robert Sparks <[email-masked]>, Gonzalo Camarillo <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [ietf-types] Review of

Thank you Bj�rn for your review. Please Hadriel, consider Bj�rn 's comments for the next version of the document.

/Miguel
________________________________________
From: Bjoern Hoehrmann [[email-masked]]
Sent: Friday, April 06, 2012 1:30 AM
To: Hadriel Kaplan
Cc: Martin J. D�rst; [email-masked]; Miguel Garcia A; Flemming Andreasen; Gonzalo Camarillo; Robert Sparks
Subject: Re: [ietf-types] Review of

* Hadriel Kaplan wrote:
> 13.2.1    audio/encaprtp
>           Encoding considerations: This media type is framed
>                binary data.

This should just say "framed".

>           Published specification: This MIME type is described fully
>                within this document.

It might be better to use just "this document" or "RFC XXXX". Note the
inconsistency in nomenclature, above you have "media type" and here you
have "MIME type", at least that should be fixed.

>           Person & email address to contact for further information:
>
>                Kaynam Hedayat
>                EMail: [email-masked]

The typical rendering is `Name <[email-masked]>`.

>           Intended usage: COMMON

My impression is that RTP-only types typically use LIMITED USE, but I
might be mistaken about that.
--
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/

From: Bjoern Hoehrmann <[email-masked]>
To: Hadriel Kaplan <[email-masked]>
Date: Fri, 06 Apr 2012 01:30:50 +0200
Cc: "Miguel A. Garcia" <[email-masked]>, "[email-masked]" <[email-masked]>, Gonzalo Camarillo <[email-masked]>, Flemming Andreasen <[email-masked]>, Robert Sparks <[email-masked]>
Subject: Re: [ietf-types] Review of

* Hadriel Kaplan wrote:
> 13.2.1    audio/encaprtp 
>           Encoding considerations: This media type is framed  
>                binary data. 

This should just say "framed".

>           Published specification: This MIME type is described fully 
>                within this document. 

It might be better to use just "this document" or "RFC XXXX". Note the
inconsistency in nomenclature, above you have "media type" and here you
have "MIME type", at least that should be fixed.

>           Person & email address to contact for further information: 
>     
>                Kaynam Hedayat 
>                EMail: [email-masked] 

The typical rendering is `Name <[email-masked]>`.

>           Intended usage: COMMON 

My impression is that RTP-only types typically use LIMITED USE, but I
might be mistaken about that.
-- 
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/ 

From: Hadriel Kaplan <[email-masked]>
To: =?iso-8859-1?Q?Martin_J._D�rst?= <[email-masked]>, "[email-masked]" <[email-masked]>
Accept-Language: en-US
Cc: "Miguel A. Garcia" <[email-masked]>, Flemming Andreasen <[email-masked]>, Gonzalo Camarillo <[email-masked]>, Robert Sparks <[email-masked]>
Subject: Re: [ietf-types] Review of

 13.2.1    audio/encaprtp 
     
           To: [email-masked] 

           Subject: Registration of media type audio/encaprtp 

           Type name: audio 

           Subtype name: encaprtp 

           Required parameters:  
                rate:RTP timestamp clock rate, which is equal to the 
                sampling rate. The typical rate is 8000; other rates 
                may be specified.  
     
           Optional parameters: none 
     
           Encoding considerations: This media type is framed  
                binary data. 

           Security considerations: See Section 12 of this document. 
     
           Interoperability considerations: none 
     
           Published specification: This MIME type is described fully 
                within this document. 
     
           Applications which use this media type: Applications wishing 
                to monitor and ensure the quality of transport to the 
                edge of a given VoIP, Real-Time Text or Video Over IP 
                Service. 
     
           Additional information: none 
     
           Person & email address to contact for further information: 
     
                Kaynam Hedayat 
                EMail: [email-masked] 
     
           Intended usage: COMMON 
     
           Restrictions on usage: This media type depends on RTP 
                framing, and hence is only defined for transfer via 
                RTP. Transfer within other framing protocols is not 
                defined at this time.                       
     
           Author:  
                Kaynam Hedayat.  
     
           Change controller: IETF Audio/Video Transport working 
                group delegated from the IESG. 

 13.2.2    video/encaprtp 
     
           To: [email-masked] 
     
           Subject: Registration of media type video/encaprtp 
     
           Type name: video 
     
           Subtype name: encaprtp 
     
           Required parameters:  
                 
                rate:RTP timestamp clock rate, which is equal to the 
                sampling rate. The typical rate is 8000; other rates 
                may be specified.  

           Optional parameters: none 
     
           Encoding considerations: This media type is framed  
                binary data. 
     
           Security considerations: See Section 12 of this document. 
     
           Interoperability considerations: none 
     
           Published specification: This MIME type is described fully 
                within this document. 
     
           Applications which use this media type: Applications wishing 
                to monitor and ensure the quality of transport to the 
                edge of a given VoIP, Real-Time Text or Video Over IP 
                Service. 
     
           Additional information: none 
     
           Person & email address to contact for further information: 
     
                Kaynam Hedayat 
                EMail: [email-masked] 
     
           Intended usage: COMMON 
     
           Restrictions on usage: This media type depends on RTP 
                framing, and hence is only defined for transfer via 
                RTP. Transfer within other framing protocols is not 
                defined at this time.                       
     
           Author:  
                Kaynam Hedayat.  
     
           Change controller: IETF Audio/Video Transport working 
                group delegated from the IESG. 

 13.2.3    text/encaprtp 
     
           To: [email-masked] 
     
           Subject: Registration of media type text/encaprtp 
     
           Type name: text 
     
           Subtype name: encaprtp 

           Required parameters:  
                 
                rate:RTP timestamp clock rate, which is equal to the 
                sampling rate. The typical rate is 8000; other rates 
                may be specified.  
     
           Optional parameters: none 
     
           Encoding considerations: This media type is framed  
                binary data. 
     
           Security considerations: See Section 12 of this document. 
     
           Interoperability considerations: none 
     
           Published specification: This MIME type is described fully 
                within this document. 
     
           Applications which use this media type: Applications wishing 
                to monitor and ensure the quality of transport to the 
                edge of a given VoIP, Real-Time Text or Video Over IP 
                Service. 
     
           Additional information: none 
     
           Person & email address to contact for further information: 
     
                Kaynam Hedayat 
                EMail: [email-masked] 
     
           Intended usage: COMMON 
     
           Restrictions on usage: This media type depends on RTP 
                framing, and hence is only defined for transfer via 
                RTP. Transfer within other framing protocols is not 
                defined at this time.                       
     
           Author:  
                Kaynam Hedayat.  
     
           Change controller: IETF Audio/Video Transport working 
                group delegated from the IESG. 

 13.2.4    application/encaprtp 
     
           To: [email-masked] 

           Subject: Registration of media type 
                application/encaprtp 
     
           Type name: application 
     
           Subtype name: encaprtp 
     
           Required parameters:  
                 
                rate:RTP timestamp clock rate, which is equal to the 
                sampling rate. The typical rate is 8000; other rates 
                may be specified.  
     
           Optional parameters: none 
     
           Encoding considerations: This media type is framed  
                binary data. 
     
           Security considerations: See Section 12 of this document. 
     
           Interoperability considerations: none 
     
           Published specification: This MIME type is described fully 
                within this document. 
     
           Applications which use this media type: Applications wishing 
                to monitor and ensure the quality of transport to the 
                edge of a given VoIP, Real-Time Text or Video Over IP 
                Service. 
     
           Additional information: none 
     
           Person & email address to contact for further information: 
     
                Kaynam Hedayat 
                EMail: [email-masked] 
     
           Intended usage: COMMON 
     
           Restrictions on usage: This media type depends on RTP 
                framing, and hence is only defined for transfer via 
                RTP. Transfer within other framing protocols is not 
                defined at this time.                       
     
           Author:  
                Kaynam Hedayat.  
     
           Change controller: IETF Audio/Video Transport working 
                group delegated from the IESG. 

 13.2.5    audio/rtploopback 
     
           To: [email-masked] 
     
           Subject: Registration of media type audio/rtploopback 
     
           Type name: audio 
     
           Subtype name: rtploopback 
     
           Required parameters:  
                 
                rate:RTP timestamp clock rate, which is equal to the 
                sampling rate. The typical rate is 8000; other rates 
                may be specified.  
     
           Optional parameters: none 
     
           Encoding considerations: This media type is framed  
                binary data. 
     
           Security considerations: See Section 12 of this document. 
     
           Interoperability considerations: none 
     
           Published specification: This MIME type is described fully 
                within this document. 
     
           Applications which use this media type: Applications wishing 
                to monitor and ensure the quality of transport to the 
                edge of a given VoIP, Real-Time Text or Video Over IP 
                Service. 
     
           Additional information: none 
     
           Person & email address to contact for further information: 
     
                Kaynam Hedayat 
                EMail: [email-masked] 
     
           Intended usage: COMMON 
     
           Restrictions on usage: This media type depends on RTP 
                framing, and hence is only defined for transfer via 
                RTP. Transfer within other framing protocols is not 
                defined at this time.                       
     
           Author:  
                Kaynam Hedayat.  
     
           Change controller: IETF Audio/Video Transport working 
                group delegated from the IESG. 
     
 13.2.6    video/rtploopback 
     
           To: [email-masked] 
     
           Subject: Registration of media type video/rtploopback 
     
           Type name: video 
     
           Subtype name: rtploopback 
     
           Required parameters:  
                 
                rate:RTP timestamp clock rate, which is equal to the 
                sampling rate. The typical rate is 8000; other rates 
                may be specified.  
     
           Optional parameters: none 
     
           Encoding considerations: This media type is framed  
                binary data. 
     
           Security considerations: See Section 12 of this document. 
     
           Interoperability considerations: none 
     
           Published specification: This MIME type is described fully 
                within this document. 
     
           Applications which use this media type: Applications wishing 
                to monitor and ensure the quality of transport to the 
                edge of a given VoIP, Real-Time Text or Video Over IP 
                Service. 
     
           Additional information: none 
     
           Person & email address to contact for further information: 
     
                Kaynam Hedayat 
                EMail: [email-masked] 
     
           Intended usage: COMMON 
     
           Restrictions on usage: This media type depends on RTP 
                framing, and hence is only defined for transfer via 
                RTP. Transfer within other framing protocols is not 
                defined at this time.                       
     
           Author:  
                Kaynam Hedayat.  
     
           Change controller: IETF Audio/Video Transport working 
                group delegated from the IESG. 

 13.2.7    text/rtploopback 
     
           To: [email-masked] 
     
           Subject: Registration of media type text/rtploopback 
     
           Type name: text 
     
           Subtype name: rtploopback 
     
           Required parameters:  
                 
                rate:RTP timestamp clock rate, which is equal to the 
                sampling rate. The typical rate is 8000; other rates 
                may be specified.  
     
           Optional parameters: none 
     
           Encoding considerations: This media type is framed  
                binary data. 
     
           Security considerations: See Section 12 of this document. 
     
           Interoperability considerations: none 
     
           Published specification: This MIME type is described fully 
                within this document. 
     
           Applications which use this media type: Applications wishing 
                to monitor and ensure the quality of transport to the 
                edge of a given VoIP, Real-Time Text or Video Over IP 
                Service. 
     
           Additional information: none 
     
           Person & email address to contact for further information: 
     
                Kaynam Hedayat 
                EMail: [email-masked] 

           Intended usage: COMMON 
     
           Restrictions on usage: This media type depends on RTP 
                framing, and hence is only defined for transfer via 
                RTP. Transfer within other framing protocols is not 
                defined at this time.                       
     
           Author:  
                Kaynam Hedayat.  
     
           Change controller: IETF Audio/Video Transport working 
                group delegated from the IESG. 

 13.2.8    application/rtploopback 
     
           To: [email-masked] 
     
           Subject: Registration of media type 
                application/rtploopback 
     
           Type name: application 
     
           Subtype name: rtploopback 
     
           Required parameters:  
                 
                rate:RTP timestamp clock rate, which is equal to the 
                sampling rate. The typical rate is 8000; other rates 
                may be specified.  
     
           Optional parameters: none 
     
           Encoding considerations: This media type is framed  
                binary data. 
     
           Security considerations: See Section 12 of this document. 
     
           Interoperability considerations: none 
     
           Published specification: This MIME type is described fully 
                within this document. 
     
           Applications which use this media type: Applications wishing 
                to monitor and ensure the quality of transport to the 
                edge of a given VoIP, Real-Time Text or Video Over IP 
                Service. 

           Additional information: none 
     
           Person & email address to contact for further information: 
     
                Kaynam Hedayat 
                EMail: [email-masked] 
     
           Intended usage: COMMON 
     
           Restrictions on usage: This media type depends on RTP 
                framing, and hence is only defined for transfer via 
                RTP. Transfer within other framing protocols is not 
                defined at this time.                       
     
           Author:  
                Kaynam Hedayat.  
     
           Change controller: IETF Audio/Video Transport working 
                group delegated from the IESG. 

On Apr 5, 2012, at 2:19 AM, Martin J. D�rst wrote:

> Hello Miguel,
> 
> Please post the registration templates here. This gives you a *much* higher chance of getting good comments.
> 
> Regards,   Martin.
> 
> On 2012/04/04 19:26, Miguel A. Garcia wrote:
>> Hi,
>> 
>> The MMUSIC working group is running the WGLC of
>> draft-ietf-mmusic-media-loopback-18.txt, available at:
>> 
>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback/
>> 
>> The draft registers 8 new media types. Please refer to Section 13.2 in
>> the draft:
>> 
>> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-18#section-13.2
>> 
>> We will appreciate if you can review the registration and provide us
>> with comments.
>> 
>> Thanks,
>> 
>> Miguel

Date: Thu, 05 Apr 2012 15:19:19 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <[email-masked]>
Organization: Aoyama Gakuin University
To: "Miguel A. Garcia" <[email-masked]>
Cc: Flemming Andreasen <[email-masked]>, Robert Sparks <[email-masked]>, Gonzalo Camarillo <[email-masked]>, Hadriel Kaplan <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Review of

Hello Miguel,

Please post the registration templates here. This gives you a *much* 
higher chance of getting good comments.

Regards,   Martin.

On 2012/04/04 19:26, Miguel A. Garcia wrote:
> Hi,
>
> The MMUSIC working group is running the WGLC of
> draft-ietf-mmusic-media-loopback-18.txt, available at:
>
> http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback/
>
> The draft registers 8 new media types. Please refer to Section 13.2 in
> the draft:
>
> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-18#section-13.2
>
> We will appreciate if you can review the registration and provide us
> with comments.
>
> Thanks,
>
> Miguel

Date: Wed, 4 Apr 2012 15:01:31 +0300
From: Gonzalo Camarillo <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: Miguel Garcia A <[email-masked]>, Flemming Andreasen <[email-masked]>, Hadriel Kaplan <[email-masked]>, Robert Sparks <[email-masked]>
Subject: Re: [ietf-types] Review of draft-ietf-mmusic-media-loopback-18.txt

Fixing the subject of the email.

Gonzalo

On 04/04/2012 1:26 PM, Miguel Garcia A wrote:
> Hi,
> 
> The MMUSIC working group is running the WGLC of 
> draft-ietf-mmusic-media-loopback-18.txt, available at:
> 
> http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback/
> 
> The draft registers 8 new media types. Please refer to Section 13.2 in 
> the draft:
> 
> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-18#section-13.2
> 
> We will appreciate if you can review the registration and provide us with 
> comments.
> 
> Thanks,
> 
>   Miguel

Date: Wed, 4 Apr 2012 12:26:56 +0200
From: "Miguel A. Garcia" <[email-masked]>
To: <[email-masked]>
Cc: Flemming Andreasen <[email-masked]>, Gonzalo Camarillo <[email-masked]>, Hadriel Kaplan <[email-masked]>, Robert Sparks <[email-masked]>
Subject: [ietf-types] Review of

Hi,

The MMUSIC working group is running the WGLC of 
draft-ietf-mmusic-media-loopback-18.txt, available at:

http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback/

The draft registers 8 new media types. Please refer to Section 13.2 in 
the draft:

http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-18#section-13.2

We will appreciate if you can review the registration and provide us with 
comments.

Thanks,

  Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain