Subject: [apps-discuss] draft-ietf-appsawg-media-type-suffix-regs

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 4 May 2012 21:06:02 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, April 26, 2012 6:19 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-appsawg-media-type-suffix-regs-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Applications Area Working
> Group Working Group of the IETF.
> 
> 	Title           : Additional Media Type Structured Syntax Suffixes
> 	Author(s)       : Tony Hansen
> 	Filename        : draft-ietf-appsawg-media-type-suffix-regs-00.txt
> 	Pages           : 9
> 	Date            : 2012-04-26
> 
>    This document defines several Structured Syntax Suffixes for use with
>    media type registrations.  In particular, it defines and registers
>    the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip"
>    Structured Syntax Suffixes, and updates the "+xml" Structured Syntax
>    Suffix registration.

This document is the follow-on to the one Ned just finished that updates media type registration procedures.  Since the latter references this one normatively, they'll be clustered and held until they're all queued.

Thus, please review and provide some comments so we can make progress toward being able to submit it for processing.

Thanks, and good weekend to all.

-MSK, APPSAWG co-chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 15 May 2012 18:24:47 +0000

>    Structured Syntax Suffixes, and updates the "+xml" Structured Syntax

<hat type='participant'>

This document looks reasonable to me as-is.  All of my comments are minor or nitty in nature except for the last one.

Sections 1, 3-7: The "may" in a document citing RFC2119 ought to be "can" or such.

Section 1: s/some Media Type registration/some Media Type registrations/

Section 1: "media type" is sometimes capitalized, sometimes not.

Section 2: s/provides receivers/allows receivers/  (or enables, or permits)

Sections 3 through 8: The hangText and the content of each bullet runs together.  Suggest a colon at the end of each hangText.

Section 3: Would a reference to someplace for a definition/explanation of "fragment identifier" be useful here to establish context?

Section 4: The two registrations run together as there's no separation between them.  Perhaps put each in its own section or subsection?

Section 8: Non-normative "should" ought to be something else.

Sections 3-8: I forget where we stand on the whole issue of the use of normative language in IANA registration materials.  It's there in this one.  Do we want to leave it?

</hat>

-MSK

---

From: Ned Freed <[email-masked]>
Date: Tue, 15 May 2012 23:59:14 -0700 (PDT)

I'm not the document editor, but a few comments are in order here.

> Sections 1, 3-7: The "may" in a document citing RFC2119 ought to be "can" or such.

This seems pretty silly to me. The entire point of capitalizing these terms is
so they aren't confused with conventional usage, freeing up the regular forms
for conventional use.

There may be reasons to change a may into a can or whatever because it makes
the text clearer. But not because of this.

I note in passing that the media type registration document uses "may" all over
the place. So does the draft boilerplate, for that matter. And horrors! This
is being published in May. Think of the childen^H^H^H^H^H^H^H^Hconfusion!

> Section 1: "media type" is sometimes capitalized, sometimes not.

FWIW, I try to use the lower case form consistently in the registration
draft.

> Section 8: Non-normative "should" ought to be something else.

Same point as with "may".

> Sections 3-8: I forget where we stand on the whole issue of the use of
> normative language in IANA registration materials.  It's there in this one.  Do
> we want to leave it?

This is a real conundrum. These compliance terms become in effect part of the
rules media types need to follow as well as the the checks the media types
reviewer needs to perform. As such, they need to stand out, so the same
argument for using them in the regisration procedures document apply here.

But there are two problems. One is the obvious one that these registrations
will be separated from the conventions used text, and in that process the
definition is lost. And I don't know how to retain it.

There's also a second, more subtle, problem. Media types are registered
all the time in protocol specifications. And sooner or later so will a type
suffix. When you're dealing with specification like this one or the media
types registration procedure specification that don't define any sort of
protocol, there's no confusion as to whether it's a registration requirement
or a protocol interoperability requirement. But that won't be true in a
document whose primary purpose is as a protocol specification. The potential
for confusion there is real. And part of the purpose of this document
is to provide a model to follow.

So, although it pains me greatly to say it, especially since it will make
my job harder, I think they need to be dropped from the registrations
themselves.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 May 2012 08:11:57 +0000

> From: Ned Freed [mailto:[email-masked]]
> Sent: Tuesday, May 15, 2012 11:59 PM
> To: Murray S. Kucherawy
> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-00.txt
> 
> This seems pretty silly to me. The entire point of capitalizing these
> terms is so they aren't confused with conventional usage, freeing up
> the regular forms for conventional use.

As Dave would have pointed out had I not beaten him to it, RFC2119 doesn't actually say "MAY" is different from "may".  And I've been asked to deal with this in enough of my own drafts that now I bring it up when I see it.  It's not a showstopper (for me) but I expect someone in the review path will mention it.

Barry has suggested, and I believe the IESG has allowed, that the RFC2119 boilerplate included in the document also say that the RFC2119 meaning for each only applies when the word is in all-uppercase.  That allows the stuff you're talking about.  We could do that here too just to make everyone happy.

We could further suggest that someone who feels so inclined propose a BCP draft to actually update RFC2119 accordingly.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Wed, 16 May 2012 09:49:14 -0400

> As Dave would have pointed out had I not beaten him to it, RFC2119
> doesn't actually say "MAY" is different from "may".  And I've been
> asked to deal with this in enough of my own drafts that now I bring
> it up when I see it.
>
> Barry has suggested, and I believe the IESG has allowed, that the
> RFC2119 boilerplate included in the document also say that the RFC2119
> meaning for each only applies when the word is in all-uppercase.  That
> allows the stuff you're talking about.
>
> We could further suggest that someone who feels so inclined propose a
> BCP draft to actually update RFC2119 accordingly.

I have other comments about this, but the discussion doesn't belong
here.  I'll post something to [email-masked], and anyone interested can
follow it there.

Barry

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 17 May 2012 18:42:34 +0100

Further also to the recent review.

With my informal W3C TAG and XML Core WG hats on, I want to flag again
our concern about section 8:

8.  IANA Considerations

   See the Message Type Structured Syntax Suffix registration forms in
   Section 3 - Section 7.

   The existing Structured Syntax Suffix registration for "+xml"
   should be modified to include the following

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

RFC3023 does not, in fact, embarassingly, define a fragment
identifier syntax for application/xml documents, so this paragraph is
at best misleading.

Also, it's perhaps inappropriate to attempt to override-at-a-distance in
this way, given that this document obviously will not be documented as
superseding 3023.

The overall intent of this is clearly a Good Thing, but the timing is
tricky. . .

I will try to get some concrete information about the chances of a
getting a draft RFC intended to replace 3023 as a matter of urgency.

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: Tony Hansen <[email-masked]>
Date: Thu, 17 May 2012 15:02:47 -0400

Thank you for the review Murray. I agree with most of the points.

I'm leaving off adding a definition for fragment identifiers, as I don't 
believe it belongs in this document.

For now, I'll leave the 2119 MUSTard alone.

     Tony Hansen

On 5/15/2012 2:24 PM, Murray S. Kucherawy wrote:
> ...

---

From: Tony Hansen <[email-masked]>
Date: Thu, 17 May 2012 15:10:47 -0400

> identifier syntax for application/xml documents, so this paragraph is

Please re-read the text. It does not say that fragment identifier syntax 
is defined in 3023, but instead says that fragment identifier syntax 
 >>considerations<< are defined there. In particular, sections 5 and 7 
discuss how fragment identifiers are to be treated.

> this way, given that this document obviously will not be documented as

Interesting point -- I should have added an "updates 3023" when I added 
that update to +xml's media type registration. Done.

     Tony Hansen