Re: [apps-discuss] type name suffixes
Larry Masinter <masinter@adobe.com> Wed, 16 November 2011 02:15 UTC
Return-Path: <masinter@adobe.com>
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 D340721F8DEF for <apps-discuss@ietfa.amsl.com>; Tue, 15 Nov 2011 18:15:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.275
X-Spam-Level:
X-Spam-Status: No, score=-106.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, 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 WkhKr0D3g7Ye for <apps-discuss@ietfa.amsl.com>; Tue, 15 Nov 2011 18:15:20 -0800 (PST)
Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id F12A821F8DEC for <apps-discuss@ietf.org>; Tue, 15 Nov 2011 18:15:19 -0800 (PST)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKTsMcnFlZb7NOeUpFylelaLCQcgeYNyi5@postini.com; Tue, 15 Nov 2011 18:15:20 PST
Received: from inner-relay-1.corp.adobe.com (ms-exchange.macromedia.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pAG2EoZc015406; Tue, 15 Nov 2011 18:14:51 -0800 (PST)
Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pAG2Eo5R021491; Tue, 15 Nov 2011 18:14:50 -0800 (PST)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Tue, 15 Nov 2011 18:14:50 -0800
From: Larry Masinter <masinter@adobe.com>
To: Ned Freed <ned.freed@mrochek.com>, Peter Saint-Andre <stpeter@stpeter.im>
Date: Tue, 15 Nov 2011 18:14:47 -0800
Thread-Topic: [apps-discuss] type name suffixes
Thread-Index: Acyj80bY/md1a688QAGsLSWP530vxQAEUVpw
Message-ID: <C68CB012D9182D408CED7B884F441D4D0611DAC31D@nambxv01a.corp.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>
In-Reply-To: <01O8GE5O3B5K00RCTX@mauve.mrochek.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "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:15:22 -0000
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 -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Ned Freed Sent: Wednesday, November 16, 2011 8:01 AM To: Peter Saint-Andre Cc: Ned Freed; apps-discuss@ietf.org Subject: Re: [apps-discuss] type name suffixes > > > The reason I ask is that I've had a few people ask me about this > > > topic recently. > > Well, the preferable thing would be to get the process Tony defined > > that I included in 4288bis approved. Absent that, the rule is more > > or less that you can use a suffix if you like and if it seems to make sense. > Thanks for the clarification. I agree that the right place to define > this more carefully is 4288bis. Yes, and that text is already in 4288bis. Please have a look and see if you think it is OK - there have been very few comments on it. In the meantime, let's say that someone > wants to register "application/foo+bar" -- do we feel that they need > to describe the "+bar" suffix in a separate specification, or can they > simply go ahead and use the suffix in the I-D that registers the "foo" > application, perhaps along with some explanatory text? I'd reccomment including some explanatory text saying where the format associated with the suffix is defined, but I see no need for a separate specification. In fact the 4288bis approach is specifically intended to make a separate specification unnecessary. Ned _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Graham Klyne
- Re: [apps-discuss] font/* Eric Burger
- Re: [apps-discuss] font/* Eric Burger
- [apps-discuss] font/* Peter Saint-Andre
- Re: [apps-discuss] font/* Dave CROCKER
- Re: [apps-discuss] font/* John C Klensin
- Re: [apps-discuss] font/* Mark Nottingham
- Re: [apps-discuss] font/* Peter Saint-Andre
- Re: [apps-discuss] font/* t.petch
- Re: [apps-discuss] font/* Mykyta Yevstifeyev (М. Євстіфеєв)
- Re: [apps-discuss] font/* Murray S. Kucherawy
- Re: [apps-discuss] font/* Murray S. Kucherawy
- Re: [apps-discuss] font/* John C Klensin
- Re: [apps-discuss] font/* Graham Klyne
- Re: [apps-discuss] font/* Barry Leiba
- Re: [apps-discuss] font/* Julian Reschke
- Re: [apps-discuss] font/* Murray S. Kucherawy
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Dave CROCKER
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Julian Reschke
- Re: [apps-discuss] font/* John C Klensin
- Re: [apps-discuss] font/* Peter Saint-Andre
- Re: [apps-discuss] font/* Peter Saint-Andre
- Re: [apps-discuss] font/* Paul Hoffman
- Re: [apps-discuss] font/* Lyndon Nerenberg
- Re: [apps-discuss] font/* Julian Reschke
- Re: [apps-discuss] font/* Eric Burger
- Re: [apps-discuss] font/* John C Klensin
- Re: [apps-discuss] font/* Peter Saint-Andre
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Bjoern Hoehrmann
- Re: [apps-discuss] font/* Dave CROCKER
- Re: [apps-discuss] font/* Dave CROCKER
- Re: [apps-discuss] font/* Bjoern Hoehrmann
- Re: [apps-discuss] font/* John C Klensin
- Re: [apps-discuss] font/* Ned Freed
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Dave CROCKER
- Re: [apps-discuss] font/* Tony Hansen
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Julian Reschke
- Re: [apps-discuss] font/* Barry Leiba
- Re: [apps-discuss] font/* t.petch
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Frank Ellermann
- Re: [apps-discuss] font/* Ned Freed
- Re: [apps-discuss] font/* t.petch
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Ned Freed
- Re: [apps-discuss] font/* Graham Klyne
- Re: [apps-discuss] font/* t.petch
- Re: [apps-discuss] font/* Tony Hansen
- Re: [apps-discuss] font/* Julian Reschke
- [apps-discuss] 答复: font/* TianLinyi
- Re: [apps-discuss] font/* Tony Hansen
- Re: [apps-discuss] 答复: font/* Tony Hansen
- Re: [apps-discuss] font/* Nathaniel Borenstein
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Martin J. Dürst
- [apps-discuss] type name suffixes (was: Re: font/… Peter Saint-Andre
- Re: [apps-discuss] 答复: font/* Vinayak Hegde
- Re: [apps-discuss] font/* Ned Freed
- Re: [apps-discuss] type name suffixes (was: Re: f… Ned Freed
- Re: [apps-discuss] font/* t.petch
- Re: [apps-discuss] type name suffixes Peter Saint-Andre
- Re: [apps-discuss] type name suffixes Ned Freed
- Re: [apps-discuss] type name suffixes Larry Masinter
- Re: [apps-discuss] type name suffixes Peter Saint-Andre
- Re: [apps-discuss] type name suffixes Bjoern Hoehrmann
- [apps-discuss] +exi (was: Re: type name suffixes) Peter Saint-Andre
- Re: [apps-discuss] +exi (was: Re: type name suffi… Bjoern Hoehrmann
- Re: [apps-discuss] +exi Peter Saint-Andre
- Re: [apps-discuss] +exi (was: Re: type name suffi… Zach Shelby
- Re: [apps-discuss] +exi (was: Re: type name suffi… Mark Nottingham
- Re: [apps-discuss] +exi (was: Re: type name suffi… Carsten Bormann
- Re: [apps-discuss] +exi (was: Re: type name suffi… Mark Nottingham
- Re: [apps-discuss] +exi (was: Re: type name suffi… Zach Shelby
- Re: [apps-discuss] +exi (was: Re: type name suffi… Mark Nottingham
- Re: [apps-discuss] +exi Peter Saint-Andre
- Re: [apps-discuss] +exi SM
- Re: [apps-discuss] +exi Peter Saint-Andre
- Re: [apps-discuss] +exi Julian Reschke
- Re: [apps-discuss] +exi Carine Bournez
- Re: [apps-discuss] +exi Peter Saint-Andre
- Re: [apps-discuss] +exi Mark Nottingham
- Re: [apps-discuss] +exi Carine Bournez
- Re: [apps-discuss] +exi Paul Duffy
- Re: [apps-discuss] +exi Thomas Herbst
- Re: [apps-discuss] +exi Zach Shelby
- Re: [apps-discuss] +exi Peter Saint-Andre
- Re: [apps-discuss] +exi Peter Saint-Andre
- Re: [apps-discuss] +exi Paul E. Jones
- Re: [apps-discuss] +exi Carine Bournez
- Re: [apps-discuss] +exi Zach Shelby
- Re: [apps-discuss] +exi Martin Thomson
- Re: [apps-discuss] font/* t.petch
- Re: [apps-discuss] +exi Paul Duffy
- Re: [apps-discuss] +exi psaintan
- Re: [apps-discuss] +exi Zach Shelby
- Re: [apps-discuss] +exi Paul Duffy
- Re: [apps-discuss] +exi Peter Saint-Andre
- Re: [apps-discuss] +exi Bjoern Hoehrmann
- Re: [apps-discuss] +exi Henry S. Thompson
- Re: [apps-discuss] +exi Ned Freed
- Re: [apps-discuss] +exi Bjoern Hoehrmann
- Re: [apps-discuss] +exi Ned Freed