XMLWordPrintable

    Details

    • Type: Bug
    • Status: Applied
    • Priority: Trivial
    • Resolution: No Action
    • Affects Version/s: ODF 1.2 CD 06
    • Fix Version/s: None
    • Component/s: Public Review, Security
    • Labels:
      None
    • Resolution:
      Hide

      No action.
      Re #1: The separation between the ODF package, and the content stored within it, should be clear. Part 3 defined ODF package format. This is based on a Zip-File, but it is more than just that. In particular, each ODF package, even an empty one, contains a META-INF/manifest.xml. This file is an administrative file of an package. An ODF package utility would not expose it to the user.
      Re #2: Where the resolution of relative IRIs differs from the definition in section 3.7, this is explicitly stated. Right now, the only administrative files in a package are the manifest.xml file, and digital signature files. The manifest.xml file does not contain relative IRIs. For signature files, the exceptions are explicitly stated.
      Re #3: An ODF package is a ZIP file, and RFC3986 itself does not specify how files within a Zip file can be references. But section 3.7 covers this. Therefore, a digital signature implementation that implements only RFC3986 indeed would fail to reference files within an ODF package. But not because section 3.7 defines specific rules for that, but because RFC3986 itself does not permit referencing files in a Zip file.
      Re #4: digital signature files (like the manifest) are considered to be administrative files of the package. It is an implementation detail of the ODF package that they are contained in a META-INF folder, and it does not appear to be reasonable to prefix any file that is referenced in a signature with "../" only because digital signatures are stored in the META-INF folder. Using the package base as base URI has further practical advantages. First this provides consistency with the manifest.xml file. Second, the IRI references can be interpreted as paths within the package without transformations (except character encoding transformation that may be required).
      Re #5: While rationales and examples of course are helpful, they do not belong into an international standard, but should be provided as supplemental material.

      Show
      No action. Re #1: The separation between the ODF package, and the content stored within it, should be clear. Part 3 defined ODF package format. This is based on a Zip-File, but it is more than just that. In particular, each ODF package, even an empty one, contains a META-INF/manifest.xml. This file is an administrative file of an package. An ODF package utility would not expose it to the user. Re #2: Where the resolution of relative IRIs differs from the definition in section 3.7, this is explicitly stated. Right now, the only administrative files in a package are the manifest.xml file, and digital signature files. The manifest.xml file does not contain relative IRIs. For signature files, the exceptions are explicitly stated. Re #3: An ODF package is a ZIP file, and RFC3986 itself does not specify how files within a Zip file can be references. But section 3.7 covers this. Therefore, a digital signature implementation that implements only RFC3986 indeed would fail to reference files within an ODF package. But not because section 3.7 defines specific rules for that, but because RFC3986 itself does not permit referencing files in a Zip file. Re #4: digital signature files (like the manifest) are considered to be administrative files of the package. It is an implementation detail of the ODF package that they are contained in a META-INF folder, and it does not appear to be reasonable to prefix any file that is referenced in a signature with "../" only because digital signatures are stored in the META-INF folder. Using the package base as base URI has further practical advantages. First this provides consistency with the manifest.xml file. Second, the IRI references can be interpreted as paths within the package without transformations (except character encoding transformation that may be required). Re #5: While rationales and examples of course are helpful, they do not belong into an international standard, but should be provided as supplemental material.

      Description

      Copied from office-comment list

      Original author: "Pope, Nick" <Nick.Pope@thales-esecurity.com>
      Original date: 27 Dec 2010 12:17:10 -0000
      Original URL: http://lists.oasis-open.org/archives/office-comment/201012/msg00081.html

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              rcweir Robert Weir (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: