Re: [apps-discuss] type name suffixes

Peter Saint-Andre <stpeter@stpeter.im> Wed, 16 November 2011 02:25 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E8711E818F for <apps-discuss@ietfa.amsl.com>; Tue, 15 Nov 2011 18:25:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.812
X-Spam-Level:
X-Spam-Status: No, score=-102.812 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, 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 RapLo9p1hbSV for <apps-discuss@ietfa.amsl.com>; Tue, 15 Nov 2011 18:25:37 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DC61F11E80EE for <apps-discuss@ietf.org>; Tue, 15 Nov 2011 18:25:37 -0800 (PST)
Received: from dhcp-15ab.meeting.ietf.org (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6E28B4214E; Tue, 15 Nov 2011 19:31:51 -0700 (MST)
Message-ID: <4EC31F1E.6070304@stpeter.im>
Date: Wed, 16 Nov 2011 10:25:34 +0800
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Larry Masinter <masinter@adobe.com>
References: <4EB86078.8070904@stpeter.im> <BDC0F178EEB88CC4B3D24020@PST.JCK.COM> <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <4EBB2B83.3060901@it.aoyama.ac.jp> <01O88AB2EM7S00RCTX@mauve.mrochek.com> <4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com> <4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im> <01O8EWMK2T8E00RCTX@mauve.mrochek.com> <4EC2DC42.7010307@stpeter.im> <01O8GE5O3B5K00RCTX@mauve.mrochek.com> <C68CB012D9182D408CED7B884F441D4D0611DAC31D@nambxv01a.corp.adobe.com>
In-Reply-To: <C68CB012D9182D408CED7B884F441D4D0611DAC31D@nambxv01a.corp.adobe.com>
X-Enigmail-Version: 1.3.3
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Ned Freed <ned.freed@mrochek.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] type name suffixes
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2011 02:25:42 -0000

On 11/16/11 10:14 AM, Larry Masinter wrote:

> I believe that the suffix +xml has an important function as an
> indicator that the body of the content is suitable for generic XML
> processing, for example, in the use of XPointer as a fragment
> identifier, and the ability to use a generic XML parser to scan the
> content. The expectation is that Media types that end in +xml are, in
> fact, restricted to only contain content that fits, and that RFC 3023
> (and RFC 3023bis in preparation) defines that meaning and establishes
> that requirement.
> 
> The URI specification defers the interpretation of fragment
> identifiers (#xxx at the end of a URI) to the definition of the media
> type of the retrieved content.
> 
> The reason for holding back on other +xxx typename suffix is only to
> insure that there is a clear definition for what expectation there
> might be for common processing techniques and fragment
> identifiers....  that is, there is an operational requirement and
> definition, not just a vague "feel good".
> 
> So, for example,  type/subtype+json content labeled with a +json
> media type should be restricted, for example, to content that can be
> updated with json-patch PATCH operations, and generic json
> processing.
> 
> I think a separate specification for what the generic processing
> requirements and compatibility should be strongly recommended. It's
> not just a "feel good sounds right" matter.

Larry, that is helpful.

To be clear, the two suffixes I've seen interest in are:

+json = <http://tools.ietf.org/html/rfc4627>

+exi = <http://www.w3.org/TR/2011/REC-exi-20110310/>

We do need to take these on a case-by-case basis and we need to define
them clearly, but I doubt that we will see a flood of them.

Peter

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