Subject: [Gen-art] Gen-ART review of draft-gellens-mime-bucket-bis-05.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 5 Jul 2011 16:53:06 +0200

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft. For background on Gen-ART, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Please resolve these comments along with any other comments you may receive.

Document: draft-gellens-mime-bucket-bis-05.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 2011-07-05	
IETF LC End Date: 2011-07-14
IESG Telechat date: 2011-07-14

Summary: This draft is on the right track but has open issues, described 
in the review.

Major issues: none

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?

    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.

    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.

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

Please observe that the resolution of this issue may also apply to the 
examples in Section 4.2 or the BNF in 4.5.

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

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

- A comment on the same part of the BNF. I think you need to add 
normative references to "US-ASCII" and "UTF-8".

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

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.

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.

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

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

Regards,

       Miguel G.
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Pete Resnick <[email-masked]>
Date: Sun, 10 Jul 2011 08:11:58 -0500

David/Randy/Per,

I haven't seen any reply to this message. IESG review is coming up on 
Thursday morning. Please respond to these issues well before then.

pr

On 7/5/11 9:53 AM, Miguel A. Garcia wrote:
> reviewer for this draft. For background on Gen-ART, please see the FAQ 
> at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>
> Summary: This draft is on the right track but has open issues, 
> described in the review.
>
> Major issues: none
>
> 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:
>
> 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?
>
>
>    For
> 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.
>
>
> 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.
>
>
> - Section 3.2. There is a uncongruency between the BNF and the 
> examples. Please observe the BNF of the 'cod-fancy' object:
>
> examples to be compliant with the BNF. Therefore, I would have 
> expected that the examples were:
>
>           codecs*:=''fo%2e
>                  ^
> - 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:
>
> parameters the media types... but honestly, I haven't found evidence 
> of it. Can you please point to what IANA has already done?
>
> 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.
>
>
>
>
> 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.
>
> - 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:
>
> - 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.
>
>
> Regards,
>
>       Miguel G.

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: David Singer <[email-masked]>
Date: Tue, 12 Jul 2011 16:57:09 -0700

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

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

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

> 
> 
> - Section 3.2. There is a uncongruency between the BNF and the examples. Please observe the BNF of the 'cod-fancy' object:
> 
>  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
>                 ^
> 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.

> 
> Please observe that the resolution of this issue may also apply to the examples in Section 4.2 or the BNF in 4.5.
> 
> 
> - 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:
> 

I think many people follow the examples;  the BNF needs to permit (but not require) white-space.

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

Indeed, these two statements need to be moved.

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

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

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

OK

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

OK

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

>      Miguel G.

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 12 Jul 2011 20:05:47 -0700

Sorry for the delay....

At 4:57 PM -0700 7/12/11, David Singer wrote:

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

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

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

>>   I am missing a colon ":" before the equal sign "=", in order for 
>> the examples to be compliant with the BNF. Therefore, I would have 
>>  Alternatively, if the examples are correct, the ABNF should have 
>> not included a colon ":". I don't know which one is correct.
>

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

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.

> normative statements, so I suggest to add that text elsewhere in 
> the draft rather than embedded in a comment:
>>

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.

>  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.
>
>> capitalized. Since this is not an RFC 2119 word, I would suggest 
>> to write it in lower case.
>>

Agree.

>> characters that are encoded with a percent symbol. That would make 
>> the text:
>>

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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 13 Jul 2011 17:26:17 +0200

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.

BR,

     Miguel

On 13/07/2011 5:05, Randall Gellens wrote:
>>>                    ; Parsers MAY ignore<language>
>>>                              ^^^
>>>                    ; Parsers MAY ignore<language>
>>>                              ^^^

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 19 Jul 2011 09:49:16 +0200

Replying both Randall and David inline. I have deleted all comments for 
which I am satisfied with the responses and do not require further 
discussion.

> see a reference to RFC 4281 for some MIME types.  We should clear

Note that this comment is pending of resolution.

>>   This draft should be additional to the base definition of the media types.

I would like to see clear instructions to IANA, including:
- Which registry IANA needs to take an action upon, and which subregistry 
(if applicable).
- Which value needs to be modified, created, or deleted.
- What is the change to be applied to such value.

Please do not make reference, such as "the media types as listed in 
Sections 3 and 4", because then it is a recipe for error. List explicitly 
every value that needs to be changed/added/deleted.

BR,

        Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: David Singer <[email-masked]>
Date: Wed, 27 Jul 2011 10:47:03 -0700

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.

David Singer

---

From: David Singer <[email-masked]>
Date: Wed, 27 Jul 2011 11:04:27 -0700

Gentlemen

thank you for your review and comments; a new version (-06) has been uploaded, with edits in accordance with the email discussion. The only significant suggested change that was not made, was changing from BNF to ABNF; none of the authors felt confident enough that this could be done without possibly introducing unintended syntax changes, and the risk did not seem worthwhile (nor the divergence from RFC4281).

On Jul 27, 2011, at 11:00 , [email-masked] wrote:

> New version (-06) has been submitted for draft-gellens-mime-bucket-bis-06.txt.
> http://www.ietf.org/internet-drafts/draft-gellens-mime-bucket-bis-06.txt
> Sub state has been changed to AD Follow up from New Id Needed
> 
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-gellens-mime-bucket-bis-06
> 
> IETF Secretariat.

David Singer

---

From: Robert Sparks <[email-masked]>
Date: Wed, 27 Jul 2011 14:34:00 -0400

David -

Based on your and Randall's responses, I had expected to see text about the profile parameter similar to the existing text about the codec parameter
(such as what's at the bottom of page 8) added to the draft to address my point 1 (which I was expecting would take care of point 3 as a side-effect), 
and a discussion about the term profile to address my point 2. I'm not spotting either of those in this revision?

RjS

---

From: David Singer <[email-masked]>
Date: Wed, 27 Jul 2011 12:15:31 -0700

> and a discussion about the term profile to address my point 2. I'm not spotting either of those in this revision?

Ah, apologies, I thought we had dealt with your questions in email.  I can certainly tighten up the language for these two points.  Here are the points and my previous response, with new proposed action interleaved.

>> 1) The document states that if the codecs parameter is lost, the information it contained can be found in the body - adding it to the Content-Type header field is essentially an optimization. Futher, if the information in the body contradicts the information in the codecs parameter, the information from the codecs parameter is discarded. I'm not seeing the same statements for the profile parameter. So:
>> 
>> Is it true that the information that is intended to be captured in the profile parameter is always already available in the body? If so, text analogous to what exists for the codecs parameter needs to be added to the draft. I would also encourage text making it even clearer to someone wanting to use these two parameters that it must be the case that the body can be correctly interpreted if the parameter values are lost.
> 
> Yes, these parameters are supposed to reflect data from the body;  in the event of a mis-match (which is an error), the body is still definitive of itself.

In 3.1, add before:
   If a receiver encounters a body part whose codecs parameter contains
   codecs that are not indicated by any media elements, then the
   receiver SHOULD process the body part by discarding the information
   in the codecs parameter.

"Although a mismatch is not permitted by this draft, the body-part is definitive of the actual codecs needed; the parameter supplied here is informative."  That clarifies the following text, I hope.

Similarly in 4.1, add:

"When the use of the profiles parameter is defined for a given format, that definition SHOULD indicate that it directly reflects information in the body-part, i.e. that it does not convey information beyond, or different from, what can be learnt by inspecting the body-part. Although a mismatch is not permitted by this draft, the body-part is definitive of the actual profiles; the parameter supplied here is informative."

>> 
>> If it's not true that the information intended for the profile parameter value is already available in the body, the draft needs to explore the ramifications of minting new parameter values more explicitly.
>> 
>> 
> 
>> 
>> 3) How should a recipient treat a Content-Type header field value that has both a codecs and profile parameter that are inconsistent with each other?
> 
> 
> I'm not sure that they can be, as they claim orthogonal things. I supposed it might be possible to write a profile that says "codec XXXX must not be present in files conformant to this profile" and then if you see a codecs value that contains XXXX you have detected an issue.
> 
> The consistency of what is written in the file is out of scope of this RFC;  we merely need to say that the file is definitive, in the case of any divergence between the file and these parameters.  I think we should be silent on what to do if the report of the codecs and profiles in these parameters correctly reflects what the file contains, but the file itself is in error.  That's not our issue.
> 

David Singer

---

From: Robert Sparks <[email-masked]>
Date: Wed, 27 Jul 2011 15:25:55 -0400

Thanks David - that would work for 1) and 3).

RjS

---

