ODF 1.2 Part 3 "IRI" and "relative IRI" used throughout are never defined

1. Add [RFC3987] to the Normative References.

2. Define IRI and relative IRI in some way (a terminology/nomenclature entry would be helpful), with reference to the applicable definitions in [RFC3987] and/or in a specific portion of Part 3, such as section 2.7.

3. Specify when and how IRI-%-encoding kicks in for URI path segments that are within the package and for URI references that end in the package.

4. Be careful about speaking of IRIs vs IRI-encoding in URIs and URIs generally.

5. Make sure we have accounted for normative provisions of [RFC3986] and [RFC3987], of the anyURI datatype, and of whatever it is we say manifest:full-path is and what its relationship to the name recorded for a file as a data unit of the Zip archive.

Change description of 3.7 Usage of IRIs Within Packages to:

Within the files contained in a package, relative IRIs as defined by [RFC3987] may be used to reference other files within the same package.
OpenDocument Package Consumers shall resolve relative IRIs that occur within a file of a package as follows:
1. The file entry path is the file name of the file within the Zip file which contains the relative IRI, including its relative path.
2. The package base IRI is the base IRI which would be established for the package itself as defined in §5.1 of [RFC3986].
3. If the relative IRI does not match the rule for "relative-ref" defined in §4.2 of [RFC3986] or if the relative IRI does start with a "/" character (U+002F, SOLIDUS) then it is resolved as defined in §5.2 of [RFC3986] with the package base IRI as base URI.
4. Otherwise the relative IRI is copied into a relative IRI buffer and the file entry path is copied into a file entry path buffer.
5. If the relative IRI buffer starts with the character sequence "./" (U+002E, FULL STOP, followed by U+002F, SOLIDUS) then that character sequence it removed from the buffer. Continue with step 5.
6. If the relative IRI buffer starts with the character sequence "../" (U+002E, FULL STOP, followed by U+002E, FULL STOP, followed by U+002F, SOLIDUS) and

• if the file entry path buffer contains only a file name but no relative path, then the "../" is removed from the relative IRI buffer. The content of the relative IRI buffer then is resolved as defined in §5.2 of [RFC3986] with the package base IRI as base URI.
• if the file entry path buffer contains at least one relative path component, the first relative path component up to and including the first "/" character (U+002F, SOLIDUS) is removed. Continue with step 5.
  7. If the relative IRI buffer contains one or more "#" (U+0023, NUMBER SIGN) characters, the first "#" character is removed from the relative IRI buffer. The characters following the "#" character are copied into a fragment identifier buffer and are then also removed from the relative IRI buffer.
  8. The content of the relative IRI buffer is interpreted as a file name within the package, that is, as the name of a file including its relative path within the Zip file.
  9. If a fragment buffer has been created and is not empty, its content may be resolved as fragment identifier, as defined by §3.5 of [RFC3986].

Note: Files whose relative path starts with "META-INF/" are considered to be part of the OpenDocument package rather than of the content stored within the package. Therefore, different rules regarding the resolution of relative IRIs may apply. In particular the base URI for the resolution of relative IRIs may be the package base IRI rather than the file entry base IRI.