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

[Alexey Melnikov <[e-mail]>]

Hi Ned,

On 13/04/2012 01:33, Ned Freed wrote:
>> 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.
I like the new text, thanks!
>> 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.
>
>> 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.
>> 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.

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

>
>                 Ned