Re: [apps-discuss] type name suffixes

Larry Masinter <> Wed, 16 November 2011 02:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D340721F8DEF for <>; Tue, 15 Nov 2011 18:15:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.275
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WkhKr0D3g7Ye for <>; Tue, 15 Nov 2011 18:15:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id F12A821F8DEC for <>; Tue, 15 Nov 2011 18:15:19 -0800 (PST)
Received: from ([]) by ([]) with SMTP ID; Tue, 15 Nov 2011 18:15:20 PST
Received: from ( []) by (8.12.10/8.12.10) with ESMTP id pAG2EoZc015406; Tue, 15 Nov 2011 18:14:51 -0800 (PST)
Received: from ( []) by (8.12.10/8.12.10) with ESMTP id pAG2Eo5R021491; Tue, 15 Nov 2011 18:14:50 -0800 (PST)
Received: from ([]) by ([]) with mapi; Tue, 15 Nov 2011 18:14:50 -0800
From: Larry Masinter <>
To: Ned Freed <>, Peter Saint-Andre <>
Date: Tue, 15 Nov 2011 18:14:47 -0800
Thread-Topic: [apps-discuss] type name suffixes
Thread-Index: Acyj80bY/md1a688QAGsLSWP530vxQAEUVpw
Message-ID: <>
References: <> <BDC0F178EEB88CC4B3D24020@PST.JCK.COM> <> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [apps-discuss] type name suffixes
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


-----Original Message-----
From: [] On Behalf Of Ned Freed
Sent: Wednesday, November 16, 2011 8:01 AM
To: Peter Saint-Andre
Cc: Ned Freed;
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.

apps-discuss mailing list