Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-00.txt

[Ned Freed <[e-mail]>]

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

> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
> > Sent: Thursday, April 26, 2012 6:19 AM
> > To: [e-mail]
> > Cc: [e-mail]
> > 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.

> <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.

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: s/some Media Type registration/some Media Type registrations/

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

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

> 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.

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