Regina,
Another minor point, you ask if Schneier-Errata is normative or
non-normative?
We mention Schneier twice and the errata once:
3.4.2 Encryption Process:
The derived key is used together with the
initialization vector to encrypt the file using the Blowfish
algorithm in 8-bit cipher feedback (8-bit CFB) mode (see
[Schneier]).
4.16.1 manifest:algorithm-name
Note:
An errata for [Schneier][Schneier] is available at
[Schneier-Errata].
Since we don't cite any section of Schneier, I'm
inclined to say both Schneier and Scheier-Errata are both
non-normative references.
Good catch!
Thoughts?
Patrick
On 8/9/19 6:11 PM, Regina Henschel
wrote:
Hi
Patrick,
The following notes are not intended to be a reason to postpone a
committee draft, therefore I do not create an issue. If we stop on
each typo, we will never get a new version. It is not possible to
make an error free text of such length.
Only the different version numbers should be clarified, because
that hits automatic validation.
content
--------
Page 15
item 4.11 Does element <PGPData> contain something related
to signatures?
Page 20
item 4.16.14.3, The schema has value "1.3", the text value "1.2".
editorial
---------
The Working Draft number is not consistent: 07 in Title, wd06 in
footer and wd09 in file name.
Pages 6 and 7
{Schneier-Errata] either Normative or Non-Normative
Page 8
Suspicious [RNG] in item E)
Page 15
item 4.8, The e in encrypted-key is not part of the "element"
character style.
item 4.9, The word 'element' should have default character style.
Page 16
item 4.12, The words 'element contains' should have default
character style.
item 4.13, The word 'element' should have default character style.
Page 16
item 4.14, 4.15 It is not good to have in both cases the word
'contains'. In case of CipherValue 'contains' is correct, because
the raw encrypted data are the direct content of the element. But
in case of CipherData the encrypted data is not the direct
content. [xmldsig-core1] has the wording 'envelopes' in that case.
Inconsistent use with base64, 'a base64Binary sequence' (4.12) or
'a base64-encoded' (4.13) or 'in BASE64 encoding' (4.16.2, 4.16.5)
or 'encoded as base64binary' (4.16.12)
Page 18
item 4.16.7, The second 'For a ' should be aligned with the first
one.
Kind regards
Regina
Patrick Durusau schrieb am 07-Aug-19 um 03:58:
/Submitter's message/
Greetings!
Apologies for the delay but the light finally came on for the
PGP encryption element additions. Not nearly as difficult as I
thought it would be.
I will post a clean version tomorrow with a view of preparing
for a vote on a committee draft.
Hope everyone is having a great week!
Patrick
-- Patrick Durusau
*Document Name*: OpenDocument-v1.3-wd09-part2-packages.odt
<https://www.oasis-open.org/apps/org/workgroup/office/document.php?document_id=65742>
------------------------------------------------------------------------
*Description*
All issues applied.
Download Latest Revision
<https://www.oasis-open.org/apps/org/workgroup/office/download.php/65742/latest/OpenDocument-v1.3-wd09-part2-packages.odt>
Public Download Link
<https://www.oasis-open.org/committees/document.php?document_id=65742&wg_abbrev=office>
------------------------------------------------------------------------
*Submitter*: Patrick Durusau
*Group*: OASIS Open Document Format for Office Applications
(OpenDocument) TC
*Folder*: 1.3 Drafts
*Date submitted*: 2019-08-06 18:57:46
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC
that generates this mail. Follow this link to all your TCs in
OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
Patrick Durusau
patrick@durusau.net
Technical Advisory Board, OASIS (TAB)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau