Re: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs

[Ned Freed <[e-mail]>]

> On 02/04/2012 06:08, Murray S. Kucherawy wrote:
> >
> > This message serves as the beginning of Working Group Last Call on
> > draft-ietf-appsawg-media-type-regs, to end on Friday, April 13^th .
> > Please review the document and provide any feedback to the authors
> > directly or to [e-mail] <mailto:[e-mail]>.
> >
> > The datatracker page for the document:
> > https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/
> >
> >
> This is a very well written document, which includes lots of useful
> improvements over the previous RFC.
> I think there is a small list of issues (mostly nits or clarity issues)
> that need addressing before IESG sees it.

> 3.2.  Vendor Tree

>     A registration may be placed in the vendor tree by anyone who needs
>     to interchange files associated with some product or set of products.
>     However, the registration properly belongs to the vendor or
>     organization producing the software that employs the type being
>     registered, and that vendor or organization can at any time elect to
>     assert ownership of the registration.

> Can you expand a bit on what "assert ownership" means? Does this only apply
> to third party registrations? What are the practical implications?

How about I change it to read:

  A registration may be placed in the vendor tree by anyone who needs to
  interchange files associated with some product or set of products.  However,
  the registration properly belongs to the vendor or organization producing the
  software that employs the type being registered, and that vendor or
  organization can at any time elect to assert ownership of a registration done
  by a third party in order to correct or update it.

> For example, can the vendor/organization request removal of the registration
> (I hope the answer to this question is "no".)

Explicitly talking about deleting registrations is a place where we really
don't want to go. There's nothing in the process that would allow someone to
delete a registration, irrespective of whether or not they're considered to be
the owner. That said, there are these things called lawsuits, and who knows
what could result from one of those.

> 4.2.  Naming Requirements

>     Type and subtype names MUST conform to the following ABNF:

>         type-name = restricted-name
>         subtype-name = restricted-name

>         restricted-name = 1*127restricted-name-chars
>         restricted-name-chars = ALPHA / DIGIT / "!" /
>                                 "#" / "$" / "&" / "." /
>                                 "+" / "-" / "^" / "_"

> Ok, this might be silly, but I thought I should ask: can a subtype-name
> (or type-name) start with a dot?

Such a type would necessarily be in a new tree with a blank name, and that
requires an IETF standards action to create. I guess I could imagine, the,
well, "tree with no name" making some sort of wierd sense for, I don't know,
types that are supposed to be invisible or something. But most likely not.

A type with a name beginning with #, $, or better still, & might be amusing
though. And there's nothing AFAIK preventing those. I guess we could change the
ABNF so that the first character has to be an ALPHA or DIGIT if we think it's
worth the bother. Comments?

> 4.2.1.  Text Media Types

>     A "charset" parameter SHOULD NOT be specified when charset
>     information is transported inside the payload (e.g., as in "text/
>     xml").

> As you are already referencing [I-D.ietf-appsawg-mime-default-charset]
> Normatively, it would be good to make it clear that this document is merely
> repeating requirements from [I-D.ietf-appsawg-mime-default-charset].
> (The same applies to the next paragraph, but there it is clearer.)

I'll add something.

>     If a "charset" parameter is specified, it SHOULD be a required
>     parameter, eliminating the options of specifying a default value.  If
>     there is a strong reason for the parameter to be optional despite
>     this advice, each subtype MAY specify its own default value, or
>     alternately, it MAY specify that there is no default value.  Finally,
>     the "UTF-8" charset [RFC3629] SHOULD be selected as the default.  See
>     [I-D.ietf-appsawg-mime-default-charset] for additional information on
>     the use of "charset" parameters in conjunction with subtypes of text.

> 4.4.  Canonicalization and Format Requirements

>     As such, teferences to

> typo: references

Fixed.

>     or inclusion of format specifications in registrations is encouraged
>     but not required.  Note, however, that the public availability of a
>     meaningful specification will often make the difference between
>     simply having a name reserved so that there are no conflicts with
>     other uses and having the potential for other implementations of the
>     media type and useful interoperation with them.


> 5.2.1.  Provisional Registrations

>     Accordingly, a provisonal registration process is provided to support
>     early assigment of media type names.  A provisional registration MAY
>     be submitted to IANA for standards tree types.  The only required
>     fields in such registrations are the media type name and contact
>     information (inckuding the standards body name).

> typo: including


>     Provisional registrations MAY be updated or abandoned at any time.

> I am a bit concerned about "abandoned". It is true that the standardization
> of a media type might not complete. But if the media type ends up being
> deployed in any form, wouldn't it be better to mark it as OBSOLETE or
> something like this instead? I.e. I would prefer for entries not being
> deleted
> from the registry.

Bad idea. What if someone puts in a provisional registration for some type,
then finds out that there's already widespread unregistered usage of that type
under another name? What if the first name chosen doesn't deploy at all and
then someone suggests a much better name? What if two people provisionally
register what turns out to be the same thing at the same time?

I could go on and on and on, but I think this makes the point. You're trying to
optimize what is likely to be a fairly unlikely occurance - a name proves
successful but registration is abandoned - at the expense of other far more
likely cases, cases which if handled this way will lead to registration
clutter.

Like it or not, really have no choice here but to place some degree of trust in
the people doing these registrations. In fact I'd go so far as to say the
(sometimes only implied, sometimes all too explicit) lack of trust is at least
part of the perception problem we're faced with in a more general sense.

> 5.6.  Change Procedures

>     Once a media type has been published by the IANA, the owner may
>     request a change to its definition.  The descriptions of the
>     different registration trees above designate the "owners" of each
>     type of registration.  The same procedure that would be appropriate
>     for the original registration request is used to process a change
>     request.

> I don't remember seeing IETF (or IESG) being the owner of all Standards Tree
> registration. Did I miss it?

You missed it because it is intentionally not there. The owner of such
registrations should be whatever standards body does the registration, not the
IETF. I guess I could add a statement to that effect, but given the owner is
necessarily what's going to be checked to see if they're an "authorized
standards body", I think it just falls out of other considerations.

> 6.  Structured Syntax Suffix Registration Procedures

>     3.  Send a copy of the template or a pointer to the containing
>         document (with specific reference to the section with the
>         template) to the mailing list [e-mail],

> I've noticed that everywhere else in the document you are using
> [e-mail]. Although at the moment both mailing lists are going
> to the same place, there is no guaranty that that would be true in the
> future.
> So I suggest you be consistent everywhere.

Agreed, but in point of fact I'd prefer to change the name to something that
doesn't have "ietf" in it. I'd prefer to use "[e-mail]", but I'm
unsure of how to go about making such a change. Should I just change the
address everywhere and ask IANA to create the new address in the IANA
considerations section?

> 10.1.  Normative References

>     [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
>                Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
>                Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

> I think this reference is actually Informative.

On examination I agree. Moved.

> In Appendix A: it might be worth pointing out that submission to
> [e-mail] for review is not an absolute requirement anymore.

??? Appendix A is about grandfather media types, and I see no reference to the
mailing list there. Why would I want/need to introduce one?

				Ned