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

Julian Reschke <> Mon, 07 November 2011 18:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E761221F8C07 for <>; Mon, 7 Nov 2011 10:20:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.197
X-Spam-Status: No, score=-104.197 tagged_above=-999 required=5 tests=[AWL=-1.598, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZG0-fkJYplrQ for <>; Mon, 7 Nov 2011 10:20:08 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 3191121F8B85 for <>; Mon, 7 Nov 2011 10:20:07 -0800 (PST)
Received: (qmail invoked by alias); 07 Nov 2011 18:20:05 -0000
Received: from (EHLO []) [] by (mp055) with SMTP; 07 Nov 2011 19:20:05 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18v4sw0+CQvTlL76YXh/a62Q2/csgk8zcVVjT0zBP pkU9Kpsc0DOrHo
Message-ID: <>
Date: Mon, 07 Nov 2011 19:20:02 +0100
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Ned Freed <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "" <>, IETF Apps Discuss <>
Subject: Re: [apps-discuss] draft-freed-media-type-regs-01 comments
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Nov 2011 18:20:09 -0000

On 2011-11-06 19:47, Ned Freed wrote:
> ...
>> 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.
> 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.
> ...

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.

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


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


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

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

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

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

> ...
>> - 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?
> I'll add a note about it.
> ...


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

What about evolving a format?

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


 > ...

Best regards, Julian