Re: [apps-discuss] APPSDIR review of draft-ietf-appsawg-media-type-regs-07

[Ned Freed <[e-mail]>]

> Hi Ned,

> Some responses inline.

> On 17/05/2012, at 2:24 AM, Ned Freed wrote:
> >
> > I want to start by reiterating a point I've made repeatedly in the discussions
> > of this draft, but seems to have missed in this review: This is a registration
> > process BCP. It is not a protocol specification, nor is it a specification of
> > either media types or media type suffixes. Media types were specified in RFC
> > 2046 (in considerable details) and protocol suffixes were specified in RFC 3023.
> >
> > As such, it is entirely inappropriate for this document to spend time carefully
> > defining terms, justifying choices, or introducing new terminology. For one
> > thing, it's a violation of what's supposed to be in a BCP. And for another,
> > process documents need to focus on the *process*. Detailed specification
> > material is simply extraneous detail to someone just looking to use the
> > process. And this is plenty long enough already; making it longer in order to
> > include such material would be profoundly unhelpful.

> I disagree; for better or worse, this will be the only document that many people refer to when thinking about media types, especially since 2046 is a MIME document, and media types (as already pointed out in the document) are bigger than MIME.

> I'm not talking about re-defining the concepts, I'm saying that a quick,
> non-normative summary of what they are, along with pointers to more detailed
> information elsewhere, would help readers.

Then feel to suggest text.

> >> * Throughout, "media type" is used somewhat freely to mean all of: a complete
> >> media type label, the format that it identifies, and a top-level type. This is
> >> needlessly confusing. It would be extremely helpful to explicitly define terms
> >> and use them consistently throughout. In particular, "top-level type" is used
> >> sometimes, whereas the plain "media type" is used elsewhere. "content type"
> >> sneaks in sometimes too (again, inconsistently).
> >
> > Some of this is intentional. In particular, the term "media type" is used
> > interchangeably (or, if you prefer, sloppily) to refer to media types in the
> > abstract and to the label for a media type. I've tried writing it the other
> > way, and the resulting prose is stilted and confusing.

