Subject: [apps-discuss] draft-freed-media-type-regs-01 comments

From: Julian Reschke <[email-masked]>
Date: Sun, 06 Nov 2011 14:40:23 +0100

On 2011-11-05 20:17, Ned Freed wrote:
> The revised media type registration procedure document:
>
>      http://tools.ietf.org/html/draft-freed-media-type-regs-01
>
> is in need of review. In particular, comments are solicited on exactly how the
> process should be modified to remove the IESG from the review process for
> standards tree types. (Note that the IESG needs to retain the authority to
> determine what external organization are qualified standards bodies and what
> ones are not.)
> ...

Hi Ned,

below are notes from a quick top-to-bottom read I just did...:

Comments:

- 4.2 - reg-name; it would be good to state how exactly it is more 
restrictive, to reference the actual subsection of 2045 (5.1), and maybe 
say why.

- 4.2 - "X-" prefixes - this obviously should be coordinated with 
Peter's document.

- 4.2.2 - "specifies one or more separate images that require 
appropriate hardware to display" - sounds a bit fine-tuned for a time 
where graphics hardware was something special. (Also, what about audio 
and video?? :-)

- 4.2.8 - Structured Syntax Name Suffixes - would it make sense to relax 
the standards-tree registration requirements for types that use an 
existing structured syntax? (given the fact doing so makes it much 
harder to do things wrong)

- 4.3 - parameter-name; this repeats the warning about the change from 
2045, but adds "amended by RFC2231". Optimally have this in a single 
place and be consistent.

- 4.3 - maybe repeat the requirements from 2045 about case-insensitivity 
and ordering?

- 4.3 - the question about the validity to *repeat* parameters comes up 
from time to time. My understanding is that it's understood to be 
invalid, but I don't think any spec says that yet. Maybe it should be 
noted here because it affects definitions of new parameters?

- 4.11 - Mac OS File Type - is this still useful information? Minimally, 
to avid confusion, it should be stated that this only affects ancient 
versions of MacOS (right?)

- 5.8 - "When review is required, a change request may be denied if it 
renders entities that were valid under the previous definition invalid 
under the new definition." - see 
<http://www.w3.org/html/wg/tracker/issues/53> - two questions:

1) Is "valid" to be read as "processable" or as "conforming"? For 
instance, HTML5 makes many things invalid that were valid before, but 
recipients still need to process them.

2) "may be denied" is very vague? What are the guidelines? Do we have any?

- References - The spec has a normative reference to RFC 3023, which in 
turn has a reference to RFC 2048, which this document is obsoleting (via 
4288); do we really need a normative reference here? (maybe this can be 
fixed by processing this one in sync with 3023bis)?

Editorial:

- Boilerplate - Maybe move the "Historical Note" down into the 
"Introduction" section? (not only for being easier to cite in the future)

- Boilerplate - I always recommend to have an Editorial Note on the 
front page telling reviewers where to send feedback.

- 5.2 - do items 1) and 2) apply to "Specification Required" process? 
The way it's formatted is slightly confusing.

- Throughout - The spec mixes uppercase and lowercase RFC2119 terms, and 
it's not totally clear what the "force" of the lowercase ones is. In 
many cases this can be avoided by substituting "MAY" by "can" etc.

Nits:

- 5.2 - s/[RFC2026] section 6.5.4/Section 6.5.4 of [RFC206]/

- References - RFC4234 -> RFC 5234

- References - in the reference for RFC2231, there's a line break that 
shouldn't be there (this may be a problem in the 
xml.resource.org-supplied reference, but still...)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 06 Nov 2011 15:12:28 +0100

> restrictive, to reference the actual subsection of 2045 (5.1), and maybe

So this is the same as in RFC 4288, and the difference between 2045 and 
4288 appears to be:

RFC2045.token: "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." 
/ DIGIT / ALPHA / "^" / "_" / "`" / "{" / "|" / "}" / "~"