From: David Singer <[email-masked]>
Date: Thu, 28 Jul 2011 13:44:21 -0700

Gentlemen

thank you for your review and comments; a new version (-07) has been uploaded, in response to (minor) comments from Miguel and Robert.  Absent any further comment, I think we are good to go.

On Jul 28, 2011, at 13:41 , [email-masked] wrote:

> New version (-07) has been submitted for draft-gellens-mime-bucket-bis-07.txt.
> http://www.ietf.org/internet-drafts/draft-gellens-mime-bucket-bis-07.txt
> 
> 
> http://tools.ietf.org/rfcdiff?url2=draft-gellens-mime-bucket-bis-07
> 
> IETF Secretariat.

David Singer

---

From: Sean Turner <[email-masked]>
Date: Thu, 28 Jul 2011 16:48:57 -0400

Pete,

I thought we'd settled on updated the ones that are already published so 
that implementers will more easily be able to find the parameter.

spt

---

From: David Singer <[email-masked]>
Date: Thu, 28 Jul 2011 13:58:10 -0700

On Jul 28, 2011, at 13:48 , Sean Turner wrote:

> Pete,
> 
> I thought we'd settled on updated the ones that are already published so that implementers will more easily be able to find the parameter.

I am not sure I follow.  I think that's what we're asking IANA to do; add an explicit link to this RFC to all the MIME type registrations to which it applies, so these parameters can easily be found.

If that's not what you mean, what edit would you like?

David Singer

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 28 Jul 2011 23:45:39 +0200

Version -07 is OK with me.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Pete Resnick <[email-masked]>
Date: Thu, 28 Jul 2011 17:49:35 -0400

>> I thought we'd settled on updated the ones that are already published so that implementers will more easily be able to find the parameter.

Yup, my dropped ball. I should have communicated with David.

> If that's not what you mean, what edit would you like?

What we talked about was finding the RFCs that define media types that 
you are explicitly updating and listing those RFCs in the "Updates" 
header of the document. That makes it easier for people using our 
document tools to find this document since old documents will get a 
"Updated By:" listing in the metadata. You don't have to do another 
update for this; I can do this in an RFC Editor Note, but I'd like to 
enlist your assistance in getting the list of RFCs together.

pr

---

From: David Singer <[email-masked]>
Date: Thu, 28 Jul 2011 14:57:19 -0700

On Jul 28, 2011, at 14:49 , Pete Resnick wrote:

> What we talked about was finding the RFCs that define media types that you are explicitly updating and listing those RFCs in the "Updates" header of the document. That makes it easier for people using our document tools to find this document since old documents will get a "Updated By:" listing in the metadata. You don't have to do another update for this; I can do this in an RFC Editor Note, but I'd like to enlist your assistance in getting the list of RFCs together.

I linked the affected RFCs in the IANA considerations section.  I am happy to edit the XML so that the document reflects this -- do you know how to edit the XML to say this?

David Singer

---

From: Pete Resnick <[email-masked]>
Date: Thu, 28 Jul 2011 18:02:34 -0400

> I linked the affected RFCs in the IANA considerations section.  I am happy to edit the XML so that the document reflects this -- do you know how to edit the XML to say this?

If you feel like making the change, in the <rfc> directive, add 
'updates="1234,5678,9012"'.

But like I said, if you give me the list, I can just stick that in an 
RFC Editor note instead of you submitting a new draft.

Your call.

pr

---

From: David Singer <[email-masked]>
Date: Thu, 28 Jul 2011 15:14:41 -0700

Like this?

On Jul 28, 2011, at 15:02 , Pete Resnick wrote:

> If you feel like making the change, in the <rfc> directive, add 'updates="1234,5678,9012"'.
> 
> But like I said, if you give me the list, I can just stick that in an RFC Editor note instead of you submitting a new draft.
> 
> Your call.
> 
> pr
> 
> -- 

David Singer

---

From: Pete Resnick <[email-masked]>
Date: Thu, 28 Jul 2011 18:28:14 -0400

On 7/28/11 6:14 PM, David Singer wrote:
> Like this?
>    
> Network Working Group                                         R. Gellens
> Internet-Draft                                     QUALCOMM Incorporated
> Obsoletes: 4281 (if approved)                                  D. Singer
> Updates: 3839,4393,4337                                       Apple Inc.
>    

Yup. That'll do it.

pr