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

Jan Algermissen <jan.algermissen@nordsc.com> Fri, 27 April 2012 17:08 UTC

Return-Path: <jan.algermissen@nordsc.com>
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 <ietf-types@ietfa.amsl.com>; 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 <ietf-types@ietfa.amsl.com>; 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 <ietf-types@ietf.org>; 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 <jan.algermissen@nordsc.com>
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 <ben@nocarrier.co.uk>
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" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=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,
> 
> I'm currently in the process of getting these two mime types registered - a blog post introducing the mime type is available at http://nocarrier.co.uk/2012/04/the-error-hypermedia-type/ and the standard itself is available at https://github.com/blongden/vnd.error

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

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

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

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

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


Jan



> 
> I'm looking for any feedback you may have to offer at this stage (changes, enhancements etc). The registration is as follows (I have only included the xml variant here - the json one has a sub mimetype name of vnd.error+json - otherwise the registration is identical).
> 
> Name : Ben Longden
> 
> Email : 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 : 
> 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
> 
> _______________________________________________
> ietf-types mailing list
> ietf-types@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-types