Thanks David - that would work for 1) and 3). RjS
On Jul 27, 2011, at 3:15 PM, David Singer wrote: > > On Jul 27, 2011, at 11:34 , Robert Sparks wrote: > >> 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? > > 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. >> > > >> >> RjS >> >> On Jul 27, 2011, at 2:04 PM, David Singer wrote: >> >>> 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 protected] 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 >>> Multimedia and Software Standards, Apple Inc. >>> >> > > David Singer > Multimedia and Software Standards, Apple Inc. > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
