Re: [apps-discuss] type name suffixes

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