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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
