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

[Alexey Melnikov <[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?
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 [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.


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
[e-mail] for review is not an absolute requirement anymore.