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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 Jun 2012 05:25:40 -0700

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.

Thanks,
-MSK, APPSAWG co-chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 Jun 2012 23:15:06 -0700

On Mon, Jun 11, 2012 at 5:25 AM, Murray S. Kucherawy <[email-masked]>wrote:

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Jun 2012 16:18:55 +0100

On 20/06/2012 07:15, Murray S. Kucherawy wrote:
> On Mon, Jun 11, 2012 at 5:25 AM, Murray S. Kucherawy 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     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.

I've just reviewed the document. I think it looks quite reasonable in 
general. I have 1 (and maybe one more later) question:

3.1.  The +json Structured Syntax Suffix

    Fragment identifier considerations: Media types using "+json" SHOULD
                        process any fragment identifiers defined for
                        "application/json" in the same way as defined for
                        that media type.  (At publication of this
                        document, there is no fragment identification
                        syntax defined for "application/json".) Specific
                        media types using "+json" MAY identify additional
                        fragment identifier considerations, MAY define
                        processing for fragment identifiers that are
                        classed as errors for "application/json" and MAY
                        designate fragment identifiers defined for
                        "application/json" that SHOULD NOT be used.

Are you trying to say that a specific <media-type>+json can do arbitrary 
changes to the rules for handling of fragment identifiers when compared 
to the media type it is based on? Is there a feeling for what is more 
likely: <media-type>+json defines a more restricted fragment identifier 
syntax or it defines a richer one?

(Similar text for a couple of other suffixes being registered in the 
same document.)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 21 Jun 2012 11:07:01 -0700

On Thu, Jun 21, 2012 at 8:18 AM, Alexey Melnikov
<[email-masked]>wrote:

> [...]

Also, I think that this document (like its parent) should have BCP status.

-MSK

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 21 Jun 2012 19:48:14 +0100

Alexey Melnikov <[email-masked]> writes:

> Are you trying to say that a specific <media-type>+json can do
> arbitrary changes to the rules for handling of fragment identifiers
> when compared to the media type it is based on? Is there a feeling for
> what is more likely: <media-type>+json defines a more restricted
> fragment identifier syntax or it defines a richer one?
>

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
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 22 Jun 2012 17:32:09 +0100

On 21/06/2012 19:48, Henry S. Thompson wrote:
> Alexey Melnikov<[email-masked]>  writes:
>
>> Are you trying to say that a specific<media-type>+json can do
>> what is more likely:<media-type>+json defines a more restricted
Yes, I think so. I think the current set of restrictions/recommendations 
can be derived from what you wrote above, but your text conveys rules in 
a clearer way, IMHO.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 25 Jun 2012 15:52:09 +1000

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/