Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json

Jan Algermissen <> Sun, 29 April 2012 00:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C734521F85D4 for <>; Sat, 28 Apr 2012 17:29:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.919
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7ANcBMrnYjZw for <>; Sat, 28 Apr 2012 17:29:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B23C021F85D2 for <>; Sat, 28 Apr 2012 17:29:29 -0700 (PDT)
Received: from [] ( []) by (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: <> <> <>
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==
Subject: Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json
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,
> Thanks for your comments.
>> If I understand your intention correctly, these two media types are specifically designed to support the anti pattern of tunneling application specific semantics through HTTP.
> I understand what you're saying... But I don't know how to respond to that. You could argue that point about any media type... How could you get application specific semantics from the server to the client without using HTTP?

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

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

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

> Even your example below is doing that.

How so?

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

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

>> The error communicated of an HTTP error response is specifically indicated by the HTTP status codes (4xx and 5xx). If you feel you need more specific error semantics, you are probably applying HTTP in the wrong way (as a transport to tunnel application semantics).
> I am absolutely advocating the use of the HTTP status code - that's why I have excluded it from the proposed media type(s).
>> From the POV of playing nice with Web architecture I suggest you think about designing proper resource semantics instead.
>> Regarding the name vnd.error... I think this is an incorrect naming pattern in the vnd-tree, please check.
> There are approved examples of excluding the vendor name from the vnd tree, ( 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.

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


> BenLongden