RFC4288.reg-name: "!" / "#" / "$" / "&" / "+" / "-" / "." / DIGIT / 
ALPHA / "^" / "_"

RFC2045.token - RFC4288.reg-name: "%" / "'" / "*" / "`" / "{" / "|" / 
"}" / "~"

HTTP has:

RFC2616.token: "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." 
/ DIGIT / ALPHA / "^" / "_" / "`" / "|" / "~"

which is somewhere in between 2045 and 4288.

If HTTPbis adds recommendations for header field parameters, should we 
restrict the character repertoire accordingly?

Best regards, Julian

---

From: Ned Freed <[email-masked]>
Date: Sun, 06 Nov 2011 10:47:52 -0800 (PST)

> restrictive, to reference the actual subsection of 2045 (5.1), and maybe

Adding the section 5.1 reference is a good idea and I'll do that. But I really
don't want to get into where all the restrictions originate - the point behind
writing this using descriptive rather than proscriptive ABNF was to make it
very easy for people to tell what characters they can use without having to
wade through a lot of unncessary distractions.

Remember: We're trying to make it easier for folks to figure out how to
register stuff. Understanding the historical reasons why things are the way
they are is a secondary goal at best.

> - 4.2 - "X-" prefixes - this obviously should be coordinated with

Er, actually, it rather obviously should not. Peter's draft is focused on
preventing *new* uses of the X- convention. It doesn't address the issue of
what to do about existing x- usage, which is a rather naunced and tricky area.

Now, if you want to argue that Peter's draft should address how to deal with
existing x- usage in various places, well, that's a discussion you need to have
to have elsewhere. If and when that happens it may make sense to refer to
such a document. Or not - it would depend on what it said.

In any case, the current approach taken to the X- issue here is to:

(1) Strongly discourage the use of such names.
(2) In the event such a name gets widely deployed in spite of it's lack
    of registration, allow it to be registered in the vnd. tree.

This wasn't noted in the changes since the last version list and I have
addressed that.

> where graphics hardware was something special. (Also, what about audio

The point of the "separate image" line was to distinguish it from video. That
said, I take your point about the hardware reference and will remove it.

> harder to do things wrong)

Not sure what you're getting at here. Stuctured syntax name suffixes are
available to all types in all registration trees and always have been. If
there's text that says or implies otherwise let me know where it is and I'll
fix it.

If you're saying that the requirements for a structured syntax are
too strict - they're currently that there be a referencable description
of that syntax, preferably in some sort of standards document - then I quite
simply disgree that that's a good iea.

> 2045, but adds "amended by RFC2231". Optimally have this in a single

It's a different change and for different reasons. And the amendment made
by RFC 2231 applies here but not to media type names, so it cannot be
collapsed without making it incorrect.

> - 4.3 - maybe repeat the requirements from 2045 about case-insensitivity

Can't hurt.

> noted here because it affects definitions of new parameters?

I'll add a note about it.

> versions of MacOS (right?)

Nope. The actual situation under Mac OS is rather complex, but suffice it to
say that Mac OS still supports and uses these codes. (And yes, it also uses
file extensions. As I say, it's complicated.)

> 2) "may be denied" is very vague? What are the guidelines? Do we have any?

The concern here is that someone may attempt to use the change procedure as a
means of attack - for no good reason change a type in such a way that someone's
software is now incompliant.

This has never happened and this procedure has never been invoked. If and when
it ever does, then maybe at that point we'll be able to come up with some
better guidelines. But until then... I'm not comfortable trying to specify
anything more and I'm not comfortable removing this either.

That said, the part of this section that does bother me is the part about only
making changes when there's a serious error. I'm going to qualify that to say
significant changes to a definition should only be made to correct a serious
error. (I may actually not have gone far enough on this one.)

> fixed by processing this one in sync with 3023bis)?

You need to understand the rules that apply specifically to XML types to
register one and those rules are for better or worse, in RFC 3023. So IMO the
reference is normative.