> I made such a proposal below ("Media types MUST function as labels for actual
> media formats.") -- are you really saying that this is "stilted and
> confusing"?

As a matter of fact, yes, that text is quite confusing. It implicitly says that
the term "media type" refers to a label rather than an abstraction, and that
contradicts other usage throughout the document.

> Note that I'm not suggesting any new terms be introduced here; the draft
> already uses "label" and "media format"; it just doesn't use them consistently.

No, it uses them when a disctinction needs to be made. That's not
inconsistency.

> >> * "major type" -- e.g., "text" (currently called a "top-level type" sporadically)
> >
> > The word "major" currently appears nowhere in the document. As such, this would
> > be introducing a completely new specification term, and per the above, that's
> > should not happen unless there's simply no alternative. The current text uses
> > either type name or top-level type name, depending on whether or not there's a
> > possibility of confusion with the full name of a media type, and that's how it
> > needs to stay.
> >
> > I'm not particularly fond of top-level type name myself, but it's what we have.

> That's fine, but it's not used consistently now.

I never said it was. In fact I explicitly said the opposite.

> Picking a random example,
> 4.2.1 starts with:

>    The "text" media type is intended for sending material that is
>    principally textual in form.
> When a much clearer rendering would be:

>    The "text" top-level type is intended...

> or better yet:

>    Media types with the "text" top-level type are intended...

That's one of the changes I've already made. (Similar changes need to be
made in all the similar sections, of course.)

> >> * In Section 4.2.4: "Note that although in general this document strongly
> >> discourages the mixing of multiple media in a single body..." This kind of
> >> architectural advice seems out of place in this document. Recommend either
> >> justifying this position, or removing it.
> >
> > First of all, the "this document" in this text is simply incorrect. RFC 2046 is
> > the specification that imposes this restriction, and I'll change the text to
> > make that clear.
> >
> > But per my initial point, this is a registration process, and changing or
> > removing a specification restriction here is not allowed. This document does
> > not and cannot update RFC 2046. (I personaly happen to think the restriction is
> > a little silly at this point, but that's also irrelevant.)

> It sounds like a reference will fix this.

Well, it really doesn't fix the underlying problem, but it's the best we can
do here.

> >> * Section 4.4 covers patents but not copyrights. Given that some people now
> >> believe it's possible to copyright an API, and media types form a key portion
> >> of some styles of APIs, it would seem prudent to have guidelines here. At a
> >> minimum, I'd expect that I wouldn't have to worry about copyright issues when
> >> using a media type in the standards tree.
> >
> > I kind of agree, but this issue should have raised long before last call.
> > Constructing text to deal with a new IPR issue, especially one which AFAICT
> > isn't really addressed by BCPs 78 and 79, ***FAR*** exceeds anything that
> > should be attempted by a document editor on their own during last call.

> These are review comments for the IESG; I'm not necessarily asking you to
> change it, merely noting a potential (and very timely) problem.

So timely that AFIAK the court has yet to rule ;-) Anyway, that's entirely
reasonable - if the IESG feels this needs attention either here or elsewhere
they can figure how to deal with it. I'm just glad I don't have to deal with it
now.

> > I'll add a reference to RFC 4844, but I like the original text a lot better.
> > In particular, the term "Document Stream" is nowhere near as familiar as the
> > terms used in the original text.

> As you point out above, having this document introduce its own terminology
> doesn't do anyone any good. "Familiar" is of course relative to the reader.

Then I'm the one who is confused, because what in this text:

  In the case of registration for the IETF itself, the registration
  proposal MUST be published as an RFC.  When the RFC is in the IETF
  stream it is an IETF Consensus RFC <xref target="RFC4844"/> , which
  can be on the Standards Track, a BCP, Informational, or Experimental.
  Registrations published in non-IETF RFC streams are also allowed, and require
  IESG approval.

is new terminology? "IETF stream" (4844), "IETF Consensus RFC" (2026 and 4844),
"Standards Track", "BCP", "Informational", and "Experimental" (all 2026) are
all well defined and widely used terms.

> >> * In Section 3.3: "Media types in the standards tree are normally denoted by
> >> names that are not explicitly faceted..."  It seems like there should be a
> >> requirement here; although it's understood that there are cases where this
> >> isn't true, it would be useful to give clear guidance.
> >
> > I thought about doing this. The problem with making it a MUST is that
> > you then have to qualify it, and that drags in a bunch of issues and results
> > in repetitive text.

> [ sorry, that should be 3.1]

> I was thinking more of a SHOULD. E.g.,

> "Media types in the standards tree SHOULD NOT have faceted names, unless they
> are grandfathered in using the process described in Appendix A."

On further consideration, this approach actually allows us to use a MUST
without dragging in a lot of additional text. (There was a point when this
material was in a couple of other places in the text.)

There may be an issue with normative language in an appendix, but (a) This
doesn't change that, and (b) That can be addressed easily if someone objects.
And I can get rid of the bit about what an unfaceted name is now that that's
explained elsewhere.

> >> * In Section 4.1, it cautions against transfer encodings being registered,
> >> yet I see application/zlib being registered now
> >> <https://datatracker.ietf.org/doc/draft-levine-application-gzip/>. Does this
> >> need to be reconsidered, or that registration rejected?
> >
> > No and not our call. Gzip is an exceptional case for various reasons. Of course
> > it is entirely possible that the IESG will reject it on this basis.

> Yes. However, right now there's a MUST requirement in there. Is GZIP so
> exceptional that a MUST can be violated, or should this be a SHOULD?

This is unchanged from RFC 4288, so it isn't new. And since GZIP is currently
functioning as a media format in widespread real world practice, the MUST isn't
really being violated. The part that's arguably breaking the rules is the part
about it being "better thought of" as an encoding. Had we actually managed to
define gzip-base64 at some point we have a real case against application/gzip,
but we never managed to do that.

> >> * Section 4.3 would do well to note that third parties cannot arbitrarily add
> >> parameters to existing types without going through the appropriate process;
> >> this comes up quite often, as people assume that there's a default "ignore"
> >> rule here.
> >
> > This falls out of the rules for who can do updates. If you really think
> > something needs to be added, you'll need to suggest text.

> New paragraph at the end of 4.3:

> """ > Changes to parameters (including the introduction of new ones) is
managed in the same manner as other changes to the media type; see 5.6 Change
Procedures. > """

Added.

> (normally I wouldn't suggest adding this kind of redundant "reminder"
> information, but IME this is not well understood)

Fair point.

> >> * Section 4.6: "All registrations MUST state whether or not they employ such
> >> "active content"..." Is it reasonable to expect this? I.e., will the DE be
> >> rejecting requests that don't have a boilerplate "This format does not employ
> >> active content."?
> >
> > That's not how the rules work, since there's the "not assessed" escape
> > hatch, but yes, if you elect not to use the hatch, you have to include
> > that, and it is enforced.

> That's not clear, because the requirement starts with "All registrations MUST
> state..."

> I'd suggest:

> "A security analysis MUST state..."

I don't really see how that addresses the issue, but it also seems harmless, so
... added.

> >> * Section 5.4 directs people to send comments on registered media types to
> >> IANA. Isn't it more appropriate/straightforward to send them to the change
> >> controller, optionally CC:ing the types list?
> >
> > No, I don't think so. Sending it to IANA insures that it gets tracked.

> Is there an expectation that the comments will be collected, or that there
> will be metrics for comments on a media type, or...? I don't see the benefit of
> giving IANA yet another thing to do here.

That's the whole point - if the comment seems sensible, it gets added to the
registration. If we send comments to change controller, I think there's a fair
chance that's as far as they will go.

> >> * Section 4.1 "Media types MUST function as actual media formats." --> "Media
> > types MUST function as labels for actual media formats."
> >
> > Not appropriate.

> See above.

Ditto.

> >> * Section 4.2 "While it is possible for a given media type to be assigned
> >> additional names..." --> "While it is possible for a given format to be
> >> assigned additional media types..."
> >
> > Not appropriate.

> See above.

Ditto.

> >> * Section 5.2.1 "Provisional registrations MAY be updated or abandoned at any
> >> time." How does this happen? How is it reflected in the registry? "OBSOLETE"?
> >
> > Provisional registrations are not in the registry. It's up to IANA as to
> > how to implement the details.

> I see. In that case, I'll add a comment that separating the provisional and
> permanent registries doesn't work well, IME; we have a similar situation in the
> Message Header registry, and forcing people to look into two lists makes it
> confusing. I'd recommend a single, authoritative list, using the status field
> to distinguish them.

I strongly disagree. I think the problem of provisionals being seen as real if
they are intermixed, no matter how well they are labelled.

> >> * Section 5.5: Similar to comments above, the URL for the registry is
> >> important enough to be higher in the document (e.g., the introduction), rather
> >> than buried down here.
> >
> > I don't really see why.

> Because a reader familiarising themselves with the registry might want to
> actually find it.

Feel free to include that in your provided text.

				Ned