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