As for trying to sync with another specification, that's almost always a really
bad idea. The reality is specifications are both interdependent and get
updates, so such situations are going to happen whether we like it or not.

> "Introduction" section? (not only for being easier to cite in the future)

Seems reasonable.

> front page telling reviewers where to send feedback.

I don't really see the point in this case.

> The way it's formatted is slightly confusing.

This part is incomplete, pending input on exactly how the process should be
modified to allow registration of standards tree types without involving the
IESG.

> many cases this can be avoided by substituting "MAY" by "can" etc.

A lower case must, may, or should is by definition not a RFC 2119 term. And the
choices for all of these have been made rather carefully over a prolonged
period. I'm not about to start making further changes willy-nilly along the
lines you suggest.

> - 5.2 - s/[RFC2026] section 6.5.4/Section 6.5.4 of [RFC206]/

OK.

> - References - RFC4234 -> RFC 5234

Fixed.

> xml.resource.org-supplied reference, but still...)

I'll leave that one for the RFC Editor. Fixing XML resource stuff is above
my pay grade.

				Ned

---

From: Julian Reschke <[email-masked]>
Date: Mon, 07 Nov 2011 19:20:02 +0100

> wade through a lot of unncessary distractions.

Understood, but the change actually removed a lot of characters, so it's 
not just a matter of style. As we have similar stuff in HTTPbis I'm 
personally interested to find out about the history for this.

And no, it doesn't need to be addressed in this spec, and it's also not 
a change from 4288.

> This wasn't noted in the changes since the last version list and I have

+1

> said, I take your point about the hardware reference and will remove it.

Thanks.

> simply disgree that that's a good iea.

No, I meant to say something else; about registering a type that uses a 
registered suffix in the standards tree.

But that requires either "IESG approval" or "Specification required"; 
and that's fine (my idea was to reduce load on the IESG in this case, 
but it seems I misremembered the requirement).

> collapsed without making it incorrect.

Sorry, indeed. Maybe it's worthwhile to point out that the character 
removed due to RFC 2231 is "*".

> I'll add a note about it.

+1

> error. (I may actually not have gone far enough on this one.)

What about evolving a format?

> A lower case must, may, or should is by definition not a RFC 2119 term.
 > ...

Depending on how you read RFC 2119, you might come to a different 
conclusion. Some people do.

> And the

Ack.

Best regards, Julian

---

From: "Mykyta Yevstifeyev (М. Євстіфеєв)" <[email-masked]>
Date: Tue, 08 Nov 2011 21:07:46 +0200

Ned, all,

