On Jul 13, 2011, at 8:26 , Miguel A. Garcia wrote:
> David, Randall.
>
> I agree with all your suggestions. What is not clear to me is what is the
> proposal for resolving the comments related to the IANA considerations
> section.
I have updated the IANA considerations section to document precisely for which
MIME types an extra reference to this document should be added (possibly
replacing a reference to RFC 4281). For those MIME types, they keep the
reference that documents the basic mime definition, and add this reference that
documents these optional parameters.
I hope this clarifies the IANA actions (updated document coming soon), and
handles the comment.
>
> BR,
>
> Miguel
>
> On 13/07/2011 5:05, Randall Gellens wrote:
>> Sorry for the delay....
>>
>> At 4:57 PM -0700 7/12/11, David Singer wrote:
>>
>>> On Jul 5, 2011, at 7:53 , Miguel A. Garcia wrote:
>>>
>>>> Minor issues:
>>>>
>>>> - I disagree with a few MAYs and MUSTs in Section 3.1. I will
>>>> suggest to change all of them to lower case. Let me revise them:
>>>>
>>>> Therefore, when a receiver does not
>>>> support all listed codecs, special handling MAY be required.
>>>> ^^^
>>>> This one does not specify a clear option that can be implemented.
>>>> For example, I could not write a conformance requirement towards
>>>> that "MAY". What should be the "special handling", and what are
>>>> the options that I can implement or not?
>>>>
>>>
>>> I think this should not be upper-case. The ways the receiver
>>> handles missing codecs will depend on the application, the
>>> availability of fall-backs, and so on, all of which are out of
>>> scope.
>>
>> I agree. My recollection is that this was originally written "may"
>> and someone in a different review asked it to be changed to "MAY".
>> For clariity, perhaps we should use "might" which is clearly
>> descriptive, not normative ("might require special handling").
>>
>>
>>
>>> > For
>>>> example, the media element(s) MAY need to be examined in order to
>>>> ^^^^
>>>> determine if an unsupported codec is actually required ...
>>>>
>>>> This one has a contradiction: if it is an example ("For example,")
>>>> then it cannot have a normative statement. Besides, it also
>>>> suffers from the same problem as the previous "MAY", it is not
>>>> clear what are the options to be implemented or not, and how to
>>>> write a statement of compliance.
>>>
>>> Again, lower-case the 'may'. It is possible, for example, that the
>>> codec in question is only used in a part of the time-line that is
>>> not requested.
>>
>> Agreed. Perhaps also switch to "the media element(s) could be
>> examined" to avoid this sort of confusion.
>>
>>
>>> > NOTE: Although the parameter value MUST be complete and accurate in
>>>> ^^^^
>>>> 'breadth' (that is, it MUST report all four-character codes used in
>>>> ^^^^
>>>> all tracks for ISO-family files, for example) systems MUST NOT rely
>>>> ^^^^^^^^
>>>> on it being complete in 'depth'.
>>>>
>>>> The problem with the above three "MUSTs" is that they are in a
>>>> NOTE, and notes are informative by nature. So, either you remove
>>>> the word "NOTE:" or you turn them all lowercase. If you keep the
>>>> uppercase, it would be nice to see which entity is responsible to
>>>> execute the "MUST", i.e., the encoder of the decoder. The current
>>>> wording, although polite, does not clearly indicate which entity
>>>> is responsible for implementing the MUSTs.
>>>
>>> This should not be a NOTE, it should be plain text. The encoder
>>> MUST report across the complete breadth; the receiver MUST NOT rely
>>> on the report being complete in depth.
>>
>> Agree.
>>
>>
>>
>>> > - Section 3.2. There is a uncongruency between the BNF and the
>>> examples. Please observe the BNF of the 'cod-fancy' object:
>>>>
>>>> cod-fancy := "codecs*" ":=" encodedv
>>>>
>>>> Now observe the examples given in Section 3.1:
>>>>
>>>> codecs*=''fo%2e
>>>> codecs*="''%25%20xz, gork"
>>>>
>>>> I am missing a colon ":" before the equal sign "=", in order for
>>>> the examples to be compliant with the BNF. Therefore, I would have
>>>> expected that the examples were:
>>>>
>>>> codecs*:=''fo%2e
>>>> ^
>>>> codecs*:="''%25%20xz, gork"
>>>> ^
>>>>
>>>> Alternatively, if the examples are correct, the ABNF should have
>>>> not included a colon ":". I don't know which one is correct.
>>>
>>> I believe that the ":" in the BNF is an error.
>>
>> Yes, this looks like a typo.
>>
>> Look at 'cod-simple' and 'cod-fancy' together:
>>
>> cod-simple := "codecs" "=" unencodedv
>> cod-fancy := "codecs*" ":=" encodedv
>>
>>
>> The same error is in RFC 4281, so this should be filed as an errata.
>> I'll do that now.
>>
>>
>>> > Please observe that the resolution of this issue may also apply
>>> to the examples in Section 4.2 or the BNF in 4.5.
>>
>> I don't think so, because the ":=" is a typo.
>>
>>
>>> > - BNF in Section 3.2. The definition of "simpl-list" does not
>>> admit a white space in a list of elements, however the examples
>>> show them with spaces. So, either the BNF or the examples are
>>> wrong. Please observe the BNF:
>>>>
>>>> simp-list := DQUOTE id-simple *( "," id-simple ) DQUOTE
>>>>
>>>> and the examples in Section 3.1:
>>>>
>>>> codecs="a.bb.ccc.d, e.fff"
>>>
>>> I think many people follow the examples; the BNF needs to permit
>>> (but not require) white-space.
>>
>> I believe this is confusion between BNF and ABNF. BNF has implicit
>> white space, although to be honest I can't recall exactly where in
>> RFC 822 this is spelled out or if that was inhereted from Algol's BNF.
>>
>> The best course would be to replace the syntax with ABNF but that
>> requires adding in explicit white space where BNF's grammar has it
>> implicit. This is more work than I wanted to do, at least now,
>> mostly because I'm afraid of missing something.
>>
>>
>>> > - BNF in Section 3.2 There is normative words "MAY" written as
>>> comments to the BNF. I belive this is not the right place to insert
>>> normative statements, so I suggest to add that text elsewhere in
>>> the draft rather than embedded in a comment:
>>>>
>>>> fancy-sing := [charset] "'" [language] "'" id-encoded
>>>> ; Parsers MAY ignore<language>
>>>> ^^^
>>>> ; Parsers MAY support only US-ASCII and UTF-8
>>>> ^^^
>>>> fancy-list := DQUOTE [charset] "'" [language] "'" id-list DQUOTE
>>>> ; Parsers MAY ignore<language>
>>>> ^^^
>>>> ; Parsers MAY support only US-ASCII and UTF-8
>>>> ^^^
>>>>
>>>
>>> Indeed, these two statements need to be moved.
>>
>> Well, the BNF is specifying elements that need to be permitted to be
>> compliant with MIME but which have no specification here. We're
>> borrowing the MIME character set encoding syntax, which allows for
>> language, but we don't actually use language, so we allow parsers to
>> ignore it if specified. This is a rule that only applies to the
>> parser components of an implementation.
>>
>> Probably the right thing is to leave the comment in the BNF, but also
>> add it in the text. In Section 3, the paragraph that starts "An
>> element MAY include an octet that must be encoded" should probably
>> have a new sentence at the end saying:
>>
>> While [MIME-Coding] allows specification of character set and
>> language, this parameter does not contain items intended for
>> human consumption, and hence makes no use of language. The
>> language element MAY be omitted (and usually is); the character
>> set MAY also be omitted (and usually is). A receiver MAY ignore
>> language and MAY choose to support only ASCII and UTF-8.
>>
>>
>>> > - A comment on the same part of the BNF. I think you need to add
>>> normative references to "US-ASCII" and "UTF-8".
>>>
>>> Ouch. US-ASCII is formally defined by a spec. which is basically
>>> unavailable. Does anyone reading this really not know what it is?
>>> UTF-8 needs a Unicode reference, yes.
>>
>> I think it's fine to just say "ASCII"
>>
>> IANA defines it as "ANSI_X3.4-1968" but I also found RFC 20 which we
>> can use as the reference.
>>
>>
>>> > - IANA considerations section. I am puzzled with this section.
>>> It says that IANA has already added "codecs" and "profiles" as
>>> optional parameters the media types... but honestly, I haven't
>>> found evidence of it. Can you please point to what IANA has already
>>> done?
>>>
>>> I think 'codecs' got overlooked after the previous RFC was
>>> published. This is written in the past tense so it will be true
>>> after the publication of this (and the matching IANA action).
>>
>> I'm having trouble finding an IANA registry of parameters, but I do
>> see a reference to RFC 4281 for some MIME types. We should clear
>> this up with IANA.
>>
>>
>>> > Additionally, I noticed in the I-D tracker that IANA has added
>>> this draft as references to a selection of media types. Is this
>>> what was requested by this draft? Honestly, I think not. I suspect
>>> this is totally different from what this draft is requesting.
>>>
>>> This draft should be additional to the base definition of the media types.
>>>
>>>> Nits:
>>>>
>>>> - Section 3.1, at the top of page 8, the word "REQUIRES" is
>>>> capitalized. Since this is not an RFC 2119 word, I would suggest
>>>> to write it in lower case.
>>>>
>>>> An element MAY include an octet that [RFC2045] REQUIRES to be
>>>> encoded.
>>>>
>>>>
>>>
>>> OK
>>
>> Agree.
>>
>>
>>>
>>>> - Section 3.1, same paragraph as the previous comment, towards the
>>>> end. For the sake of clarity, I would suggest to refer to "percent
>>>> encoded", which I believe is the common terminology for special
>>>> characters that are encoded with a percent symbol. That would make
>>>> the text:
>>>>
>>>> .... and single quote characters have special meaning and
>>>> so MUST themselves be percent encoded.
>>>> ^^^^^^^
>>>>
>>>> This comment also applies to the last paragraph in Section 4.2.
>>>>
>>>
>>> OK
>>
>> Agree.
>>
>>
>>>
>>>>
>>>> - I don't understand why Sections 3 and 4 have different
>>>> structure. They should be equal in structure. For example, take
>>>> the BNF definitions. We have Section 3.2 titled "Generic Syntax",
>>>> while Section 4.2 is not a BNF. Ok, it is Section 4.5, but why is
>>>> it titled "Profiles Parameter BNF definition"? I agree more with
>>>> the latter title, but should also be applied to the codec BNF
>>>> definition.
>>>
>>> I left the previous structure of the 'codecs' section unchanged
>>> from the previous RFC for consistency; but it seemed a new
>>> structure for the new 'profiles' section would aid clarity.
>>
>> I'm OK either way.
>>
>>
>> --
>> Randall Gellens
>> Opinions are personal; facts are suspect; I speak for myself only
>> -------------- Randomly selected tag: ---------------
>> The Law, in its majestic equality, forbids the rich, as well as the
>> poor, to sleep under the bridges, to beg in the streets, and to steal
>> bread. --Anatole France
>
> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
David Singer
Multimedia and Software Standards, Apple Inc.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
