Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD1F21F85B5 for ; Sun, 29 Apr 2012 13:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.641 X-Spam-Level: X-Spam-Status: No, score=-3.641 tagged_above=-999 required=5 tests=[AWL=-1.392, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRq+7o6e3XZo for ; Sun, 29 Apr 2012 13:55:27 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id E807321F8599 for ; Sun, 29 Apr 2012 13:55:26 -0700 (PDT) Received: from [192.168.2.101] (p548FD838.dip.t-dialin.net [84.143.216.56]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MhJrR-1SbbrB3UvZ-00MLK9; Sun, 29 Apr 2012 22:55:25 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: <5812232F-0278-4AC4-94F6-2A50B3B4241F@nocarrier.co.uk> Date: Sun, 29 Apr 2012 22:55:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F5BD73F-64C1-490A-B320-4527880418E3@nordsc.com> References: <7C70AEAE-52F9-4575-BF66-E348ADDF9DAD@nocarrier.co.uk> <24D956A5-24CF-437A-A80C-DF6B5DAB87D6@nordsc.com> <5812232F-0278-4AC4-94F6-2A50B3B4241F@nocarrier.co.uk> To: Ben Longden X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:8WPJTLoK4iKqrU0IgDZboPWN+zY2SDPx+U/0PuqY4KR RPgskWeImOGOf17n2bpw8VXeRgNv6HxqiUUAC6RPUBBJzf5Q4y 2zBxi2nLeBu2Iz7FmYnjYo2RiSUKsP23KRGPQqm+y6oeays6zc olM5LEZQbAm6gyULlrQw4ksiv0OXoGrpADoq3ut+Qzy9/ZnIex l9usjdrhe5Dg/8cPxUK+Mb4txAGIeB+Xs7wWvVOQgmgXAj1mF6 d4xsga/2sY0Pjlo196+vAzUpdfNbtFbF8YkwRqKug39GWE3qHT 22MzfoyVuSBAMUYitK+U38HRfKDUyjgXtEVqOXRZAE4CPMZeTi fdjA+6rqK4agrVk5BpmU1sdJz3eco9yVm7Ae/fl5n3zRriFyYB Cf+GEulYIlyTg== Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 20:55:28 -0000 On Apr 29, 2012, at 3:06 PM, Ben Longden wrote: > Hi Jan, >=20 > On 29 Apr 2012, at 01:29, Jan Algermissen wrote: >=20 >> 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. >=20 > 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. >=20 >>> Even your example below is doing that. >>=20 >> How so? >>=20 >>> 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. >>=20 >> 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=3D"" attribute. >=20 > 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 >=20 >>>=20 >>> 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. >>=20 >> Hmm, but it is exactly the error-id that I am arguing against :-) >=20 > 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=3D'service' = (http://www.iana.org/assignments/link-relations/link-relations.xml) = would make more sense. >=20 > Ben. >=20 > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCAA21F8548 for ; Sun, 29 Apr 2012 06:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRcSrWpS-L1f for ; Sun, 29 Apr 2012 06:10:09 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9138C21F8531 for ; Sun, 29 Apr 2012 06:10:09 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so1733224wib.1 for ; Sun, 29 Apr 2012 06:10:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=TRol6g55HCDwSqt+6DFy/m6NzN2qzWcn34E/XudT56Y=; b=fpGABjTD5/XEVlDAfJ8CQoYgMpddSR4gm/s1gAmT9zG2T8JV2xufcLPgPHKIfEMgOT iGoGmaD4xdMTX6Z6dEdFM6pYSufmoRkSpzvoggQZ5sGxJuI3WCYFoWCLeEp4guPsX8tP GCX9w72UpmM3OrIXtho8OOOPyTTtjo5GAZs8S76zVxBysyaoKvvJR/tkn6GL0NZqYfmU KA0jDHtrNMVP1rZL056YhqjIdV6g1UVFHjMCL1oyEf0VlW2PhsZh1g/LqkmFQNlehanp xUw0DTE9K6gTI1xrIeZoLCwTX1B943AXTLwiU/SPk6SbIouSrHt71iRFVYQBrdARFD3J sqdA== Received: by 10.216.134.136 with SMTP id s8mr10993997wei.6.1335705008662; Sun, 29 Apr 2012 06:10:08 -0700 (PDT) Received: from [192.168.0.16] (02da1837.bb.sky.com. [2.218.24.55]) by mx.google.com with ESMTPS id fn2sm32875422wib.0.2012.04.29.06.10.07 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Apr 2012 06:10:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ben Longden In-Reply-To: Date: Sun, 29 Apr 2012 14:10:08 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <7C70AEAE-52F9-4575-BF66-E348ADDF9DAD@nocarrier.co.uk> <7F4080A8-BA78-4123-8528-56C7B548A85F@nocarrier.co.uk> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmjGF+2sUdHzG72HJsygU8S7TGIKap0+mFWDvwttqL4x1dO+TW4DF779Ao5430D9zMLV4p6 Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 13:10:10 -0000 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 Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35AE21F847A for ; Sun, 29 Apr 2012 06:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRHFsSOeLTdR for ; Sun, 29 Apr 2012 06:06:21 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A479021F84A1 for ; Sun, 29 Apr 2012 06:06:20 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so1604790wib.13 for ; Sun, 29 Apr 2012 06:06:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=XiBX11xg1rhTU7j3SSVXHjY2daModnDx683K8B57Q1o=; b=i/W7l1JccHZZpnHc5ExTgQ0FIRZ1sMhwBJi32gnUGvlkfCk5i4/baevk/QxLGX68Qh zb0xwWlfPBhbURKqTJBShgzylZtindR5teYiY7belv2Hhd5JxxDLQTzosalLAD9bn7l8 +b2U0lvBmiE4rDGGJE74aOPo7Bt7doNtqpqWQGv6hTSBRarQ4/XtB3bR8jDBeQIZpdTY t56ch8Q18VLFLl5ApTMWdyXn/dclY/VAUTyhgz62MDSMFWh+TZMvcs5hsQBwTu7GlNFz 6IxwvjIWoD9LOGuAZkmw8uRG4kl4L6uxaH7oyxnAa6Go+UWDPWshOhovL1gvLJ4aoFEJ 28Gw== Received: by 10.216.134.27 with SMTP id r27mr7589301wei.107.1335704779471; Sun, 29 Apr 2012 06:06:19 -0700 (PDT) Received: from [192.168.0.16] (02da1837.bb.sky.com. [2.218.24.55]) by mx.google.com with ESMTPS id ff9sm20665481wib.2.2012.04.29.06.06.18 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Apr 2012 06:06:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_12E56E8E-E1A7-4A96-901D-2F7462E3BF05" From: Ben Longden In-Reply-To: Date: Sun, 29 Apr 2012 14:06:19 +0100 Message-Id: <5812232F-0278-4AC4-94F6-2A50B3B4241F@nocarrier.co.uk> References: <7C70AEAE-52F9-4575-BF66-E348ADDF9DAD@nocarrier.co.uk> <24D956A5-24CF-437A-A80C-DF6B5DAB87D6@nordsc.com> To: Jan Algermissen X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlEqoQAnHebWiA2fzuPjkNBRfZw7rH8+5MtgDHnRwmJfCdNxndUgQdnsQ2cw6GPYHn/RDPM Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 13:06:21 -0000 --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. >=20 > How so? >=20 >> 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. >=20 > 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=3D"" 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. >>=20 >> 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. >=20 > 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=3D'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
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=3D"" 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=3D'service' (http://www.iana.org/assignments/link-relations/link-relations.xml) = would make more = sense.

Ben.

= --Apple-Mail=_12E56E8E-E1A7-4A96-901D-2F7462E3BF05-- Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C430E21F85C4 for ; Sat, 28 Apr 2012 18:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44V9jkrn9z8q for ; Sat, 28 Apr 2012 18:50:09 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 683B321F85A7 for ; Sat, 28 Apr 2012 18:50:09 -0700 (PDT) Received: (qmail invoked by alias); 29 Apr 2012 01:50:07 -0000 Received: from dslb-094-223-198-127.pools.arcor-ip.net (EHLO HIVE) [94.223.198.127] by mail.gmx.net (mp028) with SMTP; 29 Apr 2012 03:50:07 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+VSVlguhmVwakp11PmHx+1XqxJSiYX+8hENYsNLt c1tyRpB/l741// From: Bjoern Hoehrmann To: Ben Longden Date: Sun, 29 Apr 2012 03:50:10 +0200 Message-ID: References: <7C70AEAE-52F9-4575-BF66-E348ADDF9DAD@nocarrier.co.uk> <7F4080A8-BA78-4123-8528-56C7B548A85F@nocarrier.co.uk> In-Reply-To: <7F4080A8-BA78-4123-8528-56C7B548A85F@nocarrier.co.uk> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 01:50:10 -0000 * Ben Longden wrote: > Optional parameters: charset (matching the specification for text/xml) This should say `application/xml`. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C734521F85D4 for ; Sat, 28 Apr 2012 17:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.919 X-Spam-Level: X-Spam-Status: No, score=-3.919 tagged_above=-999 required=5 tests=[AWL=-1.670, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ANcBMrnYjZw for ; Sat, 28 Apr 2012 17:29:30 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id B23C021F85D2 for ; Sat, 28 Apr 2012 17:29:29 -0700 (PDT) Received: from [192.168.2.101] (p548FD898.dip.t-dialin.net [84.143.216.152]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MKPWk-1SNk3K0eYg-001fkS; Sun, 29 Apr 2012 02:29:28 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: Date: Sun, 29 Apr 2012 02:29:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C70AEAE-52F9-4575-BF66-E348ADDF9DAD@nocarrier.co.uk> <24D956A5-24CF-437A-A80C-DF6B5DAB87D6@nordsc.com> To: Ben Longden X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:R09YwqndU8Nu8JpCRPJ8d1hvJiZ4DR4u+nQiez2SyU5 qN9ci7gDlDAbWNdZtYObTbSOTcKjPriEVv/MnaNfnBdubNgrJI t61DyPYB7ftnkIpnUy5fjYJ51cHFAKP44CtmYwEkMiudD83lnQ fHZAzH+2/DdeAgF/lDKlJkXiH9QFrMui2Jyrhrpyi+WtTwZzcu 2Xcfh0SBYLVilw3jIfgIu9wo8OIOFPyUs2S/+XysX7+ywD7g9u 8WkEYggujOfd58wGSeN2PD0i+iYtSKQ55xPzCyP5CQDSvjEpwr l0+vXO4avbQg1lKLfPQGk06Pk2S7VyGNeiyJtr5MMhzn2muFrn SpFF3zawsA8IUDvIbKcBrFZORtJArnLMEyhNYrHQ08pCL2v+r8 GjjK4xbonLwuA== Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 00:29:30 -0000 Bi Ben, On Apr 28, 2012, at 11:09 PM, Ben Longden wrote: > Hi Jan, >=20 > Thanks for your comments. >=20 >> 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. >=20 > 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 (=3Dbeyond 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=3D"" attribute. >=20 >> 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). >=20 > I am absolutely advocating the use of the HTTP status code - that's = why I have excluded it from the proposed media type(s). >=20 >> =46rom the POV of playing nice with Web architecture I suggest you = think about designing proper resource semantics instead. >>=20 >> Regarding the name vnd.error... I think this is an incorrect naming = pattern in the vnd-tree, please check. >=20 > 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. >=20 >> 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? >=20 > 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. >=20 > 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 >=20 > BenLongden > http://nocarrier.co.uk Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A1621F860D for ; Sat, 28 Apr 2012 14:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxz7gt8WcJbC for ; Sat, 28 Apr 2012 14:12:41 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 753E821F8600 for ; Sat, 28 Apr 2012 14:12:40 -0700 (PDT) Received: by werb10 with SMTP id b10so1388674wer.31 for ; Sat, 28 Apr 2012 14:12:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=dEP1kh4Q1FmaA1g4R3tqPfHJnEB8VShDtGbg4gPQ+/A=; b=GGPwQ+27VEONlF/zd7UCwn0P/I5w6XXGY5YTKb+knK4vkkrbKu9F4zNjgZu2M/Mwbh Vb+XVsvw0hwxMcMbNORt4rXPW8O6jkrTQdZzSipEhz6SN3zuci6OBVlqwulFrYQ7Rm6Q wLxV2uI3CBcJ2lzOLQfmN+kg9fBhqecINeFcPjZGn9vUxGWLxFxeTjdDWFc2fhtAb2tO oktrZOQt3dH4wmr/23f2hP87VPymYLZ7ydm8v6+Qi0n+n7T0kgJn/tjfp+61MuRa2H+n 0fOsmTpY5/Z0m20Iz0cVwcIFglOrQ8QVl+BoyKdo5L8pG82vAZhSbWqmcGLuIa1Yc8vE ZXIg== Received: by 10.180.102.100 with SMTP id fn4mr17052234wib.1.1335647559435; Sat, 28 Apr 2012 14:12:39 -0700 (PDT) Received: from [192.168.0.16] (02da1837.bb.sky.com. [2.218.24.55]) by mx.google.com with ESMTPS id o2sm24574576wiv.11.2012.04.28.14.12.38 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 28 Apr 2012 14:12:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_DD9A209D-F4BF-4FEF-8CE0-E88E50D75056" From: Ben Longden In-Reply-To: Date: Sat, 28 Apr 2012 22:12:37 +0100 Message-Id: <7F4080A8-BA78-4123-8528-56C7B548A85F@nocarrier.co.uk> References: <7C70AEAE-52F9-4575-BF66-E348ADDF9DAD@nocarrier.co.uk> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmohISPv5//P3hIjIXnf9c2lpgkohYPjWwiV4MNcPzdT5OWQ4NJSmbcNrhq4llF5XaFqXjw Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 21:12:41 -0000 --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 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
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

   Required parameters: none

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

   Encoding = considerations: binary



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


     Magic number(s):
     = Macintosh file type code(s):

ben@nocarrier.co.uk>

   Intended usage: = common

   Author: Ben Longden

   Change controller: Ben = Longden

nocarrier.co.uk

= --Apple-Mail=_DD9A209D-F4BF-4FEF-8CE0-E88E50D75056-- Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B8321F8624 for ; Sat, 28 Apr 2012 14:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRqRnPcDv03n for ; Sat, 28 Apr 2012 14:09:48 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6FADA21F8610 for ; Sat, 28 Apr 2012 14:09:48 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so1360747wib.13 for ; Sat, 28 Apr 2012 14:09:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=RJ9U6F8xd0yr3d1JFfkTVmaqUx02FxHuDtckNdheTzE=; b=X6BzFvUKWVc5717yuGL+A4Ic+zSqY3eIfjEMUqaF0eXv8j1o0Z0+m39uydioPMgDs3 EV31qtv/gwSV1voKK1r77ZGwHaC4AFA/95VbJidWw7aPe44maPIMQKI7O19ibGp8m7z2 iJ5zQrcOEMJz5/PtwZDPhQUXHYsdk1Z6V7RscxycQM3rx55yhUZgE+M2or+YOg/oaBYg vOoMs32ZJMCc5Qr5tJkedskk291B6N8OP4C4wlX0/G/A0Eq/lpcvmyi7LP/0KD1k4f2i u4EsHIkdSPO44j0Xd+RUvrotqoU5hv7hzgzigEIIPcM4WNtq4pT+hhvX081P7QtI9b4Q Iufg== Received: by 10.216.132.18 with SMTP id n18mr9688154wei.81.1335647386986; Sat, 28 Apr 2012 14:09:46 -0700 (PDT) Received: from [192.168.0.16] (02da1837.bb.sky.com. [2.218.24.55]) by mx.google.com with ESMTPS id b3sm15649217wib.4.2012.04.28.14.09.45 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 28 Apr 2012 14:09:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_D52E6268-5AC4-49B5-905C-E3D8D5AE67D3" From: Ben Longden In-Reply-To: <24D956A5-24CF-437A-A80C-DF6B5DAB87D6@nordsc.com> Date: Sat, 28 Apr 2012 22:09:45 +0100 Message-Id: References: <7C70AEAE-52F9-4575-BF66-E348ADDF9DAD@nocarrier.co.uk> <24D956A5-24CF-437A-A80C-DF6B5DAB87D6@nordsc.com> To: Jan Algermissen X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlXT7G1kmbt6wkJ8+W1p597U/JFqq01A6OPfKNv1FYlC3XZ3ftoTxsu8r4w9kJmk8PLz/Oj Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 21:09:50 -0000 --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). > =46rom the POV of playing nice with Web architecture I suggest you = think about designing proper resource semantics instead. >=20 > 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
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).

=46rom 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.amunds= en.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.

nocarrier.co.uk
= --Apple-Mail=_D52E6268-5AC4-49B5-905C-E3D8D5AE67D3-- Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BEC21F86CA for ; Fri, 27 Apr 2012 16:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GZIQSBXrnL3 for ; Fri, 27 Apr 2012 16:24:52 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A819921F86B8 for ; Fri, 27 Apr 2012 16:24:51 -0700 (PDT) Received: (qmail invoked by alias); 27 Apr 2012 23:24:50 -0000 Received: from dslb-094-223-198-127.pools.arcor-ip.net (EHLO HIVE) [94.223.198.127] by mail.gmx.net (mp040) with SMTP; 28 Apr 2012 01:24:50 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/Z90MCCdvZwynijVNj41TZ/sSvdBn01/43QJYebR bqQV6u7ulVToIU From: Bjoern Hoehrmann To: Ben Longden Date: Sat, 28 Apr 2012 01:24:51 +0200 Message-ID: References: <7C70AEAE-52F9-4575-BF66-E348ADDF9DAD@nocarrier.co.uk> In-Reply-To: <7C70AEAE-52F9-4575-BF66-E348ADDF9DAD@nocarrier.co.uk> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 23:24:53 -0000 * Ben Longden wrote: >Name : Ben Longden > >Email : ben@nocarrier.co.uk > >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:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EFB21F869D for ; Fri, 27 Apr 2012 10:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.337 X-Spam-Level: X-Spam-Status: No, score=-4.337 tagged_above=-999 required=5 tests=[AWL=-2.088, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmCSK3E9veIF for ; Fri, 27 Apr 2012 10:08:56 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 073CF21F8600 for ; Fri, 27 Apr 2012 10:08:55 -0700 (PDT) Received: from [192.168.2.103] (p548FA8E2.dip.t-dialin.net [84.143.168.226]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MPqmw-1SIqaS19nO-004yDw; Fri, 27 Apr 2012 19:08:54 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: <7C70AEAE-52F9-4575-BF66-E348ADDF9DAD@nocarrier.co.uk> Date: Fri, 27 Apr 2012 19:08:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24D956A5-24CF-437A-A80C-DF6B5DAB87D6@nordsc.com> References: <7C70AEAE-52F9-4575-BF66-E348ADDF9DAD@nocarrier.co.uk> To: Ben Longden X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:OiWm3RRza3QuftbHOTP/D7HJkZX3lGWIKPrK+ziRSlA 6WyhhMh3mRoLSXoxsnVP+TvmWZX2CmOvLaleBGWbsdH8DRFKIe +uucfxc+GhEqrQqGFQGH+87FAtEaxQs19wSbAR/bz0tuidsDUv qQFg7IG6At4bLeG3UGCyvPM4r8hhtZuDXBDfqcBLY3X8PrZ1cq ZIwpMTbvfnOrr93hW4+4wHimgW4C9WzhHT2mLRnwdKEMhKGLHY J0zh/Pa61c9B9PbZLQlKrnUbacj+bvJxHdl3eevSQPOOCI3dvO 2j2a0RKANKZ3khnaqugiWE3nqNd7UwaEbT4BAyOgfV5I4x4KTx 4/WFzwJaryaLJzHL/f4zUjxHYxJoJuulN8Yt4Gx8rMq/2V+U/J c+GJkWhoJkrkQ== Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 17:08:57 -0000 Hi Ben, On Apr 27, 2012, at 5:32 PM, Ben Longden wrote: > Hi all, >=20 > 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). =46rom 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 >=20 > 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). >=20 > Name : Ben Longden >=20 > Email : ben@nocarrier.co.uk >=20 > MIME media type name : Application >=20 > MIME subtype name : Vendor Tree - vnd.error+xml >=20 > Required parameters : None >=20 > Optional parameters : None >=20 > Encoding considerations : binary >=20 > Security considerations :=20 > 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. >=20 > Interoperability considerations : None >=20 > Published specification : https://github.com/blongden/vnd.error >=20 > Applications which use this media : None >=20 > 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 >=20 > Person to contact for further information : > 1. Name : Ben Longden > 2. Email : ben@nocarrier.co.uk >=20 > Intended usage : Common > Author/Change controller : Ben Longden >=20 > -- > Ben Longden > http://nocarrier.co.uk >=20 > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C03021F86FE for ; Fri, 27 Apr 2012 08:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkPmRpvvzbyh for ; Fri, 27 Apr 2012 08:32:48 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F088B21F86E1 for ; Fri, 27 Apr 2012 08:32:47 -0700 (PDT) Received: by werb10 with SMTP id b10so638908wer.31 for ; Fri, 27 Apr 2012 08:32:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer:x-gm-message-state; bh=gVuT108cdNeVx5A1dOYD3NooohaPp6Oy/wP0g3Bemyk=; b=oMjCB/ovQQBelND7p1LxeU1rkMgMEBgyPZJ7Q1UR2pjQ7MMw7nd1JIn3dfFA3XxWbu YAIfVPPE0whQX/VrHVD++Q2JuIDNSLBFdcAiJzBAlnlSBWe+7sq6G2o7IpYVNEd2Mevn 3VkJe5efBTVAYaq5g/tGDoqvNRAqrho80ZUyqYRIKbk9aA5u59Wz6bYvvl6aaj63NkCZ 1U3EZb6AeskQaEY0dE+ntGjw72U0pacQdiS8g0tlggrkC53KtV2E8yq8GNInTiuHtr46 i4gcwTcPGj50wdYaFpX9/FByFCzNPtvIkEfVkso/oeodyt/ASC/C4IYqfL53DowKOO+V JbOA== Received: by 10.216.132.75 with SMTP id n53mr7041127wei.51.1335540767029; Fri, 27 Apr 2012 08:32:47 -0700 (PDT) Received: from [192.168.1.27] (ip-81-23-63-2.ask4internet.com. [81.23.63.2]) by mx.google.com with ESMTPS id o2sm8497386wiv.11.2012.04.27.08.32.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 08:32:46 -0700 (PDT) From: Ben Longden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Apr 2012 16:32:45 +0100 Message-Id: <7C70AEAE-52F9-4575-BF66-E348ADDF9DAD@nocarrier.co.uk> To: ietf-types@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmVMDWJRvbc0G770cERvFJkxQV9/dW83nNJBCs4EIu87Jx3uyDRUA3Nyz7BxjSK4BXzP2CP Subject: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 15:33:29 -0000 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 : ben@nocarrier.co.uk MIME media type name : Application MIME subtype name : Vendor Tree - vnd.error+xml Required parameters : None Optional parameters : None Encoding considerations : binary Security considerations :=20 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 : ben@nocarrier.co.uk Intended usage : Common Author/Change controller : Ben Longden -- Ben Longden http://nocarrier.co.uk Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AABD21E8028 for ; Thu, 26 Apr 2012 08:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.144 X-Spam-Level: X-Spam-Status: No, score=-106.144 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YUM+lIT-FHi for ; Thu, 26 Apr 2012 08:26:19 -0700 (PDT) Received: from pechora3.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 5497721E80AC for ; Thu, 26 Apr 2012 08:26:13 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id q3QFPqSZ017453 for ; Thu, 26 Apr 2012 15:26:12 GMT X-AuditID: c1b4fb2d-b7b76ae0000063d8-31-4f99656587ec Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0B.E4.25560.565699F4; Thu, 26 Apr 2012 17:10:29 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Thu, 26 Apr 2012 17:10:29 +0200 Message-ID: <4F99654A.5070600@ericsson.com> Date: Thu, 26 Apr 2012 17:10:02 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "'ietf-types@iana.org'" X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== X-Greylist: Delayed for 00:15:21 by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Thu, 26 Apr 2012 15:26:13 +0000 (UTC) Cc: "mmusic-chairs@tools.ietf.org" Subject: [ietf-types] Review of text/parameters X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:26:20 -0000 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 (magnus.westerlund@ericsson.com) Intended usage: Common Restrictions on usage: None Author: Magnus Westerlund (magnus.westerlund@ericsson.com) 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A1621F873A for ; Mon, 23 Apr 2012 08:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFyDlCxU8BO6 for ; Mon, 23 Apr 2012 08:44:29 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id DA89621F8730 for ; Mon, 23 Apr 2012 08:44:28 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id q3NFhtsY026604 for ; Mon, 23 Apr 2012 15:44:15 GMT Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D152240058; Mon, 23 Apr 2012 09:57:53 -0600 (MDT) Message-ID: <4F95789B.9060004@stpeter.im> Date: Mon, 23 Apr 2012 09:43:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?UTF-8?B?SmVzw7pzIEhlcm7DoW5kZXogR29ybWF6?= References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Mon, 23 Apr 2012 15:44:15 +0000 (UTC) Cc: ietf-types@iana.org Subject: Re: [ietf-types] Request of new MIME type for Python. X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:44:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 =dbVF -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2263921F8559 for ; Sun, 22 Apr 2012 15:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.903 X-Spam-Level: * X-Spam-Status: No, score=1.903 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=2.601, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cqqetwMu3Eh for ; Sun, 22 Apr 2012 15:35:40 -0700 (PDT) Received: from pechora6.dc.icann.org (unknown [IPv6:2620:0:2830:201::1:72]) by ietfa.amsl.com (Postfix) with ESMTP id 4C71A21F852D for ; Sun, 22 Apr 2012 15:35:40 -0700 (PDT) Received: from mail-yw0-f41.google.com (mail-yw0-f41.google.com [209.85.213.41]) by pechora6.dc.icann.org (8.13.8/8.13.8) with ESMTP id q3MMZJt7017135 for ; Sun, 22 Apr 2012 22:35:39 GMT Received: by yhr47 with SMTP id 47so6154074yhr.28 for ; Sun, 22 Apr 2012 15:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CjywEzFzyVzzm+W+U7hwYuW6vzneJX9ya0X/v9Ydy9g=; b=x4n1u509CONSHf2i0yY3pGbgREFY1EXGDm3lW+/i6zaPDD8ZgqHchivfDNfvcs8Y/I d4iyl8s06ppQGjbEvGr7Rt7PQdZCCfEkZqSbsdOScZMKCX6tcF8vJdYwLMYRazYjTIcL GJPRu1jTYl3zJ41GSdHlnCKLJG6ximEb7goYX9oWpbTg0SRmCtdBpMQTnfAKpFE9ZR70 vzjp59PGFa7a3M9FEUIPDXccWPhdnnQgyG6k6gr/F1pm07ehrB/4KjsgxMZ3jExRZS3A AEw42YSFws87hmx/Mk+M6JVr7EzczV5vvXHqzZydlfD868nZM4C7tM049VTvMoAvzw5K ze8w== MIME-Version: 1.0 Received: by 10.236.185.138 with SMTP id u10mr8304287yhm.106.1335134100415; Sun, 22 Apr 2012 15:35:00 -0700 (PDT) Received: by 10.236.143.33 with HTTP; Sun, 22 Apr 2012 15:35:00 -0700 (PDT) Date: Sun, 22 Apr 2012 23:35:00 +0100 Message-ID: From: =?UTF-8?B?SmVzw7pzIEhlcm7DoW5kZXogR29ybWF6?= To: ietf-types@iana.org Content-Type: multipart/alternative; boundary=20cf3056430dc8652404be4c21b2 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora6.dc.icann.org [192.0.46.72]); Sun, 22 Apr 2012 22:35:39 +0000 (UTC) X-Mailman-Approved-At: Mon, 23 Apr 2012 06:07:09 -0700 Subject: [ietf-types] Request of new MIME type for Python. X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 22:37:27 -0000 --20cf3056430dc8652404be4c21b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello I am Jes=C3=BAs Hern=C3=A1ndez 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. --=20 JHG. --20cf3056430dc8652404be4c21b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello I am Jes=C3=BAs = Hern=C3=A1ndez Gormaz, I would like=C2=A0to propose =C2=A0that=C2=A0the MIME type=C2=A0= text /=C2=A0x-python=C2=A0<= /span>pass=C2=A0to register with the
=C2=A0IANA=C2=A0and thus=C2=A0switch to a=C2=A0text /=C2= =A0python=C2=A0completelysta= ndard
=C2=A0and accepted.=C2=A0Also, as=C2=A0I guess=C2=A0will know, Python=C2=A0handles
=C2=A0files=C2=A0= .pyc=C2=A0besides the=C2=A0.py=C2=A0and= =C2=A0.pyc=C2=A0are your=C2=A0bytecode, so=C2=A0I
=C2=A0propose a=C2=A0typoappli= cation /=C2=A0x-python-bytecode=C2=A0to begin to
=C2=A0give these=C2=A0files=C2=A0its own MIME type=C2=A0,= =C2=A0and encou= rage=C2=A0as=C2=A0in the
=C2=A0previous ca= se=C2=A0to=C2=A0formalize=C2=A0an=C2=A0application /bytecode-python
=C2=A0as=C2=A0i= t seems important=C2=A0formalziar=C2=A0Python=C2=A0MIME= types.

Greetings.

--
JHG.

--20cf3056430dc8652404be4c21b2-- Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDE821F85B9 for ; Wed, 18 Apr 2012 08:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-KRrAGCMP2w for ; Wed, 18 Apr 2012 08:36:34 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 755B721F85C4 for ; Wed, 18 Apr 2012 08:36:34 -0700 (PDT) Received: by iazz13 with SMTP id z13so12914548iaz.31 for ; Wed, 18 Apr 2012 08:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:content-transfer-encoding:organization :user-agent; bh=JRjl8cw3E7umtG2yMftlSTM5DCh19ozo19I9vMnRRMQ=; b=jzfbsMCMTl10ongJm5bEhNeKxgh+8z6AH7QXL95SZgZ0C6Nk+OKw7Vp06HUcKb+cYE nBYtURqRYtlqjEWfyPZEyhJlvxlVxRconx9+WyTjCVyKGYXeJs3Iv6efbepet/QQKOJR 7F5elC8e2CuX0YQkrBU+q6OHz8g0LYN+n3/UDNEToPw2zg83IuHdWzhGwAQKV+QSoWtj /lTekzmz3uFZDFvCdRyya31JvZzO3/GLvyGuf2gp/5cNeSmLDRNPLCCI5c50rTfSpzzj ilTccPgwPMcN6b6VetUv5cHsov4/p6F81HAVclkk19cC5fmA8gbGv0JxDtAL1kt3a2L0 PYMQ== Received: by 10.42.215.68 with SMTP id hd4mr2040774icb.30.1334763394149; Wed, 18 Apr 2012 08:36:34 -0700 (PDT) Received: from w3.org (w3cdhcp76.w3.org. [128.30.55.203]) by mx.google.com with ESMTPS id ew6sm18481802igc.6.2012.04.18.08.36.33 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Apr 2012 08:36:33 -0700 (PDT) Sender: "Eric Prud'hommeaux" Date: Wed, 18 Apr 2012 11:36:30 -0400 From: Eric Prud'hommeaux To: ietf-types@ietf.org Message-ID: <20120418153629.GB29120@w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Organization: World Wide Web Consortium (W3C) - http://www.w3.org/ User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [ietf-types] Request for review of N-Triples (an RDF serialization) media type: application/n-triples X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 15:36:35 -0000 Hi all, we're about to publish a last call of an RDF representation called 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 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 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 Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9B021F8721 for ; Tue, 10 Apr 2012 01:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_5x7=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ne7b3pVTGssj for ; Tue, 10 Apr 2012 01:07:38 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AAF8721F8716 for ; Tue, 10 Apr 2012 01:07:37 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-c9-4f83ea48901a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B5.36.03534.84AE38F4; Tue, 10 Apr 2012 10:07:36 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Apr 2012 10:07:36 +0200 Message-ID: <4F83EA45.5050106@ericsson.com> Date: Tue, 10 Apr 2012 10:07:33 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <4F7C21F0.6020908@ericsson.com> <4F7D3967.20809@it.aoyama.ac.jp> <6F178BA1-04CD-4629-A0C9-C3B829213CC4@acmepacket.com> <2iasn79hpto657j8sdflqpt98psliig88g@hive.bjoern.hoehrmann.de> In-Reply-To: <2iasn79hpto657j8sdflqpt98psliig88g@hive.bjoern.hoehrmann.de> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Miguel Garcia A , "ietf-types@ietf.org" , Gonzalo Camarillo , Hadriel Kaplan , Flemming Andreasen , Robert Sparks Subject: Re: [ietf-types] Review of X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 08:07:38 -0000 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6D821F8622 for ; Fri, 6 Apr 2012 05:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlGLnLeDu2DQ for ; Fri, 6 Apr 2012 05:16:56 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7605D21F862A for ; Fri, 6 Apr 2012 05:16:56 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 6 Apr 2012 08:16:49 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.74]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Fri, 6 Apr 2012 08:16:49 -0400 From: Hadriel Kaplan To: Miguel Garcia A Thread-Topic: [ietf-types] Review of Thread-Index: AQHNEk2AXbRsLGUU40Co+nnEkMXldpaMBoSAgADef3OAAQ0OgIAACqkA Date: Fri, 6 Apr 2012 12:16:48 +0000 Message-ID: <9A021A28-11C1-4461-BF34-8360624F34CE@acmepacket.com> References: <4F7C21F0.6020908@ericsson.com> <4F7D3967.20809@it.aoyama.ac.jp> <6F178BA1-04CD-4629-A0C9-C3B829213CC4@acmepacket.com>, <2iasn79hpto657j8sdflqpt98psliig88g@hive.bjoern.hoehrmann.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "ietf-types@ietf.org" , Bjoern Hoehrmann , Gonzalo Camarillo , Flemming Andreasen , Robert Sparks Subject: Re: [ietf-types] Review of X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 12:16:57 -0000 Yup, will do! Thanks, -hadriel On Apr 6, 2012, at 7:38 AM, Miguel Garcia A wrote: > Thank you Bj=F6rn for your review. Please Hadriel, consider Bj=F6rn 's co= mments for the next version of the document. >=20 > /Miguel > ________________________________________ > From: Bjoern Hoehrmann [derhoermi@gmx.net] > Sent: Friday, April 06, 2012 1:30 AM > To: Hadriel Kaplan > Cc: Martin J. D=FCrst; ietf-types@ietf.org; Miguel Garcia A; Flemming And= reasen; Gonzalo Camarillo; Robert Sparks > Subject: Re: [ietf-types] Review of >=20 > * Hadriel Kaplan wrote: >> 13.2.1 audio/encaprtp >> Encoding considerations: This media type is framed >> binary data. >=20 > This should just say "framed". >=20 >> Published specification: This MIME type is described fully >> within this document. >=20 > 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. >=20 >> Person & email address to contact for further information: >>=20 >> Kaynam Hedayat >> EMail: kaynam.hedayat@exfo.com >=20 > The typical rendering is `Name `. >=20 >> Intended usage: COMMON >=20 > My impression is that RTP-only types typically use LIMITED USE, but I > might be mistaken about that. > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld= .de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= .de/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABAD21F8633 for ; Fri, 6 Apr 2012 04:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkjcwaovMGED for ; Fri, 6 Apr 2012 04:39:20 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 300B721F851B for ; Fri, 6 Apr 2012 04:39:19 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-a6-4f7ed5e6db80 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA) Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 94.CD.03534.6E5DE7F4; Fri, 6 Apr 2012 13:39:19 +0200 (CEST) Received: from ESESSCMS0364.eemea.ericsson.se ([169.254.1.68]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 6 Apr 2012 13:39:18 +0200 From: Miguel Garcia A To: Bjoern Hoehrmann , Hadriel Kaplan Date: Fri, 6 Apr 2012 13:38:39 +0200 Thread-Topic: [ietf-types] Review of Thread-Index: Ac0ThCR07AvzZIWzSee3EEQiyTmPggAZasRb Message-ID: References: <4F7C21F0.6020908@ericsson.com> <4F7D3967.20809@it.aoyama.ac.jp> <6F178BA1-04CD-4629-A0C9-C3B829213CC4@acmepacket.com>, <2iasn79hpto657j8sdflqpt98psliig88g@hive.bjoern.hoehrmann.de> In-Reply-To: <2iasn79hpto657j8sdflqpt98psliig88g@hive.bjoern.hoehrmann.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen , Robert Sparks , Gonzalo Camarillo , "ietf-types@ietf.org" Subject: Re: [ietf-types] Review of X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 11:39:21 -0000 Thank you Bj=F6rn for your review. Please Hadriel, consider Bj=F6rn 's comm= ents for the next version of the document. /Miguel ________________________________________ From: Bjoern Hoehrmann [derhoermi@gmx.net] Sent: Friday, April 06, 2012 1:30 AM To: Hadriel Kaplan Cc: Martin J. D=FCrst; ietf-types@ietf.org; Miguel Garcia A; Flemming Andre= asen; 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: kaynam.hedayat@exfo.com The typical rendering is `Name `. > Intended usage: COMMON My impression is that RTP-only types typically use LIMITED USE, but I might be mistaken about that. -- Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehrma= nn.de Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld.d= e 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d= e/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68ABD21F86C3 for ; Thu, 5 Apr 2012 16:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjXuCp0w86u7 for ; Thu, 5 Apr 2012 16:30:54 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 116E921F86B0 for ; Thu, 5 Apr 2012 16:30:53 -0700 (PDT) Received: (qmail invoked by alias); 05 Apr 2012 23:30:51 -0000 Received: from dslb-094-223-217-222.pools.arcor-ip.net (EHLO HIVE) [94.223.217.222] by mail.gmx.net (mp027) with SMTP; 06 Apr 2012 01:30:51 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/rJh8CRkHrFvTJcxKAN0K82x+hJ50xsaSbHLTdSY aHcP6YDiXqNsU3 From: Bjoern Hoehrmann To: Hadriel Kaplan Date: Fri, 06 Apr 2012 01:30:50 +0200 Message-ID: <2iasn79hpto657j8sdflqpt98psliig88g@hive.bjoern.hoehrmann.de> References: <4F7C21F0.6020908@ericsson.com> <4F7D3967.20809@it.aoyama.ac.jp> <6F178BA1-04CD-4629-A0C9-C3B829213CC4@acmepacket.com> In-Reply-To: <6F178BA1-04CD-4629-A0C9-C3B829213CC4@acmepacket.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "Miguel A. Garcia" , "ietf-types@ietf.org" , Gonzalo Camarillo , Flemming Andreasen , Robert Sparks Subject: Re: [ietf-types] Review of X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 23:30:55 -0000 * 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: kaynam.hedayat@exfo.com The typical rendering is `Name `. > 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:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6831321F8822 for ; Thu, 5 Apr 2012 05:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IddLHLL-U0Vq for ; Thu, 5 Apr 2012 05:04:04 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 21B3521F87AB for ; Thu, 5 Apr 2012 05:04:03 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 5 Apr 2012 08:03:59 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.74]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Thu, 5 Apr 2012 08:03:57 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= , "ietf-types@ietf.org" Thread-Topic: [ietf-types] Review of Thread-Index: AQHNEk2AXbRsLGUU40Co+nnEkMXldpaMBoSAgABgSQA= Date: Thu, 5 Apr 2012 12:03:57 +0000 Message-ID: <6F178BA1-04CD-4629-A0C9-C3B829213CC4@acmepacket.com> References: <4F7C21F0.6020908@ericsson.com> <4F7D3967.20809@it.aoyama.ac.jp> In-Reply-To: <4F7D3967.20809@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= X-Mailman-Approved-At: Thu, 05 Apr 2012 05:50:00 -0700 Cc: "Miguel A. Garcia" , Flemming Andreasen , Gonzalo Camarillo , Robert Sparks Subject: Re: [ietf-types] Review of X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 12:04:05 -0000 13.2.1 audio/encaprtp=20 =20 To: ietf-types@iana.org=20 Subject: Registration of media type audio/encaprtp=20 Type name: audio=20 Subtype name: encaprtp=20 Required parameters: =20 rate:RTP timestamp clock rate, which is equal to the=20 sampling rate. The typical rate is 8000; other rates=20 may be specified. =20 =20 Optional parameters: none=20 =20 Encoding considerations: This media type is framed =20 binary data.=20 Security considerations: See Section 12 of this document.=20 =20 Interoperability considerations: none=20 =20 Published specification: This MIME type is described fully=20 within this document.=20 =20 Applications which use this media type: Applications wishing=20 to monitor and ensure the quality of transport to the=20 edge of a given VoIP, Real-Time Text or Video Over IP=20 Service.=20 =20 Additional information: none=20 =20 Person & email address to contact for further information:=20 =20 Kaynam Hedayat=20 EMail: kaynam.hedayat@exfo.com=20 =20 Intended usage: COMMON=20 =20 Restrictions on usage: This media type depends on RTP=20 framing, and hence is only defined for transfer via=20 RTP. Transfer within other framing protocols is not=20 defined at this time. =20 =20 Author: =20 Kaynam Hedayat. =20 =20 Change controller: IETF Audio/Video Transport working=20 group delegated from the IESG.=20 =20 =20 13.2.2 video/encaprtp=20 =20 To: ietf-types@iana.org=20 =20 Subject: Registration of media type video/encaprtp=20 =20 Type name: video=20 =20 Subtype name: encaprtp=20 =20 Required parameters: =20 =20 rate:RTP timestamp clock rate, which is equal to the=20 sampling rate. The typical rate is 8000; other rates=20 may be specified. =20 =20 Optional parameters: none=20 =20 Encoding considerations: This media type is framed =20 binary data.=20 =20 Security considerations: See Section 12 of this document.=20 =20 Interoperability considerations: none=20 =20 Published specification: This MIME type is described fully=20 within this document.=20 =20 Applications which use this media type: Applications wishing=20 to monitor and ensure the quality of transport to the=20 edge of a given VoIP, Real-Time Text or Video Over IP=20 Service.=20 =20 Additional information: none=20 =20 Person & email address to contact for further information:=20 =20 Kaynam Hedayat=20 EMail: kaynam.hedayat@exfo.com=20 =20 Intended usage: COMMON=20 =20 Restrictions on usage: This media type depends on RTP=20 framing, and hence is only defined for transfer via=20 RTP. Transfer within other framing protocols is not=20 defined at this time. =20 =20 Author: =20 Kaynam Hedayat. =20 =20 Change controller: IETF Audio/Video Transport working=20 group delegated from the IESG.=20 =20 =20 13.2.3 text/encaprtp=20 =20 To: ietf-types@iana.org=20 =20 Subject: Registration of media type text/encaprtp=20 =20 Type name: text=20 =20 Subtype name: encaprtp=20 Required parameters: =20 =20 rate:RTP timestamp clock rate, which is equal to the=20 sampling rate. The typical rate is 8000; other rates=20 may be specified. =20 =20 Optional parameters: none=20 =20 Encoding considerations: This media type is framed =20 binary data.=20 =20 Security considerations: See Section 12 of this document.=20 =20 Interoperability considerations: none=20 =20 Published specification: This MIME type is described fully=20 within this document.=20 =20 Applications which use this media type: Applications wishing=20 to monitor and ensure the quality of transport to the=20 edge of a given VoIP, Real-Time Text or Video Over IP=20 Service.=20 =20 Additional information: none=20 =20 Person & email address to contact for further information:=20 =20 Kaynam Hedayat=20 EMail: kaynam.hedayat@exfo.com=20 =20 Intended usage: COMMON=20 =20 Restrictions on usage: This media type depends on RTP=20 framing, and hence is only defined for transfer via=20 RTP. Transfer within other framing protocols is not=20 defined at this time. =20 =20 Author: =20 Kaynam Hedayat. =20 =20 Change controller: IETF Audio/Video Transport working=20 group delegated from the IESG.=20 =20 =20 13.2.4 application/encaprtp=20 =20 To: ietf-types@iana.org=20 Subject: Registration of media type=20 application/encaprtp=20 =20 Type name: application=20 =20 Subtype name: encaprtp=20 =20 Required parameters: =20 =20 rate:RTP timestamp clock rate, which is equal to the=20 sampling rate. The typical rate is 8000; other rates=20 may be specified. =20 =20 Optional parameters: none=20 =20 Encoding considerations: This media type is framed =20 binary data.=20 =20 Security considerations: See Section 12 of this document.=20 =20 Interoperability considerations: none=20 =20 Published specification: This MIME type is described fully=20 within this document.=20 =20 Applications which use this media type: Applications wishing=20 to monitor and ensure the quality of transport to the=20 edge of a given VoIP, Real-Time Text or Video Over IP=20 Service.=20 =20 Additional information: none=20 =20 Person & email address to contact for further information:=20 =20 Kaynam Hedayat=20 EMail: kaynam.hedayat@exfo.com=20 =20 Intended usage: COMMON=20 =20 Restrictions on usage: This media type depends on RTP=20 framing, and hence is only defined for transfer via=20 RTP. Transfer within other framing protocols is not=20 defined at this time. =20 =20 Author: =20 Kaynam Hedayat. =20 =20 Change controller: IETF Audio/Video Transport working=20 group delegated from the IESG.=20 13.2.5 audio/rtploopback=20 =20 To: ietf-types@iana.org=20 =20 Subject: Registration of media type audio/rtploopback=20 =20 Type name: audio=20 =20 Subtype name: rtploopback=20 =20 Required parameters: =20 =20 rate:RTP timestamp clock rate, which is equal to the=20 sampling rate. The typical rate is 8000; other rates=20 may be specified. =20 =20 Optional parameters: none=20 =20 Encoding considerations: This media type is framed =20 binary data.=20 =20 Security considerations: See Section 12 of this document.=20 =20 Interoperability considerations: none=20 =20 Published specification: This MIME type is described fully=20 within this document.=20 =20 Applications which use this media type: Applications wishing=20 to monitor and ensure the quality of transport to the=20 edge of a given VoIP, Real-Time Text or Video Over IP=20 Service.=20 =20 Additional information: none=20 =20 Person & email address to contact for further information:=20 =20 Kaynam Hedayat=20 EMail: kaynam.hedayat@exfo.com=20 =20 Intended usage: COMMON=20 =20 Restrictions on usage: This media type depends on RTP=20 framing, and hence is only defined for transfer via=20 RTP. Transfer within other framing protocols is not=20 defined at this time. =20 =20 Author: =20 Kaynam Hedayat. =20 =20 Change controller: IETF Audio/Video Transport working=20 group delegated from the IESG.=20 =20 13.2.6 video/rtploopback=20 =20 To: ietf-types@iana.org=20 =20 Subject: Registration of media type video/rtploopback=20 =20 Type name: video=20 =20 Subtype name: rtploopback=20 =20 Required parameters: =20 =20 rate:RTP timestamp clock rate, which is equal to the=20 sampling rate. The typical rate is 8000; other rates=20 may be specified. =20 =20 Optional parameters: none=20 =20 Encoding considerations: This media type is framed =20 binary data.=20 =20 Security considerations: See Section 12 of this document.=20 =20 Interoperability considerations: none=20 =20 Published specification: This MIME type is described fully=20 within this document.=20 =20 Applications which use this media type: Applications wishing=20 to monitor and ensure the quality of transport to the=20 edge of a given VoIP, Real-Time Text or Video Over IP=20 Service.=20 =20 Additional information: none=20 =20 Person & email address to contact for further information:=20 =20 Kaynam Hedayat=20 EMail: kaynam.hedayat@exfo.com=20 =20 Intended usage: COMMON=20 =20 Restrictions on usage: This media type depends on RTP=20 framing, and hence is only defined for transfer via=20 RTP. Transfer within other framing protocols is not=20 defined at this time. =20 =20 Author: =20 Kaynam Hedayat. =20 =20 Change controller: IETF Audio/Video Transport working=20 group delegated from the IESG.=20 =20 =20 13.2.7 text/rtploopback=20 =20 To: ietf-types@iana.org=20 =20 Subject: Registration of media type text/rtploopback=20 =20 Type name: text=20 =20 Subtype name: rtploopback=20 =20 Required parameters: =20 =20 rate:RTP timestamp clock rate, which is equal to the=20 sampling rate. The typical rate is 8000; other rates=20 may be specified. =20 =20 Optional parameters: none=20 =20 Encoding considerations: This media type is framed =20 binary data.=20 =20 Security considerations: See Section 12 of this document.=20 =20 Interoperability considerations: none=20 =20 Published specification: This MIME type is described fully=20 within this document.=20 =20 Applications which use this media type: Applications wishing=20 to monitor and ensure the quality of transport to the=20 edge of a given VoIP, Real-Time Text or Video Over IP=20 Service.=20 =20 Additional information: none=20 =20 Person & email address to contact for further information:=20 =20 Kaynam Hedayat=20 EMail: kaynam.hedayat@exfo.com=20 Intended usage: COMMON=20 =20 Restrictions on usage: This media type depends on RTP=20 framing, and hence is only defined for transfer via=20 RTP. Transfer within other framing protocols is not=20 defined at this time. =20 =20 Author: =20 Kaynam Hedayat. =20 =20 Change controller: IETF Audio/Video Transport working=20 group delegated from the IESG.=20 =20 =20 13.2.8 application/rtploopback=20 =20 To: ietf-types@iana.org=20 =20 Subject: Registration of media type=20 application/rtploopback=20 =20 Type name: application=20 =20 Subtype name: rtploopback=20 =20 Required parameters: =20 =20 rate:RTP timestamp clock rate, which is equal to the=20 sampling rate. The typical rate is 8000; other rates=20 may be specified. =20 =20 Optional parameters: none=20 =20 Encoding considerations: This media type is framed =20 binary data.=20 =20 Security considerations: See Section 12 of this document.=20 =20 Interoperability considerations: none=20 =20 Published specification: This MIME type is described fully=20 within this document.=20 =20 Applications which use this media type: Applications wishing=20 to monitor and ensure the quality of transport to the=20 edge of a given VoIP, Real-Time Text or Video Over IP=20 Service.=20 Additional information: none=20 =20 Person & email address to contact for further information:=20 =20 Kaynam Hedayat=20 EMail: kaynam.hedayat@exfo.com=20 =20 Intended usage: COMMON=20 =20 Restrictions on usage: This media type depends on RTP=20 framing, and hence is only defined for transfer via=20 RTP. Transfer within other framing protocols is not=20 defined at this time. =20 =20 Author: =20 Kaynam Hedayat. =20 =20 Change controller: IETF Audio/Video Transport working=20 group delegated from the IESG.=20 On Apr 5, 2012, at 2:19 AM, Martin J. D=FCrst wrote: > Hello Miguel, >=20 > Please post the registration templates here. This gives you a *much* high= er chance of getting good comments. >=20 > Regards, Martin. >=20 > On 2012/04/04 19:26, Miguel A. Garcia wrote: >> Hi, >>=20 >> The MMUSIC working group is running the WGLC of >> draft-ietf-mmusic-media-loopback-18.txt, available at: >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback/ >>=20 >> The draft registers 8 new media types. Please refer to Section 13.2 in >> the draft: >>=20 >> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-18#section-1= 3.2 >>=20 >> We will appreciate if you can review the registration and provide us >> with comments. >>=20 >> Thanks, >>=20 >> Miguel Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E54B11E80FB for ; Thu, 5 Apr 2012 00:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.865 X-Spam-Level: X-Spam-Status: No, score=-97.865 tagged_above=-999 required=5 tests=[AWL=1.925, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Qhacdo+cfAG for ; Thu, 5 Apr 2012 00:17:21 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id B33A311E8079 for ; Thu, 5 Apr 2012 00:17:20 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q357HFo0025307 for ; Thu, 5 Apr 2012 16:17:15 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 2c6e_8545_5efca3a0_7eef_11e1_aa6a_001d096c566a; Thu, 05 Apr 2012 16:17:14 +0900 Received: from [IPv6:::1] ([133.2.210.1]:37831) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 5 Apr 2012 16:17:19 +0900 Message-ID: <4F7D3967.20809@it.aoyama.ac.jp> Date: Thu, 05 Apr 2012 15:19:19 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <4F7C21F0.6020908@ericsson.com> In-Reply-To: <4F7C21F0.6020908@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , Robert Sparks , Gonzalo Camarillo , Hadriel Kaplan , ietf-types@ietf.org Subject: Re: [ietf-types] Review of X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 07:17:21 -0000 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 Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B0521F84F8 for ; Wed, 4 Apr 2012 05:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MIuBRyZtz27 for ; Wed, 4 Apr 2012 05:01:34 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 56DB421F84F5 for ; Wed, 4 Apr 2012 05:01:34 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-b2-4f7c381ddbd2 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA) Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9D.CF.25560.D183C7F4; Wed, 4 Apr 2012 14:01:33 +0200 (CEST) Received: from [131.160.126.161] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012 14:01:32 +0200 Message-ID: <4F7C381B.5070506@ericsson.com> Date: Wed, 4 Apr 2012 15:01:31 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "ietf-types@ietf.org" References: <4F7C21F0.6020908@ericsson.com> In-Reply-To: <4F7C21F0.6020908@ericsson.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Miguel Garcia A , Flemming Andreasen , Hadriel Kaplan , Robert Sparks Subject: Re: [ietf-types] Review of draft-ietf-mmusic-media-loopback-18.txt X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 12:01:35 -0000 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 Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200EB21F8620 for ; Wed, 4 Apr 2012 03:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulxFK6TtptvJ for ; Wed, 4 Apr 2012 03:27:00 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 687E421F861D for ; Wed, 4 Apr 2012 03:27:00 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-60-4f7c21f3e6b6 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA) Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5D.1A.25560.3F12C7F4; Wed, 4 Apr 2012 12:26:59 +0200 (CEST) Received: from [159.107.48.214] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012 12:26:58 +0200 Message-ID: <4F7C21F0.6020908@ericsson.com> Date: Wed, 4 Apr 2012 12:26:56 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 04 Apr 2012 06:52:53 -0700 Cc: Flemming Andreasen , Gonzalo Camarillo , Hadriel Kaplan , Robert Sparks Subject: [ietf-types] Review of X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 10:27:01 -0000 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