Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-media-type-suffix-regs

From: Tony Hansen <[email-masked]>
Date: Tue, 17 Jul 2012 01:26:04 -0400

Mark, the suffix-regs doc is mostly trying to document the rules under 
which existing suffixes have been informally permitted in the past and 
provide a more formal basis for them to be used in the future. Except 
for +ber, +der and +zip, there are already examples of the other 
suffixes mentioned in this document. For example, in addition to all of 
the +xml media types, consider all of these media types that are already 
being used:

     application/soap+fastinfoset
     application/vnd.collection+json
     application/vnd.hal+json
     application/vnd.oftn.l10n+json
     application/vnd.nokia.conml+wbxml
     application/vnd.nokia.landmark+wbxml
     application/vnd.nokia.pcd+wbxml
     application/vnd.syncml.dm+wbxml
     application/vnd.wv.csp+wbxml

You ask about the guidance being provided to the Expert Reviewers in the 
media type registry document. That advice is expanded on by the 
media-type-suffix-regs document; Expert Reviewers should consider both 
pieces of guidance. (One can argue that the additional guidance in this 
document should have been in the other document; for various reasons it 
didn't happen.)

And yes, the gateway is being protected by an Expert Reviewer. But 
that's been true for them in the past, as well as all of the media types 
in general. I don't see anyone being to drive a tank through that 
gateway any more easily now than they have in the past. As an example of 
a recently proposed media type suffix that did *not* pass muster, 
consider +exi.

     Tony Hansen

On 6/25/2012 1:52 AM, Mark Nottingham wrote:
> I still haven't seen a satisfying answer to my questions about how this is actually going to be used. They may be out there, but I can't escape the feeling that people are going along with this because it "seems like a good idea", and I'm concerned that the implications of allowing a multitude of suffixes -- thereby effectively adding another dimension of identity to our format identifiers -- hasn't been properly considered.
>
> I'm especially concerned because, as I noted in my review of the media type registrations document, there isn't any discussion of appropriate vs. inappropriate use in this registry; the only guidance given to the experts for this registry is:
>
>>     The primary guideline for whether a structured type name suffix is
>>     registrable is that it be described by a readily-available
>>     description, preferably within a document published by an established
>>     standards organization, and for which there's a reference that can be
>>     used in a Normative References section of an RFC.
> Now, if that isn't a hole that you can drive a tank through, I don't know what is (BTW, the media types registration document doesn't even explicitly specify a policy for this registry; it appears to be Expert Review).
>
> E.g., the recent +merge-patch suffix proposal. If James had chosen to pursue that, on what grounds could the Expert (whoever that will be) reject the proposal?
>
> I realise this document is only a shell for registering the suffixes, rather than their registration, but I still haven't seen any meaningful response to the concerns that I brought up, first in review of the media type registrations document, and later in separate e-mail.
>
> Regards,
>
>
> On 20/06/2012, at 4:15 PM, Murray S. Kucherawy wrote:
>
>> On Mon, Jun 11, 2012 at 5:25 AM, Murray S. Kucherawy <[email-masked]> wrote:
>> This note begins a Working Group Last Call on draft-ietf-appsawg-media-type-suffix-regs, ending Monday, June 25.  Please review the document and comment on it.
>>
>> Note that its "parent" document, draft-ietf-appsawg-media-type-regs, is now in IESG Evaluation.
>>
>>   
>> A reminder that this WGLC closes in less than a week.  Please review the document and send your comments soon.
>>
>> Thanks,
>> -MSK, APPSAWG co-chair
>>
>> _______________________________________________
>> apps-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Tony Hansen <[email-masked]>
Date: Tue, 17 Jul 2012 01:28:57 -0400

I incorporated this text almost verbatim into 
draft-ietf-appsawg-media-type-suffix-regs-02.

     Tony Hansen

On 6/21/2012 2:48 PM, Henry S. Thompson wrote:
> I didn't read it that way.  It quite specifically circumscribes what a
> particular xxx+json registration should do.  The phrasing is perhaps a
> little too concise.  I believe what we should be aiming for, which I
> believe this is trying to say, consistent with the best practices under
> development by the W3C TAG, is as follows
>
>    a) Syntax and semantics of fragids specified for +SUF should be same
>        as specified for xxx/SUF
>    b) Syntax and semantics for fragids for a specific xxx/yyy+SUF as
>        follows:
>         b1) For cases defined in +SUF, where the fragid resolves per
>              the +SUF rules, then as specified in +SUF
>         b2) For cases defined in +SUF, where the fragid _doesn't_ resolve per
>              the +SUF rules, then as specified in xxx/yyy+SUF
>         b3) For cases not defined in +SUF, then as specified in xxx/yyy+SUF
>
> Is that better?
>
> ht

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 19 Jul 2012 10:36:02 +1000

On 17/07/2012, at 3:26 PM, Tony Hansen wrote:

> Mark, the suffix-regs doc is mostly trying to document the rules under which existing suffixes have been informally permitted in the past and provide a more formal basis for them to be used in the future. Except for +ber, +der and +zip, there are already examples of the other suffixes mentioned in this document. For example, in addition to all of the +xml media types, consider all of these media types that are already being used:
> 
> You ask about the guidance being provided to the Expert Reviewers in the media type registry document. That advice is expanded on by the media-type-suffix-regs document;

Where? I'm talking about guidance for new suffixes, not new media types using existing suffixes.

> Expert Reviewers should consider both pieces of guidance. (One can argue that the additional guidance in this document should have been in the other document; for various reasons it didn't happen.)
> 
> And yes, the gateway is being protected by an Expert Reviewer. But that's been true for them in the past, as well as all of the media types in general. I don't see anyone being to drive a tank through that gateway any more easily now than they have in the past. As an example of a recently proposed media type suffix that did *not* pass muster, consider +exi.

*sigh*

We can, and should, do better than this.