Some additional (to Julian's) comments.

In Abstract, it must be mentioned that the document obsoletes RFC 4288.

I find the current text in Introduction very confusing (or irrelevant), 
as it is very generic and not related to media types.  It should be 
rewritten to make clear the goal of the doc.  I also concur with Julian 
that Historical Note should be moved in the Introduction section.

In Section 3.1: when specifying the procedures for registration media 
types in Standards Tree, you mentioned (in terms of RFC 5226): IESG 
approval, Specification Required, IETF Consensus, RFC Required with IESG 
Approval, i.e. 4 different registration policies.  Whereas they serve a 
variety of possible cases, I think we would benefit from a single policy 
which would cover all of them.  I suppose it is "Specification Required 
with IESG Approval" that would cover the following cases: (1) 
IESG-approved document, (2) specification of other standards body; 
registration undergoing IESG approval, (3) non-IESG-approved RFCs, 
registration of which also undergo IESG approval.  The possible cases 
may also be discussed, though.

Section 3.3: the "vanity" naming.  I may be wrong cause it may be some 
sort of stylistic choice, but I actually think that "personal" is enough 
to characterize this tree.  Whereas English native speakers would 
understand such naming, this would be frankly difficult for those who 
speak English as a foreign lang.  I can't manage to find Russian or 
Ukrainian translation of RFC 4288 to prove, but I'm sure that the said 
formulation is applicable in English language only, and isn't 
appropriate for the international-scoped document.

Section 3.4: this is what Julian has already mentioned for Section 4.2.  
APPSAWG is obliged to bring the draft deprecating x- to BCP, so if we 
revising the procedures docs, we need to take it into account.  I 
propose you remove Section 3.4 and naming convention from Section 4.2 
but put a note in Appendix B referring to the RFC-to-be. <later 
when="after reading reply to Julian's message">I think that if we 
produce new version of the doc we should take into account the current 
practice documented as BCP (and I hope it will get BCP).  At least you 
should note that their registration is not absolutely prohibited; I also 
agree that in exceptional cases they can be registered, but only if wide 
use is demonstrated.</later>

Section 4.2: Shouldn't it explain the differences between RFC 2045 and 
the given ABNF?

Section 4.10: "Proposals for media types registered in the standards 
tree by the IETF itself MUST be published as RFCs.".  Do you really mean 
"proposal"?  Also, do we need to encourage publishing RFCs for vnd and 
prs registrations?

Section 5.1: "Registrations in other trees MAY be sent to the list for 
review as well."  Maybe SHOULD?

Section 5.9:  Do we need to leave mail-style lines in the template (I 
mean To: and Subject:)?

Ibid:  Please move the para about MacOS file types into Section 4.11.

Section 6: s/RFC 3978/RFC 5378/ (and in References)

Sections 6 and 8:  As your document sets up the registry for +suffixes, 
it should contain the description as required by RFC 5226, which it 
currently doesn't have.

Thanks,
Mykyta Yevstifeyev

06.11.2011 15:40, Julian Reschke wrote:
> restrictive, to reference the actual subsection of 2045 (5.1), and 
> maybe say why.
>
> - 4.2.8 - Structured Syntax Name Suffixes - would it make sense to 
> relax the standards-tree registration requirements for types that use 
> an existing structured syntax? (given the fact doing so makes it much 
> - 4.3 - maybe repeat the requirements from 2045 about 
> case-insensitivity and ordering?
>
> - 4.3 - the question about the validity to *repeat* parameters comes 
> up from time to time. My understanding is that it's understood to be 
> - 4.11 - Mac OS File Type - is this still useful information? 
> Minimally, to avid confusion, it should be stated that this only 
> affects ancient versions of MacOS (right?)
>
> - References - The spec has a normative reference to RFC 3023, which 
> in turn has a reference to RFC 2048, which this document is obsoleting 
> (via 4288); do we really need a normative reference here? (maybe this 
> can be fixed by processing this one in sync with 3023bis)?
>
>
> Editorial:
>
> - Throughout - The spec mixes uppercase and lowercase RFC2119 terms, 
> and it's not totally clear what the "force" of the lowercase ones is. 
> In many cases this can be avoided by substituting "MAY" by "can" etc.
>
>
> Nits:
>
> _______________________________________________
> happiana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/happiana
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Nov 2011 20:10:32 +0100

> In Abstract, it must be mentioned that the document obsoletes RFC 4288.

No.

But maybe in the introduction (with a forward reference to the Changes 
appendix).

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 Nov 2011 16:53:58 -0700

On 11/6/11 11:47 AM, Ned Freed wrote:

<snip/>

>> - 4.2 - "X-" prefixes - this obviously should be coordinated with

draft-ietf-appsawg-xdash, that is. It's not only my draft, since I have 
two capable co-authors helping me. :)

> such a document. Or not - it would depend on what it said.

We've deliberately punted on that issue in draft-ietf-appsawg-xdash, 
which does *not* modify registration procedures for any existing registries.

> (1) Strongly discourage the use of such names.

At which point an informational reference to draft-ietf-appsawg-xdash 
might be appropriate (for those who want a more detailed treatment of 
the topic).

> This wasn't noted in the changes since the last version list and I have

Thanks for the clarifications.

Peter

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