<div dir="ltr"><div>Caroline,</div><div><br></div><div>Thank you for your careful review again. In London, we studied your</div><div>comments carefully, although some of your comments need further </div><div>work.</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-09 6:06 GMT+09:00 Arms, Caroline <span dir="ltr"><<a href="mailto:caar@loc.gov" target="_blank">caar@loc.gov</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I promised that I would comment on Murata-san’s latest rewrite of the text related to media/content types. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I chose to ignore my earlier comments and approach it again as a new reader. So there may be some repetition of points I made before that Murata-san argued against. Most of the changes look fine.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">All page numbers relate to OPC WD1 DSig-JH2 and C2MRev.docx as I see it but automated changes relating to renumbering in Clause 4 resulted in added pages in my copy.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">General issues: <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">1. Inconsistent capitalization for Media Types, Media Types Stream, and Media Types Stream Markup. This is a problem throughout. The question is what capitalization choices SHOULD be made given that the name of the stream is [/[Content_Types].xml]</span></p></div></div></blockquote><div><br></div><div>Now, we use "media type" and "the Media Type stream" except in titles, part property name, and RFC titles.</div><div>The list of all occurrences of "media type" is shown at the end of this mail. "Growth Hint" and </div><div>"Media Type" as part property names are also capitalized.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Some clause/subclause headings are not capitalized where they should be. I find the use of "Media Types stream" in the narrative slightly confusing given that it does not match the stream name. I might prefer "media types stream" except in headings. I suggest the group as a whole discuss this issue in London.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> </span></p></div></div></blockquote><div><br></div><div>Capitalization of headings is left to final editing work after the technical content </div><div>is mature.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">2. How early should we indicate that the "media types stream" is called [/[Content_Types].xml]<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Currently it is not explicitly stated as text until a table in 9.3.1 and in the narrative in 9.3.7. However, "ContentType" shows up in diagrams 9.2.3.3. I strongly believe that the stream's name should be mentioned informatively earlier than 9.3. My preference would be to add a note to the definition of "media type stream" in Clause 4. Alternatively (or additionally), add a mention in 9.2.3.2.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> </span></p></div></div></blockquote><div> </div><div><div>Participants of the London meeting do not want to mention</div><div>[Content_Types].xml in earlier clauses. This is because this file is</div><div>very specific to the ZIP physical package model. Media type</div><div>information does not always require a particular file. Even if a</div><div>particular file is needed, the file name is not required to be</div><div>[Content_Types].xml.</div></div><div><br></div><div>But we added </div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div><p class="MsoNormal"><span lang="EN-US">This clause specifies an abstract model for
a package. The requirements for mapping </span></p><p class="MsoNormal"><span lang="EN-US">these concepts to a physical format,
including specifically to ZIP files, are given in §</span><span lang="EN-US">9</span><span lang="EN-US">.</span></p></div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><p class="MsoNormal"><span lang="EN-US">and</span></p></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div><p class="MsoNormal"><span lang="EN-US"><span lang="EN-US" style="font-size:11pt;line-height:115%;font-family:Calibri,sans-serif">This
clause specifies the requirements for mapping the abstract package model </span></span></p><p class="MsoNormal"><span lang="EN-US"><span lang="EN-US" style="font-size:11pt;line-height:115%;font-family:Calibri,sans-serif">concepts in §</span><span lang="EN-US" style="font-size:11pt;line-height:115%;font-family:Calibri,sans-serif">8</span><span lang="EN-US" style="font-size:11pt;line-height:115%;font-family:Calibri,sans-serif"> to
a physical format, including specifically to ZIP files as described in §</span><span lang="EN-US" style="font-size:11pt;line-height:115%;font-family:Calibri,sans-serif">9.3</span><span lang="EN-US" style="font-size:11pt;line-height:115%;font-family:Calibri,sans-serif">.</span><br></span></p><p class="MsoNormal"><span lang="EN-US"><br></span></p></div></div></div></blockquote>at the beginning of Clauses 8 and 9, respectively.<br><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">3. I think we have to use different phrases for the relationship of media types to 2046 and 7231. The current text uses "as defined in RFC xxxx" for both. Careful readers will see that as an inconsistency. My suggestion is to use "using the syntax provided in RFC 7231 3.1.1.1". Note that this clause in RFC 7231 refers to RFC 2046, which is useful. Or we might refer to Appendix D which also connects OWS (optional white space as included in the BNF in 3.1.1.1) to its definition in RFC 7230.<u></u><u></u></span></p><p class="MsoNormal"></p></div></div></blockquote><div><br></div><div>Now, we use "<span style="font-family:Calibri,sans-serif;font-size:11pt;line-height:115%"> </span><span style="font-family:Calibri,sans-serif;font-size:11pt;line-height:115%">using the syntax defined in RFC 7231</span><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:14.6666660308838px"> </span><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:14.6666660308838px">3.1.1.1"</span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"> </p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">4. I suspect that Murata-san's changes do not take into account what I believe to be an automated relationship between requirements in the text and those in Annex G. I would like to emphasize that the separate list of requirements is likely to be very useful to folks doing validation of OPC packages, for example in the workflow for ingest into a preservation repository.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> </span></p></div></div></blockquote><div><br></div><div>We plan to drop Annex G. It hampers our editing work. No other parts </div><div>have such lists of requirements.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Detailed issues:<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Clause 2. Conformance (p. 2)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> I suggest we pick a different conformance example (used to show how requirements are indicated in the text) to raising the issue about the stream that is called [/[Content_Types].xml]</span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> but now described by the phrase "media types stream." Perhaps use one of the XML Usage requirements in 8.2.5. Several of these requirements seem self-explanatory.</span></p></div></div></blockquote><div><br></div><div>Not done yet.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Clause 3. Normative References (p. 3)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> Just noting that RFC 2616 is still referenced in 8.2.3. However, I believe that is in a section that Murata-san hopes to delete.</span></p></div></div></blockquote><div><br></div><div>Yes, we have deleted the section. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Clause 4. Terms and Definitions (p. 5)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> I see no reason for upper case in the term here. Change "specially" to "special"<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> </span></p></div></div></blockquote><div><br></div><div>We deleted the definition of "Media Type stream". It is rather a provision.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">My preference would be to add a note to indicate that the stream is called [/[Content_Types].xml]</span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> when using a ZIP-based package as described in clause 9.</span></p></div></div></blockquote><div><br></div><div>Again we do not want to mention this file name in Clauses 1 thru 8.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Clause 8. Package Model <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">8.2.3 (p.17)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I suggest a slight rewording of Murata-san's added text. This also needs to be assigned a requirement number.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">"This specification uses MIME media types as defined in RFC 2046 to identify the type of content stored in parts. Each part shall have a media type (e.g., application/xml) which may have a set of parameters."</span></p></div></div></blockquote><div><br></div><div>First, we tried to avoid normative definitions of what is already defined in MIME RFCs.</div><div>As a result, this subclause has much less text then before. I will send a revised text </div><div>very soon.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Would it be more appropriate to use as an example a media type/subtype combination that appears in RFC 2046?<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">With all the changes, I am unable to figure out exactly which paragraphs Murata-san wishes to delete. Looking at in my copy of Word it looks as though the proposal includes deleting what seem to be significant requirements, e.g., requirement M1.15. I see no problem in deleting the syntax presentation if others agree that it is covered adequately in cited RFCs. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">However, since RFC 2046 does not provide full BNF for the media type and I believe the syntax for a media type should be specified in Clause 8 and not only in Clause 9, I would like to see an RFC that does supply the BNF cited here too. M1.13 (here, but possibly in the proposed deletion) is the syntax requirement for mediatypes. Murata-san did modify the text for M1.13 in Annex G to refer to RFC 7231. </span></p></div></div></blockquote><div><br></div><div>RFC 2046 provides a conceptual definition of media types. RFC 7231 provides one possible syntax for specifying</div><div>media types. Thus, we think that 8.2.3 should not reference RFC 7231. We think that 9.2.3 is the right place.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I'll leave it to the BNF and regex experts to thrash out what really needs to be in this Clause 8 section. RFC 7231 doesn't get mentioned until Clause 9.</span></p></div></div></blockquote><div><br></div><div>Yes, this is intentional. <span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:14.6666660308838px">RFC 7231 shouldn't get mentioned until Clause 9.</span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">8.2.5 (p. 18)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">There might usefully be a pointer to Annex C for the schemas for the "XML Content" this subclause relates to, perhaps in the [Note] in the first para.</span></p></div></div></blockquote><div><br></div><div>Again, the schemas provide syntax. Thus, it should not be referenced from Clause 8.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">8.3.5 (p. 23)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">[M7.3] doesn't seem to exist any more. [not to do with media/content type -- just noticed in passing, since an apparent reference to a requirement rather than a subclause seemed odd.]</span></p></div></div></blockquote><div><br></div><div>We defer editing work of [Mx,x:]. I would like to delete all of them. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">8.5.4 third para (p. 29) <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">may have missing space after mediatype</span></p></div></div></blockquote><div><br></div><div>Yes. Done.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Clause 9. Physical package.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Note: If M1.13 is not in Clause 8, an equivalent requirement certainly needs to be added to the main text in clause 9 and refer to RFC 7231.</span></p></div></div></blockquote><div><br></div><div><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:14.6666660308838px">RFC 7231 is referenced in</span> 9.2.3.2.3 and 9.2.3.2.4. We intend to reformulate requirements on</div><div>producers/consumers as requirements on data, thus dropping M1.13.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">9.2.3.2 (p. 34)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> I suggest rewording <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">"For all other physical package formats, the package implementer should include an XML stream, known as the Media Types stream, in the package. [S2.2] The Media Types stream shall not be mapped to a part by the package implementer. [M2.1] This stream is therefore not URI-addressable. However, it can be interleaved in the physical package using the same mechanisms used for interleaving parts."<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> to<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">"For all other physical package formats, the package implementer should include an XML stream, described in this specification as the Media Types stream, in the package. [S2.2] The Media Types stream shall not be mapped to a part by the package implementer. [M2.1] This stream is therefore not URI-addressable. However, it can be interleaved in the physical package using the same mechanisms used for interleaving parts."</span></p></div></div></blockquote><div><br></div><div>We adopted the following.</div><div><br></div><div>For all other physical package formats, <a name="14e2373b1c66996c_s2_2">the package should include an XML stream called the <span>Media Types stream</span></a><span>.</span> [S2.2] <a name="14e2373b1c66996c_m2_1">The Media Types stream shall not be mapped to a part by the package
implementer.</a> [M2.1] This stream is therefore not URI-addressable. However,
it can be interleaved in the physical package using the same mechanisms used
for interleaving parts.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">If people are against adding a note to the definition of "media types stream", could we insert an example here that gives the /[Content_Types].xml name as an example for a stream in a ZIP Archive as described in Clause 9.3.? That would partly explain the ContentType attributes appearing in the tables below. Otherwise perhaps we need a reference to Annex C for the schema for the Media Types Stream.</span></p></div></div></blockquote><div><br></div><div>Again, we think that 9.3 is the right place for introducing the file name <span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:14.6666660308838px">[Content_Types].xml.</span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">9.2.3.3 (starts at p. 35)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Suggest changing each use of "as defined in RFC 7231" to "using the syntax provided in RFC 7231 3.1.1.1". See general issue 3.</span></p></div></div></blockquote><div><br></div><div>Done. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">9.3.7 (p.45)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Murata-san is proposing deletion of two paragraphs, one of which is requirement M3.10. Perhaps need to apply number M3.10 to the new paragraph above.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I’ve attached a text file with (almost) the same content. A just fixed a character set problem for [ and ] -- presumably generated when moving a text file from the Mac.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I hope this will be useful at the meeting in London. I am going to be sailing for a month starting this weekend and will not be checking my Library of Congress e-mail while away.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> Have a good time in London.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> Caroline<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> </span></p></div></div></blockquote><div><br></div><div> 149 : Removed the allowance for media type to be an empty string, as t </div><div> 149 : s this conflicts with the definition of media type in RFC 2046 and the existin </div><div> 175 : map logical item name(s) mapped to the Media Type s stream in a ZIP archive to </div><div> 189 : ternet Mail Extensions (MIME) Part Two: Media Type s, The Internet Society, N. </div><div> 206 : d in accordance with RFC?3986. The term media type is used in accordance with </div><div> 230 : l1 \n 26partstream of bytes with a MIME media type and associated common prope </div><div> 311 : are named and related. Parts have MIME media type s and are uniquely identifie </div><div> 334 : Media type The type of content stored </div><div> 336 : The package implementer shall require a media type and the format designer sha </div><div> 336 : d the format designer shall specify the media type . [M1.2] Growth Hint A sug </div><div> 371 : Media type s Each part shall have a me </div><div> 372 : Each part shall have a media type , as defined in RFC 2046, to </div><div> 372 : in that part, consisting of a top-level media type and a subtype, optionally q </div><div> 373 : ht restrict the usage of parameters for media type s. [O1.2] Media types for p </div><div> 374 : Media type s for parts defined in this </div><div> 532 : g part in ways that are specific to the media type of the part; that is, in ar </div><div> 532 : om consumers that do not understand the media type s of the parts containing su </div><div> 537 : The media type of the Relationships part i </div><div> 598 : form to this naming convention have the media type for a Relationships part. [ </div><div> 655 : atterns and mechanisms for storing part media type s. This Open Packaging speci </div><div> 660 : oblems. [Example: Associating arbitrary media type s with parts and supporting </div><div> 673 : Part media type Identifies the kind of con </div><div> 675 : ide a physical mapping for each part’s media type . [M2.2] Part contents Stor </div><div> 682 : Mapping Media Type s to Parts Introduction Th </div><div> 684 : apping with a mechanism for associating media type s with parts. [M2.3] Some p </div><div> 685 : have a native mechanism for associating media type s with parts. [Example: The </div><div> 685 : he header of a MIME entity associates a media type with that MIME entity. end </div><div> 685 : ld use the native mechanism to map part media type s to parts. [S2.1] For all </div><div> 686 : should include an XML stream called the Media Type s stream. [S2.2] The Media T </div><div> 686 : lled the Media Types stream. [S2.2] The Media Type s stream shall not be mapped </div><div> 687 : Media Type s Stream Markup Introductio </div><div> 689 : The content of the Media Type s stream shall conform to th </div><div> 690 : The Media Type s stream contains XML with a </div><div> 690 : gs from the extensions of part names to media type s. Override elements specify </div><div> 690 : media types. Override elements specify media type s on parts that are not cove </div><div> 691 : (§ REF _Ref310242801 \r \h 8.5.2), the Media Type s stream shall specify either </div><div> 696 : of Default and Override elements in the Media Type s stream is not significant. </div><div> 701 : package implementer can define Default media type mappings even though no par </div><div> 707 : The root element of the Media Type s stream. Default Element </div><div> 730 : A media type specified using the syntax </div><div> 730 : ed in RFC 7231 §3.1.1.1. Indicates the media type of any matching parts (unles </div><div> 730 : The package implementer shall require a media type in a Default element and th </div><div> 730 : d the format designer shall specify the media type . [M2.6] annotation Define </div><div> 732 : gs from the extensions of part names to media type s. Override Element The st </div><div> 749 : A media type specified using the syntax </div><div> 749 : ed in RFC 7231 §3.1.1.1. Indicates the media type of the part referenced by th </div><div> 749 : The package implementer shall require a media type and the format designer sha </div><div> 749 : d the format designer shall specify the media type in an Override element. [M2 </div><div> 757 : Specifies media type s on parts that are not cove </div><div> 758 : Media Type s Stream Markup Example [Ex </div><div> 760 : ding" \n \t 9? SEQ Example \* ARABIC 6. Media Type s stream markup <Types x </div><div> 768 : The Types element is a container for media type s to be used within the pack </div><div> 769 : e list of parts and their corresponding media type s as defined by the Media Ty </div><div> 769 : esponding media types as defined by the Media Type s stream markup above. Part </div><div> 771 : Media type /a/b/sample1.txt text/pla </div><div> 781 : Setting a Part Media Type in the Media Types Stream </div><div> 781 : Setting a Part Media Type in the Media Type s Stream When adding a new </div><div> 782 : package implementer shall ensure that a media type for that part is specified </div><div> 782 : type for that part is specified in the Media Type s stream; the package implem </div><div> 784 : Override element shall be added to the Media Type s stream. Compare the resul </div><div> 785 : tributes of the Default elements in the Media Type s stream. The comparison sha </div><div> 786 : matching Extension attribute, then the media type of the new part shall be co </div><div> 787 : If the media type s match, no further action i </div><div> 788 : If the media type s do not match, a new Overri </div><div> 788 : Override element shall be added to the Media Type s stream. If there is no D </div><div> 789 : Override element shall be added to the Media Type s stream. Determining a Par </div><div> 790 : Determining a Part Media Type from the Media Types Stream </div><div> 790 : Determining a Part Media Type from the Media Type s Stream To get the media t </div><div> 791 : To get the media type of a part, the package impl </div><div> 796 : Check the Default elements of the Media Type s stream, comparing the exte </div><div> 800 : rawn from other XML-namespaces into the Media Type s stream markup. [M2.10] Ma </div><div> 834 : ogical item does not have an associated media type . [O2.7] The package impleme </div><div> 877 : Part media type ZIP item containing the Me </div><div> 878 : ZIP item containing the Media Type s stream described in?§ REF </div><div> 891 : ogical item prefix has no corresponding media type . [M3.5] Mapping ZIP Item N </div><div> 908 : Mapping the Media Type s Stream In ZIP archives, t </div><div> 909 : In ZIP archives, the Media Type s stream shall be stored in </div><div> 910 : map logical item name(s) mapped to the Media Type s stream in a ZIP archive to </div><div> 910 : racters "[" and "]" were chosen for the Media Type s stream name specifically b </div><div>1006 : operties part. The Core Properties part media type is defined in REF _Ref1433 </div><div>1056 : rtificate parts. Relationship names and media type s relating to the use of dig </div><div>1069 : e certificate may be signed. [O6.6] The media type s of the Digital Signature C </div><div>1079 : query components that specify the part media type as described in?§ REF _Ref1 </div><div>1079 : specify in a case-sensitive manner the media type of the referenced part. [M6 </div><div>1106 : ences to package parts include the part media type as a query component. The s </div><div>1108 : where value is the media type of the targeted part. [Not </div><div>1112 : In the following example, the media type is “application/vnd.openxml </div><div>1318 : t with the query component matching the media type of the target part, necessa </div><div>1328 : When validating digital signatures, the media type and the digest contained in </div><div>1335 : ference elements includes verifying the media type of the referenced part and </div><div>1335 : dia type of the referenced part and the media type specified in the reference </div><div>2229 : Media Type s Stream <xs:schema xml </div><div>2477 : Media Type s Stream default namespace </div><div>2607 : (normative)Standard Namespaces and Media type s The namespaces available </div><div>2612 : Media Type s stream <a href="http://schemas.ope" target="_blank">http://schemas.ope</a> </div><div>2623 : The media type s for the parts defined in t </div><div>2623 : 9361607 \h \* MERGEFORMAT Package-wide media type s Table STYLEREF \s "Appe </div><div>2624 : E? SEQ Table \* ARABIC 2. Package-wide media type s Description Media type </div><div>2626 : Media type Core Properties part appl </div><div>2638 : s and format designers shall not create media type s with parameters for the pa </div><div>2638 : eat the presence of parameters in these media type s as an error. [M1.22] The </div><div>2720 : The package implementer shall require a media type and the format designer sha </div><div>2720 : d the format designer shall specify the media type . REF _Ref129157037 \r \h </div><div>2765 : create and only recognize parts with a media type ; format designers shall spe </div><div>2765 : type; format designers shall specify a media type for each part included in t </div><div>2765 : e for each part included in the format. Media type s for package parts shall fi </div><div>2765 : shall fit the definition and syntax for media type s as specified in RFC 7231,? </div><div>2770 : _14 \h \* MERGEFORMAT The value of the media type is permitted to be the empt </div><div>2771 : Media type s shall not use linear white </div><div>2771 : or between an attribute and its value. Media type s also shall not have leadin </div><div>2771 : age implementers shall create only such media type s and shall require such med </div><div>2771 : such media types and shall require such media type s when retrieving a part fro </div><div>2771 : ormat designers shall specify only such media type s for inclusion in the forma </div><div>2776 : The package implementer shall require a media type that does not include comme </div><div>2776 : he format designer shall specify such a media type . REF _Ref129157439 \r \h </div><div>2807 : s and format designers shall not create media type s with parameters for the pa </div><div>2807 : eat the presence of parameters in these media type s as an error. REF _Ref143 </div><div>2842 : form to this naming convention have the media type for a Relationships part </div><div>2877 : ht restrict the usage of parameters for media type s. REF _Ref140643471 \r \h </div><div>2912 : REF m2_1 \h The Media Type s stream shall not be mapped </div><div>2916 : red components package, part name, part media type , and part contents. REF </div><div>2920 : apping with a mechanism for associating media type s with parts. REF _Ref129 </div><div>2924 : than relationships parts (§8.5.2), the Media Type s stream shall specify either </div><div>2935 : The package implementer shall require a media type in a Default element and th </div><div>2935 : d the format designer shall specify the media type . REF _Ref140665453 \r \h </div><div>2940 : The package implementer shall require a media type and the format designer sha </div><div>2940 : d the format designer shall specify the media type in an Override element. RE </div><div>2945 : package implementer shall ensure that a media type for that part is specified </div><div>2945 : type for that part is specified in the Media Type s stream; the package implem </div><div>2949 : REF m2_9 \h To get the media type of a part, the package impl </div><div>2953 : rawn from other XML-namespaces into the Media Type s stream markup. REF _Ref </div><div>2990 : A: Only relevant if using the media type mapping strategy specified </div><div>3001 : ave a native mechanism for representing media type s. REF s2_1b \h \* MERGEF </div><div>3001 : uld use the native mechanism to map the media type for a part. REF _Ref12915 </div><div>3005 : If no native method of mapping a media type to a part exists, REF s2_ </div><div>3005 : d XML stream in the package, called the Media Type s stream REF _Ref129159669 </div><div>3026 : A: Only relevant if using the media type mapping strategy specified </div><div>3053 : package implementer can define Default media type mappings even though no par </div><div>3061 : ogical item does not have an associated media type . REF _Ref112211501 \r \h </div><div>3066 : A: Only relevant if using the media type mapping strategy specified </div><div>3095 : ogical item prefix has no corresponding media type . REF _Ref140683954 \r \h </div><div>3117 : _10 \h Package implementers shall store media type data in an item(s) mapped t </div><div>3121 : map logical item name(s) mapped to the Media Type s stream in a ZIP archive to </div><div>3316 : uery components that specifies the part media type as described in?§12.3.5.7. </div><div>3316 : ent that incorrectly specifies the part media type to be an error. REF _Ref </div><div>3321 : th a query component that specifies the media type that matches the media type </div><div>3321 : ecifies the media type that matches the media type of the referenced part. The </div><div>3321 : ignature validation to fail if the part media type compared in a case-sensitiv </div><div>3321 : pared in a case-sensitive manner to the media type specified in the query comp </div><div>3414 : signatures, consumers shall verify the media type and the digest contained in </div><div>C:\Users\makoto\Downloads\OPC pre-WD2 London.docx (matched:23 score:41.8)</div><div> 149 : Removed the allowance for media type to be an empty string, as t </div><div> 149 : s this conflicts with the definition of media type in RFC 2046 and the existin </div><div> 190 : ternet Mail Extensions (MIME) Part Two: Media Type s, The Internet Society, N. </div><div> 208 : d in accordance with RFC?3986. The term media type is used in accordance with </div><div> 315 : nd related. Parts have content typeMIME media type s and are uniquely identifie </div><div> 377 : This specification uses MIME media type s as defined in RFC 2046 to </div><div> 377 : stored in part. Each part shall have a media type , as defined in RFC 2046, to </div><div> 377 : in that part, consisting of a top-level media type and a subtype, such as appl </div><div> 378 : tent typeMedia types define a top-level media type , a subtype, and an optional </div><div> 378 : shall fit the definition and syntax for media type s as specified in RFC 2616,? </div><div> 700 : have a native mechanism for associating media type s with partsrepresenting con </div><div> 700 : he header of a MIME entity associates a media type with that MIME entity. end </div><div> 701 : ally named an XML stream , known as the Media Type s stream, in the package, .c </div><div> 701 : am, in the package, .called the Content Media Type s stream. [S2.2] The Content </div><div> 704 : Media Type s stream markupIntroduction </div><div> 705 : The content of the Media Type s stream shall conform to th </div><div> 797 : Setting the a Content TypePart Media Type of a Partin the Media Types </div><div> 797 : ent TypePart Media Type of a Partin the Media Type s Stream When adding a new </div><div> 806 : ypea Part Media tType of a Partfrom the Media Type s Stream To get the content </div><div> 893 : Part content media type ZIP item(s) containing XML </div><div> 894 : r each part according to the patternthe Media Type s stream described in?§ REF </div><div> 925 : In ZIP archives, the Media Type s stream shall be stored in </div><div>2922 : shall fit the definition and syntax for media type s as specified in RFC 261672 </div><div><br></div><div>Regards,</div><div>Makoto</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Caroline Arms<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Library of Congress Contractor<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Co-compiler of Sustainability of Digital Formats resource <a href="http://www.digitalpreservation.gov/formats/" target="_blank">http://www.digitalpreservation.gov/formats/</a><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">** Views expressed are personal and not necessarily those of the institution **<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> <a href="mailto:eb2mmrt@gmail.com" target="_blank">eb2mmrt@gmail.com</a> [mailto:<a href="mailto:eb2mmrt@gmail.com" target="_blank">eb2mmrt@gmail.com</a>] <b>On Behalf Of </b>MURATA Makoto<br><b>Sent:</b> Sunday, May 10, 2015 5:23 AM<br><b>To:</b> SC34<br><b>Subject:</b> Revised text for OPC<u></u><u></u></span></p><div><div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">Folks,<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">In the draft minutes, I was tasked to "make a further update to the<u></u><u></u></p></div><div><p class="MsoNormal">draft text to incorporate references to RFC 2045 and/or RFC 2046 for<u></u><u></u></p></div><div><p class="MsoNormal">the concepts of media type and subtype and to RFC 7231 (replacing the<u></u><u></u></p></div><div><p class="MsoNormal">reference to RFC 2616) for the syntactic definition (ABNF) in clause 8<u></u><u></u></p></div><div><p class="MsoNormal">Package Model." I tried to do the task.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Later, Caroline sent some useful comments from a more careful look at<u></u><u></u></p></div><div><p class="MsoNormal">the latest draft. I accepted most of her comments and even proposed<u></u><u></u></p></div><div><p class="MsoNormal">text (thank you, Caroline!). My disposition is shown in an attached <u></u><u></u></p></div><div><p class="MsoNormal">document ("MediaTypeCheck...").<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Please find my rewrite. Although I already sent a rewrite of the<u></u><u></u></p></div><div><p class="MsoNormal">Content Type regular expression (see the threead "Rewriting the regexp<u></u><u></u></p></div><div><p class="MsoNormal">for @ContentType in opc-contentTypes.xsd"), I have not incorporated <u></u><u></u></p></div><div><p class="MsoNormal">my rewrite yet.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Regards,<u></u><u></u></p></div><div><p class="MsoNormal">Makoto<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br>Praying for the victims of the Japan Tohoku earthquake<br><br>Makoto</div>
</div></div>