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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 2 Apr 2012 05:08:13 +0000

This message serves as the beginning of Working Group Last Call on draft-ietf-appsawg-media-type-regs, to end on Friday, April 13th.  Please review the document and provide any feedback to the authors directly or to [email-masked]<mailto:[email-masked]>.

The datatracker page for the document: https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/

-MSK, APPSAWG co-chair

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Apr 2012 18:22:57 +0100

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 [email-masked] <mailto:[email-masked]>.
>
> 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?
For example, can the vendor/organization request removal of the registration
(I hope the answer to this question is "no".)

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?

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

    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

    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.

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?

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 [email-masked],

I've noticed that everywhere else in the document you are using
[email-masked]. 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.

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.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 12 Apr 2012 18:09:06 +0000

Just a reminder that this WGLC ends today.  If anyone has any reviews to report or comments to provide, please do so.  I'd like to hand it over to Barry this weekend if possible.

-MSK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Sunday, April 01, 2012 10:08 PM
To: [email-masked]
Subject: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs

-MSK, APPSAWG co-chair

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 12 Apr 2012 15:57:36 -0600

On 4/12/12 12:09 PM, Murray S. Kucherawy wrote:
> Just a reminder that this WGLC ends today.  If anyone has any
> reviews to report or comments to provide, please do so.  I’d like
> to hand it over to Barry this weekend if possible.

Overall this looks very good. I have a few comments.

1. I wonder about this:

   In the case of registration for the IETF itself, the registration
   proposal MUST be published as an IETF Consensus RFC, which can be on
   the Standards Track, a BCP, Informational, or Experimental.

Given the descriptions of Informational and Experimental documents in
RFC 2026, I don't think we can say that they reflect IETF consensus.
See in particular:

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.

2. It's not clear to me where open-source projects fit into the
taxonomy. One might think that an organization like Mozilla is a
"vendor" or "producer", according to Section 3.2:

   The vendor tree is used for media types associated with publicly
   available products.  "Vendor" and "producer" are construed very
   broadly in this context and are considered equivalent.  Note that
   industry consortia as well as non-commercial entities that do not
   qualify as recognized standards bodies can quite appropriately
   register media types in the vendor tree.

However, Section 3.3 seems to add a further proviso regarding the
commercial nature of a vendor or producer:

   Registrations for media types created experimentally or as part of
   products that are not distributed commercially may be registered in
   the personal or vanity tree.

So, is commercial distribution a necessary feature of a vendor or
producer?

3. I don't know if the unregistered "x." tree is truly consistent with
draft-ietf-appsawg-xdash. I'm not saying it needs to be, but that
would IMHO be desirable. Note that the xdash document, despite the
name, is not limited to the literal string "x-" but applies more
generally to similar constructs, such as "x.". Given that we are
significantly easing the registration process in
draft-ietf-appsawg-media-type-regs, do we still feel a need to even
mention the "x." tree?

I might provide further comments later today...

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ned Freed <[email-masked]>
Date: Thu, 12 Apr 2012 15:23:49 -0700 (PDT)

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> RFC 2026, I don't think we can say that they reflect IETF consensus.

You're reading it backwards. Nowhere does it say that all informational
specifications reflect IETF consensus, but rather than some IETF Consensus RFCs
can be published as informational. This is an incontrovertible fact, as is the
fact that standards tree media types have been defined in informational
specifications, and I suspect this will be done in the future as well.

For better or worse, the fact that everything has to go in one of a small set
of categories sometimes necessitates that awkward choices be made. But in the
case of a standards tree registration in an RFC, the IESG has final say on
that, including but not limited to assessing whether or not it makes sense for
the type to be in the standards tree at all, irrespective of the document
status. And I think this is already very clear.

>    Internet community consensus or recommendation.

Except that sometimes it does, and this has been true for a long time, RFC 2026
assertions notwithstanding. And in the case of it registering a media type in
the standards tree, it has to.

> "vendor" or "producer", according to Section 3.2:

According to their web site, the Mozilla Foundation qualifies as a
non-commercial  entity.

> So, is commercial distribution a necessary feature of a vendor or

Once again you're reading things backwards. This is a restriction on who may
register a personal or vanity type, nothing more. We really don't want types
associated commercial entities showing up in the prs. tree.

And I really don't see how you can read it any other way. The term "vendor
tree" appears nowhere in this paragraph and the paragraph itself appears in a
section talking about the prs. tree, so how can it possibly apply any sort of
restriction on a different tree?

> draft-ietf-appsawg-media-type-regs, do we still feel a need to even

If there's a clear preference and consensus to drop it that's fine, but absent
that I'm uncomfortable with removing it.

				Ned

---

From: SM <[email-masked]>
Date: Thu, 12 Apr 2012 16:52:55 -0700

Hi Peter,
>RFC 2026, I don't think we can say that they reflect IETF consensus.

The descriptions from RFC 2026 are no longer applicable.  If you 
decide to argue about this on process grounds, you are correct and I am wrong.

RFC 5471 defines the boilerplate text for an RFC in the IETF Stream 
which represents consensus.  As this is the IETF, rumor has it that 
there might be a Standard Track document which does not represent 
IETF Consensus.

   "Registrations published in non-IETF RFC streams are allowed and
    require IESG approval."

Documents in the IETF Stream also require IESG approval.  The hurdle 
is lower for non-IETF streams.   I don't have enough background 
information to comment on whether that should be changed.

Regards,
-sm

---

From: Ned Freed <[email-masked]>
Date: Thu, 12 Apr 2012 17:33:39 -0700 (PDT)

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

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

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

> (The same applies to the next paragraph, but there it is clearer.)

I'll add something.

> typo: references

Fixed.

> something like this instead? I.e. I would prefer for entries not being

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.

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

> 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 "[email-masked]", 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?

> I think this reference is actually Informative.

On examination I agree. Moved.

> [email-masked] 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 Apr 2012 01:40:20 +0000

Sorry, it actually ends tomorrow.  But I'm glad all this chatter got started on the second-last day rather than the last one.  Maybe I'll use this trick again in the future!

-MSK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Thursday, April 12, 2012 11:09 AM
To: [email-masked]
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs

-MSK

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Sunday, April 01, 2012 10:08 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs

-MSK, APPSAWG co-chair

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Apr 2012 20:11:38 +0100

Hi Ned,

>  by a third party in order to correct or update it.
I like the new text, thanks!
> 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.
> requires an IETF standards action to create.
Heh, Ok :-).
> I guess I could imagine, the,
This is what I was thinking.
>> deleted from the registry.
>
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.

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?)
> standards body", I think it just falls out of other considerations.
Ok, good point.
> address everywhere and ask IANA to create the new address in the IANA
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.
> mailing list there. Why would I want/need to introduce one?
I meant the Appendix with changes since the previous RFC.

---

From: Ned Freed <[email-masked]>
Date: Fri, 13 Apr 2012 13:52:04 -0700 (PDT)

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

> 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 / "!" /
                            "#" / "$" / "&" / "." /
                            "+" / "-" / "^" / "_"

> preservation of the record if there is some indication of media type

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.

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

> 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,
  [email-masked], for the media type review list, which replaces the
  [email-masked] address specified in RFC 4288. [email-masked] 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.

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

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

				Ned