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

Ben Longden <> Sat, 28 April 2012 21:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27B8321F8624 for <>; Sat, 28 Apr 2012 14:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.69
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YRqRnPcDv03n for <>; Sat, 28 Apr 2012 14:09:48 -0700 (PDT)
Received: from ( []) by (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;; 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 with SMTP id n18mr9688154wei.81.1335647386986; Sat, 28 Apr 2012 14:09:46 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id b3sm15649217wib.4.2012. (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: <>
Date: Sat, 28 Apr 2012 22:09:45 +0100
Message-Id: <>
References: <> <>
To: Jan Algermissen <>
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQlXT7G1kmbt6wkJ8+W1p597U/JFqq01A6OPfKNv1FYlC3XZ3ftoTxsu8r4w9kJmk8PLz/Oj
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: Sat, 28 Apr 2012 21:09:50 -0000

Hi Jan,

Thanks for your comments.

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

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

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

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

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

There are approved examples of excluding the vendor name from the vnd tree, ( 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.