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

[Ned Freed <[e-mail]>]

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

> All am really asking about is a statement in the document that entries
> are never deleted, but can be marked OBSOLETE instead.

And I continue to believe that it's a bad idea to get into this in this
specific context. I will also note that under change procedures the document
already says:

  Media type registrations may not be deleted; media types that are no
  longer believed appropriate for use can be declared OBSOLETE by a
  change to their "intended use" field; such media types will be clearly
  marked in the lists published by the IANA.

So the information is there. And I think it's sufficient. But I will add a
pointer to that section to the end of the paragraph, to make it clear that's
what's being referred to.

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

> Heh, Ok :-).

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

> This is what I was thinking.

OK, how does this look:

    restricted-name = restricted name-first *126restricted-name-chars
    restricted-name-first = ALPHA / DIGIT
    restricted-name-chars = ALPHA / DIGIT / "!" /
                            "#" / "$" / "&" / "." /
                            "+" / "-" / "^" / "_"

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

> I would feel more comfortable if you add some text about choices that
> are reasonable with some examples (from the above). Or maybe recommend
> preservation of the record if there is some indication of media type
> being in use.

I'm sorry, but I think this is also a bad idea. The problem with such lists is
they tend to be taken as enumerating all the options, or at least suggesting
what usage should look like, no matter how you label them. And since this is a
new thing, we really have no idea how it's going to work.

> On a related note: is the Designated Expert going to be involved in this
> at all? (I.e., can the Designated Expert update the registration?)

We've been over this before. It's really IANA's call as to how much vetting for
basic syntax and whatnot they are comfortable doing versus getting the expert
reviewer involved. As such, I don't want to specify how this is going t be
handled, because it could easily turn out to be incorrect.

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

> Ok, good point.

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

> Yes. Also it would be worth telling IANA to keep the old one as an
> alias, but this can be communicated to IANA out-of-band.

OK, I decided to go ahead and make the change, and I added the following
paragraph at the end of the IANA considerations section:

  Finally, this document calls for the creation of a new email address,
  [e-mail], for the media type review list, which replaces the
  [e-mail] address specified in RFC 4288. [e-mail] should
  be retained as an alias.

I can always removed the bit about the alias if you think it is better
communicated out of band.

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

> I meant the Appendix with changes since the previous RFC.

That makes more sense. I'll add a note about it.

				Ned