<div dir="ltr">The XAdES committee is now considering a big change <div>in <span style="font-size:14px">XAdESENv111.xsd. In my understanding, they </span></div><div><span style="font-size:14px">will make a decision before our F2F.</span></div><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">Regards,</span></div><div><span style="font-size:14px">Makoto</span></div><div><span style="font-size:14px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-05-30 0:55 GMT+09:00 John Haug <span dir="ltr"><<a href="mailto:johnhaug@exchange.microsoft.com" target="_blank">johnhaug@exchange.microsoft.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546a">I was thinking that the different namespaces and named conformance levels could be abstracted away from the requirements. For example, “if validation data
is present…” or referencing an element without a namespace. Both methods are used in MS-OFFCRYPTO and ODF.<u></u><u></u></span></p><span class="">
<p class="MsoNormal">> begin with careful comparison of the upcoming XAdES and existing XAdES<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546a"><u></u><u></u></span></p>
</span><p class="MsoNormal"><a name="14da062a654bfcb1__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546a">Yes, I agree. I’m not as familiar with the upcoming XAdES and may or may not be right on my claims. I will try to understand it
better before London. I found it more difficult to parse than the existing standard when I looked at it in the past… Do you know if there is a newer version than 0.0.9 (link we received from Juan Carlos Cruellas after the Bellevue meeting)?<u></u><u></u></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546a"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546a">John<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546a"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;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> Thursday, May 28, 2015 4:06 PM<br>
<b>To:</b> <a href="mailto:e-SC34-WG4@ecma-international.org" target="_blank">e-SC34-WG4@ecma-international.org</a></span></p><div><div class="h5"><br>
<b>Subject:</b> Re: Japanese position on the introduction of XAdES to OPC.<u></u><u></u></div></div><p></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">John,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">2015-05-29 3:21 GMT+09:00 John Haug <<a href="mailto:johnhaug@exchange.microsoft.com" target="_blank">johnhaug@exchange.microsoft.com</a>>:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hello –</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>
</span>Even if we introduce the new version of XAdES as part of the revision of OPC, the extension points will continue to be available.<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Perhaps I misunderstood, then. I thought the position was to effectively prohibit use of the current
XAdES and only allow use of the new upcoming version. Even discouraging use of the existing one in favor of the upcoming one seems a bit much in my mind. As long as OPC gives guidance on which choices to make when implementing XAdES, that should suffice
for interoperability and leave flexibility to implementers to choose what they support, however good or bad an idea it is – i.e., no signature, plain XMLDSig, current XAdES, upcoming XAdES.</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Sure. The upcoming OPC should not discourage the use of the existing XAdES.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I may not be familiar enough with the details of the upcoming XAdES, but I think the small number
of interop requirements that we might want to add to OPC apply equally to both the established and upcoming XAdES. I think it can be done in a way that is agnostic to which edition of XAdES implementers choose. I’m don’t think it’s quite right to think of
a “Microsoft XAdES” as opposed to regular XAdES or XYZ Corp’s XAdES. Our implementation is conformant XAdES and we simply publish a document containing information about the choices we made where XAdES allows flexibility so that others know what to expect
in OOXML files generated by Office and what we didn’t implement support for in Office.</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Having seen the latest draft and schemas of the upcoming XAdES, I strongly think that we <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">need different sets of requirements on the upcoming XAdES and the existing XAdES. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">For example, namespaces are different. The schema XAdESENv111.xsd for the existing <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">version and that for the upcoming version are different. The number of conformance levels <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">are different. The organization of the specs are different: for example, level C (references <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">to validation data) are moved to the second part of the upcoming XAdES.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">If we decide to implement one set of requirements for the upcoming XAdES and <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">another for the existing XAdES, we will probably have to introduce different sets <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">of relationships for the two XAdES. They are for preserving seemingly orphan <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">parts, which are referenced by XAdES by relative URIs. If we do not allow <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">the use of the second part of the upcoming XAdES, we do not need such <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">relationships for the upcoming XAdES. I am not completely sure but <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I think that the URI attribute in Include element of the existing XAdES <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">requires such a relationship type.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Given the above…</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>
</span>It means that a set of conventions on the use of the new version of XAdES will be established. New applications based on the revised OPC will follow these conventions.<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I fully agree with the first sentence immediately above and think it applies to XAdES in general;
or, slightly differently, to both the current and upcoming versions. The second sentence could be taken to mean that use of the current XAdES is deprecated and implementations should use the upcoming one. The upcoming one is so early in its life that I think
this might be premature. I may also be misinterpreting that second sentence and this isn’t what you intended.</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Let me try again. New applications implementing the upcoming version of XAdES will follow these conventions.<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>
</span>Then, we will have two sets of conventions: Microsoft XAdES and the revised OPC. They are unlikely to be identical.<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I think this is the crux of what we need to figure out in detail. My impression is that XAdES hasn’t
changed terribly in its markup details, which would allow OPC to make restricting statements that would apply equally to current and upcoming XAdES. I may be wrong. Though if the differences are minor, we may simply note something like: for TS 101 903: foo,
and for EN 319 132: bar. We have a proposed set of requirements based on TS 101 903 in a draft we looked at in Bellevue, very similar to both MS-OFFCRYPTO and ODF 1.2, which we could evaluate against the latest draft of EN 319 132 to get a better idea of
this.</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">My impression is different. Details of XAdES markup has changed a lot.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Perhaps, the best way to go forward is to begin with careful comparison of the upcoming <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">XAdES and existing XAdES. I will prepare something by the F2F.<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>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">John</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","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> Wednesday, May 27, 2015 7:29 PM<br>
<b>To:</b> John Haug<br>
<b>Cc:</b> <a href="mailto:e-SC34-WG4@ecma-international.org" target="_blank">e-SC34-WG4@ecma-international.org</a><br>
<b>Subject:</b> Re: Japanese position on the introduction of XAdES to OPC.</span><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">John,<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I am afraid that I was not clear. OPC as of now already provides extension points. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">They allow third parties to introduce legitimate extensions. Microsoft XAdES is <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">such a legitimate extension.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Even if we introduce the new version of XAdES as part of the revision of OPC, <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">the extension points will continue to be available. Thus, Microsoft XAdES <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">will continue to be a legitimate extension of OPC. Implementations of
<br>
such extensions will continue to be conformant. Backward compatibility<br>
will not be destroyed.<br>
<br>
Then, what does it mean to incorporate the new version of XAdES into <br>
the revision of OPC? It means that a set of conventions on the use of <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">the new version of XAdES will be established. New applications <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">based on the revised OPC will follow these conventions.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">If we incorporate the existing version of XAdES into the revision of <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">OPC, we will establish a set of conventions on the use of <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">the existing version of XAdES. Then, we will have two <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">sets of conventions: Microsoft XAdES and the revised OPC. They <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">are unlikely to be identical. If they diverge, we will cause a lot <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">of troubles to users and implementations. I thus think that <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">not incorporating the existing version of XAdES into the <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">revised OPC is the best way to provide backward compatibility.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Perhaps, one solution is to provide an informative note about <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">the use of the existing XAdES in the OPC revision. The note <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">should say that such use IS conformant.<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>
<p class="MsoNormal"> <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>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">2015-05-28 8:19 GMT+09:00 John Haug <<a href="mailto:johnhaug@exchange.microsoft.com" target="_blank">johnhaug@exchange.microsoft.com</a>>:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I suspect my position on this would be easily guessed, but I strongly disfavor updating OPC in a
way that breaks backward compatibility. Even putting aside my Microsoft hat representing the single largest installed base of implementations of OPC, whether that be Office or XPS (both the .xps file format and Windows print spool format which implement ECMA-388,
which incorporates OPC by reference) or .NET Framework (System.IO.Packaging) or Windows Presentation Framework/XAML – and there are other implementers – I’d have to argue the point that where software has adopted digital signatures based on XMLDSig and gone
further, the existing XAdES specifications are what has been adopted. We’d do a disservice to current implementers and to users of many current documents to create a discontinuity in compatibility.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I believe we are getting too far down into the details of whatever work ETSI is doing now or may
do in the future to revise XAdES. There is risk I feel is inappropriate to take on in requiring use of a new, unpublished/unapproved proposed standard that has no adoption by industry while ignoring one that does have at least some industry adoption. Regardless
of considering which version to require, I don’t believe we need to or should mandate one version or another – let implementers decide what level of security they need for their application. I assert that our interest from the perspective of 29500 is to provide
requirements that improve interoperability among implementations of OPC that use XMLDSig and XAdES. And I still believe we can do that with simple statements like we’ve looked at before, ones that just require this choice or that where XAdES provides options
or leaves something as implementation-specific. Both the new and existing versions of XAdES are backward-compatible extensions of XMLDSig, the fundamental underlying technology the use of which is an important choice to make for the standard, so the previous
sentence should hold.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>
</span>As you know, Japanese XAdES experts are unhappy with the MS implementation.<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I think this is in reference to Office writing out SignaturePolicyIdentifier elements that are empty
or use SignaturePolicyImplied. Whether to allow that (which is legal XAdES) is a question we can take up along with the context of other related standards and implementations (e.g., ODF and MS-OFFCRYPTO make no statement on these elements). Chris and I can
raise those concerns with the development team here, but let’s leave any individual concerns with Office’s particular implementation choices separate from what we choose to specify in the standard.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">John</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","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> Tuesday, May 26, 2015 8:02 PM<br>
<b>To:</b> SC34<br>
<b>Subject:</b> Japanese position on the introduction of XAdES to OPC.</span><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">Dear colleagues,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">This mail is to describe the Japanese position on the <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">introduction of XAdES to OPC. Japan believes that the <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">ongoing revision of OPC (Open Packaging Conventions) <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">should use the first part of the new version of XAdES and<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">nothing else.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">As we have discussed, there are two versions of XAdES. An existing<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">version of XAdES is documented in ETSI technical specifications, while<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">a new and incompatible version is expected to become ENs (European<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Standards) in one year.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">The first version is already implemented by Microsoft Office. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">This means that, if we introduce this version of XAdES to OPC <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">as a standard, we will run the risk of making the current implementation<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">by Microsoft non-conformant. As you know, Japanese XAdES <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">experts are unhappy with the MS implementation.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">The latest version of XAdES consists of two specifications.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Apparently, Europe is committed to the first part. The second part <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">appears to be an alibi for not abandoning some<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">features of the old version.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Moreover, the first part does not use any external files. But the<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">second does. This means that if such external files exist in an OPC<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">package, they look like orphans and will be thrown away by many<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">implementations including MS Office. To avoid this problem, we will<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">have to introduce relationship types. Japan does not think that the <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">second part has advantages significant enough for this additional effort.<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>
<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>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal">--
<u></u><u></u></p>
<div>
<p class="MsoNormal"><br>
Praying for the victims of the Japan Tohoku earthquake<br>
<br>
Makoto<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<p class="MsoNormal"><br>
Praying for the victims of the Japan Tohoku earthquake<br>
<br>
Makoto<u></u><u></u></p>
</div></div></div>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><br>Praying for the victims of the Japan Tohoku earthquake<br><br>Makoto</div>
</div>