diff --git a/THANKS b/THANKS
index 7a16c62..5f37ea9 100644
--- a/THANKS
+++ b/THANKS
@@ -32,6 +32,7 @@
 Erwin Haid <erwin.haid@gmx.de>
 Eun-cheol Joo
 Florian Delizy <florian.delizy@gmail.com>
+Force Charlie <charlieio@outlookc.com>
 François Simon <AT.GFI.Francois.SIMON@sesam-vitale.fr>
 Frederik Ramm <frederik@remote.org>
 gk7huki <gk7huki@gmail.com>
diff --git a/docs/appnote.txt b/docs/appnote.txt
index 985f6f8..64b1b3a 100644
--- a/docs/appnote.txt
+++ b/docs/appnote.txt
@@ -1,8 +1,8 @@
 File:    APPNOTE.TXT - .ZIP File Format Specification
-Version: 6.3.4 
-Status: Final - replaces version 6.3.3
-Revised: October 1, 2014
-Copyright (c) 1989 - 2014 PKWARE Inc., All Rights Reserved.
+Version: 6.3.8 
+Status: FINAL - replaces version 6.3.7
+Revised: June 15, 2020
+Copyright (c) 1989 - 2014, 2018, 2019, 2020 PKWARE Inc., All Rights Reserved.
 
 1.0 Introduction
 ---------------
@@ -33,10 +33,10 @@
 1.3 Trademarks
 --------------
 
-   1.3.1 PKWARE, PKZIP, SecureZIP, and PKSFX are registered trademarks of 
-   PKWARE, Inc. in the United States and elsewhere.  PKPatchMaker, 
-   Deflate64, and ZIP64 are trademarks of PKWARE, Inc.  Other marks 
-   referenced within this document appear for identification
+   1.3.1 PKWARE, PKZIP, Smartcrypt, SecureZIP, and PKSFX are registered 
+   trademarks of PKWARE, Inc. in the United States and elsewhere.  
+   PKPatchMaker, Deflate64, and ZIP64 are trademarks of PKWARE, Inc.  
+   Other marks referenced within this document appear for identification
    purposes only and are the property of their respective owners.
    
 
@@ -74,8 +74,8 @@
      +1-414-289-9789 FAX
      zipformat@pkware.com
 
-   1.5.2 Information about this format and copies of this document are publicly
-   available at:
+   1.5.2 Information about this format and a reference copy of this document
+   is publicly available at:
 
      http://www.pkware.com/appnote
 
@@ -116,7 +116,7 @@
    considered to be in the final form for that version of the document 
    and are not subject to further change until a new, higher version
    numbered document is published.  Newer versions of this format 
-   specification are intended to remain interoperable with with all prior 
+   specification are intended to remain interoperable with all prior 
    versions whenever technically possible.  
 
 2.2 Change Log
@@ -124,7 +124,7 @@
 
    Version       Change Description                        Date
    -------       ------------------                       ----------
-   5.2           -Single Password Symmetric Encryption    06/02/2003
+   5.2           -Single Password Symmetric Encryption    07/16/2003
                   storage
 
    6.1.0         -Smartcard compatibility                 01/20/2004
@@ -177,9 +177,51 @@
 
    6.3.3         -Formatting changes to support           09/01/2012
                   easier referencing of this APPNOTE
-                  from other documents and standards        
+                  from other documents and standards  
 
    6.3.4         -Address change                          10/01/2014
+ 
+   6.3.5         -Documented compression methods 16       11/31/2018
+                  and 99 (4.4.5, 4.6.1, 5.11, 5.17, 
+                  APPENDIX E)
+
+                 -Corrected several typographical 
+                  errors (2.1.2, 3.2, 4.1.1, 10.2)
+                 
+                 -Marked legacy algorithms as no
+                  longer suitable for use (4.4.5.1)
+
+                 -Added clarity on MS DOS time format
+                  (4.4.6)
+
+                 -Assign extrafield ID for Timestamps
+                  (4.5.2)
+
+                 -Field code description correction (A.2)
+
+                 -More consistent use of MAY/SHOULD/MUST
+
+                 -Expanded 0x0065 record attribute codes (B.2)
+
+                 -Initial information on 0x0022 Extra Data
+
+   6.3.6         -Corrected typographical error          04/26/2019
+                  (4.4.1.3) 
+
+   6.3.7         -Added Zstandard compression method ID  
+                  (4.4.5)
+
+                 -Corrected several reported typos
+
+                 -Marked intended use for general purpose bit 14
+ 
+                 -Added Data Stream Alignment Extra Data info
+                  (4.6.11)
+
+   6.3.8         -Resolved Zstandard compression method ID conflict  
+                  (4.4.5)
+
+                 -Added additional compression method ID values in use
 
 
 3.0 Notations
@@ -187,7 +229,7 @@
 
    3.1 Use of the term MUST or SHALL indicates a required element. 
 
-   3.2 MAY NOT or SHALL NOT indicates an element is prohibited from use. 
+   3.2 MUST NOT or SHALL NOT indicates an element is prohibited from use. 
 
    3.3 SHOULD indicates a RECOMMENDED element.
 
@@ -206,7 +248,7 @@
    although use of a file extension is not required.  Use of the 
    extension .ZIPX is also recognized and MAY be used for ZIP files.  
    Other common file extensions using the ZIP format include .JAR, .WAR, 
-   .DOCX, .XLXS, .PPTX, .ODT, .ODS, .ODP and others. Programs reading or 
+   .DOCX, .XLSX, .PPTX, .ODT, .ODS, .ODP and others. Programs reading or 
    writing ZIP files SHOULD rely on internal record signatures described 
    in this document to identify files in this format.
 
@@ -283,12 +325,12 @@
 
    4.3.1 A ZIP file MUST contain an "end of central directory record". A ZIP 
    file containing only an "end of central directory record" is considered an 
-   empty ZIP file.  Files may be added or replaced within a ZIP file, or deleted. 
+   empty ZIP file.  Files MAY be added or replaced within a ZIP file, or deleted. 
    A ZIP file MUST have only one "end of central directory record".  Other 
    records defined in this specification MAY be used as needed to support 
    storage requirements for individual ZIP files.
 
-   4.3.2 Each file placed into a ZIP file MUST be preceeded by  a "local 
+   4.3.2 Each file placed into a ZIP file MUST be preceded by  a "local 
    file header" record for that file.  Each "local file header" MUST be 
    accompanied by a corresponding "central directory header" record within 
    the central directory section of the ZIP file.
@@ -300,7 +342,7 @@
 
    4.3.4 Compression MUST NOT be applied to a "local file header", an "encryption
    header", or an "end of central directory record".  Individual "central 
-   directory records" must not be compressed, but the aggregate of all central
+   directory records" MUST NOT be compressed, but the aggregate of all central
    directory records MAY be compressed.    
 
    4.3.5 File data MAY be followed by a "data descriptor" for the file.  Data 
@@ -360,7 +402,7 @@
       .ZIP archive. 
 
       Zero-byte files, directories, and other file types that 
-      contain no content MUST not include file data.
+      contain no content MUST NOT include file data.
 
    4.3.9  Data descriptor:
 
@@ -377,8 +419,8 @@
       archives, the compressed and uncompressed sizes are 8 bytes each.
 
       4.3.9.2 When compressing files, compressed and uncompressed sizes 
-      should be stored in ZIP64 format (as 8 byte values) when a 
-      file's size exceeds 0xFFFFFFFF.   However ZIP64 format may be 
+      SHOULD be stored in ZIP64 format (as 8 byte values) when a 
+      file's size exceeds 0xFFFFFFFF.   However ZIP64 format MAY be 
       used regardless of the size of a file.  When extracting, if 
       the zip64 extended information extra field is present for 
       the file the compressed and uncompressed sizes will be 8
@@ -386,8 +428,8 @@
 
       4.3.9.3 Although not originally assigned a signature, the value 
       0x08074b50 has commonly been adopted as a signature value 
-      for the data descriptor record.  Implementers should be 
-      aware that ZIP files may be encountered with or without this 
+      for the data descriptor record.  Implementers SHOULD be 
+      aware that ZIP files MAY be encountered with or without this 
       signature marking data descriptors and SHOULD account for
       either case when reading ZIP files to ensure compatibility.
 
@@ -527,8 +569,8 @@
         zip64 extensible data sector    (variable size)
 
       4.3.14.1 The value stored into the "size of zip64 end of central
-      directory record" should be the size of the remaining
-      record and should not include the leading 12 bytes.
+      directory record" SHOULD be the size of the remaining
+      record and SHOULD NOT include the leading 12 bytes.
   
       Size = SizeOfFixedFields + SizeOfVariableData - 12.
 
@@ -549,7 +591,7 @@
       4.3.14.3 Special purpose data MAY reside in the zip64 extensible 
       data sector field following either a V1 or V2 version of this
       record.  To ensure identification of this special purpose data
-      it must include an identifying header block consisting of the
+      it MUST include an identifying header block consisting of the
       following:
 
          Header ID  -  2 bytes
@@ -605,13 +647,13 @@
       4.4.1.2  String fields are not null terminated, since the length 
       is given explicitly.
 
-      4.4.1.3  The entries in the central directory may not necessarily
+      4.4.1.3  The entries in the central directory MAY NOT necessarily
       be in the same order that files appear in the .ZIP file.
 
       4.4.1.4  If one of the fields in the end of central directory
-      record is too small to hold required data, the field should be 
+      record is too small to hold required data, the field SHOULD be 
       set to -1 (0xFFFF or 0xFFFFFFFF) and the ZIP64 format record 
-      should be created.
+      SHOULD be created.
 
       4.4.1.5  The end of central directory record and the Zip64 end 
       of central directory locator record MUST reside on the same 
@@ -690,7 +732,7 @@
 
         * Early 7.x (pre-7.2) versions of PKZIP incorrectly set the
         version needed to extract for BZIP2 compression to be 50
-        when it should have been 46.
+        when it SHOULD have been 46.
 
         ** Refer to the section on Strong Encryption Specification
         for additional information regarding RC2 corrections.
@@ -703,12 +745,12 @@
 
         + Files compressed using PPMd MUST set the version
         needed to extract field to 6.3, however, not all ZIP 
-        programs enforce this and may be unable to decompress 
+        programs enforce this and MAY be unable to decompress 
         data files compressed using PPMd if this value is set.
 
         When using ZIP64 extensions, the corresponding value in the
         zip64 end of central directory record MUST also be set.  
-        This field should be set appropriately to indicate whether 
+        This field SHOULD be set appropriately to indicate whether 
         Version 1 or Version 2 format is in use. 
 
 
@@ -795,7 +837,7 @@
                 PKWARE Proprietary Technology into Your Product" for 
                 more information.
 
-        Bit 14: Reserved by PKWARE.
+        Bit 14: Reserved by PKWARE for alternate streams.
 
         Bit 15: Reserved by PKWARE.
 
@@ -815,15 +857,23 @@
        11 - Reserved by PKWARE
        12 - File is compressed using BZIP2 algorithm
        13 - Reserved by PKWARE
-       14 - LZMA (EFS)
+       14 - LZMA
        15 - Reserved by PKWARE
-       16 - Reserved by PKWARE
+       16 - IBM z/OS CMPSC Compression
        17 - Reserved by PKWARE
        18 - File is compressed using IBM TERSE (new)
-       19 - IBM LZ77 z Architecture (PFS)
+       19 - IBM LZ77 z Architecture 
+       20 - deprecated (use method 93 for zstd)
+       93 - Zstandard (zstd) Compression 
+       94 - MP3 Compression 
+       95 - XZ Compression 
+       96 - JPEG variant
        97 - WavPack compressed data
        98 - PPMd version I, Rev 1
+       99 - AE-x encryption marker (see APPENDIX E)
 
+       4.4.5.1 Methods 1-6 are legacy algorithms and are no longer
+       recommended for use when compressing files.
 
    4.4.6 date and time fields: (2 bytes each)
 
@@ -832,7 +882,10 @@
        those at which compression was started for this data. 
        If encrypting the central directory and general purpose bit 
        flag 13 is set indicating masking, the value stored in the 
-       Local Header will be zero. 
+       Local Header will be zero. MS-DOS time format is different
+       from more commonly used computer time formats such as 
+       UTC. For example, MS-DOS uses year values relative to 1980
+       and 2 second precision.
 
    4.4.7 CRC-32: (4 bytes)
 
@@ -877,7 +930,7 @@
 
        The length of the file name, extra field, and comment
        fields respectively.  The combined length of any
-       directory record and these three fields should not
+       directory record and these three fields SHOULD NOT
        generally exceed 65,535 bytes.  If input came from standard
        input, the file name length is set to zero.  
 
@@ -918,7 +971,7 @@
    4.4.16 relative offset of local header: (4 bytes)
 
        This is the offset from the start of the first disk on
-       which this file appears, to where the local header should
+       which this file appears, to where the local header SHOULD
        be found.  If an archive is in ZIP64 format and the value
        in this field is 0xFFFFFFFF, the size will be in the 
        corresponding 8 byte zip64 extended information extra field.
@@ -926,7 +979,7 @@
    4.4.17 file name: (Variable)
 
        4.4.17.1 The name of the file, with optional relative path.
-       The path stored MUST not contain a drive or
+       The path stored MUST NOT contain a drive or
        device letter, or a leading slash.  All slashes
        MUST be forward slashes '/' as opposed to
        backwards slashes '\' for compatibility with Amiga
@@ -1009,7 +1062,7 @@
       The comment for this .ZIP file.  ZIP file comment data
       is stored unsecured.  No encryption or data authentication
       is applied to this area at this time.  Confidential information
-      should not be stored in this section.
+      SHOULD NOT be stored in this section.
 
    4.4.27 zip64 extensible data sector    (variable size)
 
@@ -1038,7 +1091,7 @@
 
        header1+data1 + header2+data2 . . .
 
-   Each header should consist of:
+   Each header MUST consist of:
 
        Header ID - 2 bytes
        Data Size - 2 bytes
@@ -1071,6 +1124,10 @@
       0x0017        Strong Encryption Header
       0x0018        Record Management Controls
       0x0019        PKCS#7 Encryption Recipient Certificate List
+      0x0020        Reserved for Timestamp record
+      0x0021        Policy Decryption Key Record
+      0x0022        Smartcrypt Key Provider Record
+      0x0023        Smartcrypt Policy Key Data Record
       0x0065        IBM S/390 (Z390), AS/400 (I400) attributes 
                     - uncompressed
       0x0066        Reserved for IBM S/390 (Z390), AS/400 (I400) 
@@ -1200,9 +1257,9 @@
 
           4.5.6.2. No word alignment or padding is performed.
 
-          4.5.6.3. A well-behaved PKZIP/OpenVMS program should never produce
-          more than one sub-block with the same TagX value.  Also, there will 
-          never be more than one "extra" block of type 0x000c in a particular 
+          4.5.6.3. A well-behaved PKZIP/OpenVMS program SHOULD NOT produce
+          more than one sub-block with the same TagX value.  Also, there MUST 
+          NOT be more than one "extra" block of type 0x000c in a particular 
           directory record.
 
    4.5.7 -UNIX Extra Field (0x000d):
@@ -1298,7 +1355,7 @@
    4.5.9 -PKCS#7 Store for X.509 Certificates (0x0014):
 
         This field MUST contain information about each of the certificates 
-        files may be signed with. When the Central Directory Encryption 
+        files MAY be signed with. When the Central Directory Encryption 
         feature is enabled for a ZIP file, this record will appear in 
         the Archive Extra Data Record, otherwise it will appear in the 
         first central directory record and will be ignored in any 
@@ -1387,7 +1444,7 @@
 
         This field MAY contain information about each of the certificates
         used in encryption processing and it can be used to identify who is
-        allowed to decrypt encrypted files.  This field should only appear 
+        allowed to decrypt encrypted files.  This field SHOULD only appear 
         in the archive extra data record. This field is not required and 
         serves only to aid archive modifications by preserving public 
         encryption key data. Individual security requirements may dictate 
@@ -1405,7 +1462,7 @@
 
          Value     Size     Description
          -----     ----     -----------
-         Version   2 bytes  Format version number - must 0x0001 at this time
+         Version   2 bytes  Format version number - MUST be 0x0001 at this time
          CStore    (var)    PKCS#7 data blob
 
          See the section describing the Strong Encryption Specification 
@@ -1418,8 +1475,7 @@
         The following is the layout of the MVS "extra" block.
         Note: Some fields are stored in Big Endian format.
         All text is in EBCDIC format unless otherwise specified.
-
-        Value     Size      Description
+Value     Size      Description
         -----     ----      -----------
 (MVS)   0x0065    2 bytes   Tag for this "extra" block type
         TSize     2 bytes   Size for the following data block
@@ -1442,6 +1498,57 @@
                              "T4MV" for TargetFour
         (var)     TSize-4    Attribute data (see APPENDIX A)
 
+   4.5.17 -Policy Decryption Key Record Extra Field (0x0021):
+
+        The following is the layout of the Policy Decryption Key "extra" block.
+        TData is a variable length, variable content field.  It holds
+        information about encryptions and/or encryption key sources.
+        Contact PKWARE for information on current TData structures.
+        Information in this "extra" block may aternatively be placed
+        within comment fields.  Refer to the section in this document 
+        entitled "Incorporating PKWARE Proprietary Technology into Your 
+        Product" for more information.
+
+        Value     Size       Description
+        -----     ----       -----------
+        0x0021    2 bytes    Tag for this "extra" block type
+        TSize     2 bytes    Size for the following data block
+        TData     TSize      Data about the key
+
+   4.5.18 -Key Provider Record Extra Field (0x0022):
+
+        The following is the layout of the Key Provider "extra" block.
+        TData is a variable length, variable content field.  It holds
+        information about encryptions and/or encryption key sources.
+        Contact PKWARE for information on current TData structures.
+        Information in this "extra" block may aternatively be placed
+        within comment fields.  Refer to the section in this document 
+        entitled "Incorporating PKWARE Proprietary Technology into Your 
+        Product" for more information.
+
+        Value     Size       Description
+        -----     ----       -----------
+        0x0022    2 bytes    Tag for this "extra" block type
+        TSize     2 bytes    Size for the following data block
+        TData     TSize      Data about the key
+
+   4.5.19 -Policy Key Data Record Record Extra Field (0x0023):
+
+        The following is the layout of the Policy Key Data "extra" block.
+        TData is a variable length, variable content field.  It holds
+        information about encryptions and/or encryption key sources.
+        Contact PKWARE for information on current TData structures.
+        Information in this "extra" block may aternatively be placed
+        within comment fields.  Refer to the section in this document 
+        entitled "Incorporating PKWARE Proprietary Technology into Your 
+        Product" for more information.
+
+        Value     Size       Description
+        -----     ----       -----------
+        0x0023    2 bytes    Tag for this "extra" block type
+        TSize     2 bytes    Size for the following data block
+        TData     TSize      Data about the key
+
 4.6 Third Party Mappings
 ------------------------
                  
@@ -1469,8 +1576,12 @@
           0x7075        Info-ZIP Unicode Path Extra Field
           0x756e        ASi UNIX
           0x7855        Info-ZIP UNIX (new)
+          0xa11e        Data Stream Alignment (Apache Commons-Compress)
           0xa220        Microsoft Open Packaging Growth Hint
           0xfd4a        SMS/QDOS
+          0x9901        AE-x encryption structure (see APPENDIX E)
+          0x9902        unknown
+
 
    Detailed descriptions of Extra Fields defined by third 
    party mappings will be documented as information on
@@ -1478,7 +1589,7 @@
    PKWARE does not guarantee the accuracy of any published
    third party data.
 
-   4.6.2 Third-party Extra Fields must include a Header ID using
+   4.6.2 Third-party Extra Fields MUST include a Header ID using
    the format defined in the section of this document 
    titled Extensible Data Fields (section 4.5).
 
@@ -1489,9 +1600,9 @@
 
    Note: As stated above, the size of the entire .ZIP file
          header, including the file name, comment, and extra
-         field should not exceed 64K in size.
+         field SHOULD NOT exceed 64K in size.
 
-   4.6.3 In case two different programs should appropriate the same
+   4.6.3 In case two different programs appropriate the same
    Header ID value, it is strongly recommended that each
    program SHOULD place a unique signature of at least two bytes in
    size (and preferably 4 bytes or bigger) at the start of
@@ -1506,8 +1617,8 @@
 
       The following is the layout of the ZipIt extra block 
       for Macintosh. The local-header and central-header versions 
-      are identical. This block must be present if the file is 
-      stored MacBinary-encoded and it should not be used if the file 
+      are identical. This block MUST be present if the file is 
+      stored MacBinary-encoded and it SHOULD NOT be used if the file 
       is not stored MacBinary-encoded.
 
           Value         Size        Description
@@ -1537,8 +1648,8 @@
          FileType      Byte[4]     four-byte Mac file type string
          Creator       Byte[4]     four-byte Mac creator string
          fdFlags       beShort     attributes from FInfo.frFlags,
-                                   may be omitted
-         0x0000        beShort     reserved, may be omitted
+                                   MAY be omitted
+         0x0000        beShort     reserved, MAY be omitted
 
 
    4.6.6 -ZipIt Macintosh Extra Field (short, for directories) (0x2805):
@@ -1554,9 +1665,9 @@
  (Mac2c) 0x2805        Short       tag for this extra block type
          TSize         Short       total data size for this block (12)
          "ZPIT"        beLong      extra-field signature
-         frFlags       beShort     attributes from DInfo.frFlags, may
+         frFlags       beShort     attributes from DInfo.frFlags, MAY
                                    be omitted
-         View          beShort     ZipIt view flag, may be omitted
+         View          beShort     ZipIt view flag, MAY be omitted
 
 
      The View field specifies ZipIt-internal settings as follows:
@@ -1616,7 +1727,7 @@
 
        Currently Version is set to the number 1.  If there is a need
        to change this field, the version will be incremented.  Changes
-       may not be backward compatible so this extra field should not be
+       MAY NOT be backward compatible so this extra field SHOULD NOT be
        used if the version is not recognized.
 
        The ComCRC32 is the standard zip CRC32 checksum of the File Comment
@@ -1624,8 +1735,8 @@
        the comment field has not changed since the Unicode Comment extra field
        was created.  This can happen if a utility changes the File Comment 
        field but does not update the UTF-8 Comment extra field.  If the CRC 
-       check fails, this Unicode Comment extra field should be ignored and 
-       the File Comment field in the header should be used instead.
+       check fails, this Unicode Comment extra field SHOULD be ignored and 
+       the File Comment field in the header SHOULD be used instead.
 
        The UnicodeCom field is the UTF-8 version of the File Comment field
        in the header.  As UnicodeCom is defined to be UTF-8, no UTF-8 byte
@@ -1635,8 +1746,8 @@
        Flag, bit 11 (Language encoding flag (EFS)), can be used to indicate
        both the header File Name and Comment fields are UTF-8 and, in this
        case, the Unicode Path and Unicode Comment extra fields are not
-       needed and should not be created.  Note that, for backward
-       compatibility, bit 11 should only be used if the native character set
+       needed and SHOULD NOT be created.  Note that, for backward
+       compatibility, bit 11 SHOULD only be used if the native character set
        of the paths and comments being zipped up are already in UTF-8. It is
        expected that the same file comment storage method, either general
        purpose bit 11 or extra fields, be used in both the Local and Central
@@ -1658,7 +1769,7 @@
 
       Currently Version is set to the number 1.  If there is a need
       to change this field, the version will be incremented.  Changes
-      may not be backward compatible so this extra field should not be
+      MAY NOT be backward compatible so this extra field SHOULD NOT be
       used if the version is not recognized.
 
       The NameCRC32 is the standard zip CRC32 checksum of the File Name
@@ -1666,8 +1777,8 @@
       File Name field has not changed since the Unicode Path extra field
       was created.  This can happen if a utility renames the File Name but
       does not update the UTF-8 path extra field.  If the CRC check fails,
-      this UTF-8 Path Extra Field should be ignored and the File Name field
-      in the header should be used instead.
+      this UTF-8 Path Extra Field SHOULD be ignored and the File Name field
+      in the header SHOULD be used instead.
 
       The UnicodeName is the UTF-8 version of the contents of the File Name
       field in the header.  As UnicodeName is defined to be UTF-8, no UTF-8
@@ -1677,8 +1788,8 @@
       Bit Flag, bit 11 (Language encoding flag (EFS)), can be used to
       indicate that both the header File Name and Comment fields are UTF-8
       and, in this case, the Unicode Path and Unicode Comment extra fields
-      are not needed and should not be created.  Note that, for backward
-      compatibility, bit 11 should only be used if the native character set
+      are not needed and SHOULD NOT be created.  Note that, for backward
+      compatibility, bit 11 SHOULD only be used if the native character set
       of the paths and comments being zipped up are already in UTF-8. It is
       expected that the same file name storage method, either general
       purpose bit 11 or extra fields, be used in both the Local and Central
@@ -1695,15 +1806,41 @@
           PadVal        Short       Initial padding value
           Padding       variable    filled with NULL characters
 
+    4.6.11 -Data Stream Alignment (Apache Commons-Compress) (0xa11e):
+
+       (per Zbynek Vyskovsky) Defines alignment of data stream of this 
+       entry within the zip archive.  Additionally, indicates whether the 
+       compression method should be kept when re-compressing the zip file.
+
+       The purpose of this extra field is to align specific resources to 
+       word or page boundaries so they can be easily mapped into memory.  
+
+         Value         Size        Description
+         -----         ----        -----------
+         0xa11e        Short       tag for this extra block type
+         TSize         Short       total data size for this block (2+padding)
+         alignment     Short       required alignment and indicator
+         0x00          Variable    padding
+
+       The alignment field (lower 15 bits) defines the minimal alignment 
+       required by the data stream.   Bit 15 of alignment field indicates 
+       whether the compression method of this entry can be changed when 
+       recompressing the zip file.  The value 0 means the compression method 
+       should not be chnged.  The value 1 indicates  the compression method 
+       may be changed. The padding field contains padding to ensure the correct 
+       alignment.  It can be changed at any time when the offset or required 
+       alignment changes. (see https://issues.apache.org/jira/browse/COMPRESS-391)
+
+
 4.7 Manifest Files
 ------------------
 
-    4.7.1 Applications using ZIP files may have a need for additional 
-    information that must be included with the files placed into
+    4.7.1 Applications using ZIP files MAY have a need for additional 
+    information that MUST be included with the files placed into
     a ZIP file. Application specific information that cannot be
     stored using the defined ZIP storage records SHOULD be stored 
     using the extensible Extra Field convention defined in this 
-    document.  However, some applications may use a manifest
+    document.  However, some applications MAY use a manifest
     file as a means for storing additional information.  One
     example is the META-INF/MANIFEST.MF file used in ZIP formatted
     files having the .JAR extension (JAR files).  
@@ -1713,9 +1850,9 @@
     file type required by the defining application process.  It is 
     placed within the same ZIP file as files to which this information 
     applies. By convention, this file is typically the first file placed
-    into the ZIP file and it may include a defined directory path.
+    into the ZIP file and it MAY include a defined directory path.
 
-    4.7.3 Manifest files may be compressed or encrypted as needed for
+    4.7.3 Manifest files MAY be compressed or encrypted as needed for
     application processing of the files inside the ZIP files.
 
     Manifest files are outside of the scope of this specification.
@@ -1737,18 +1874,18 @@
     not automatically increased when codes larger than the current
     code size are created (but not necessarily used).  When
     the decompressor encounters the code sequence 256
-    (decimal) followed by 1, it should increase the code size
+    (decimal) followed by 1, it SHOULD increase the code size
     read from the input stream to the next bit size.  No
     blocking of the codes is performed, so the next code at
-    the increased size should be read from the input stream
+    the increased size SHOULD be read from the input stream
     immediately after where the previous code at the smaller
-    bit size was read.  Again, the decompressor should not
+    bit size was read.  Again, the decompressor SHOULD NOT
     increase the code size used until the sequence 256,1 is
     encountered.
 
     5.1.3 When the table becomes full, total clearing is not
     performed.  Rather, when the compressor emits the code
-    sequence 256,2 (decimal), the decompressor should clear
+    sequence 256,2 (decimal), the decompressor SHOULD clear
     all leaf nodes from the Ziv-Lempel tree, and continue to
     use the current code size.  The nodes that are cleared
     from the Ziv-Lempel tree are then re-used, with the lowest
@@ -2089,9 +2226,9 @@
 
        16, 17, 18, 0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15
 
-    The Huffman codes should be built as described in the Implode algorithm
+    The Huffman codes SHOULD be built as described in the Implode algorithm
     except codes are assigned starting at the shortest bit length, i.e. the
-    shortest code should be all 0's rather than all 1's.  Also, codes with
+    shortest code SHOULD be all 0's rather than all 1's.  Also, codes with
     a bit length of zero do not participate in the tree construction.  The
     codes are then used to decode the bit lengths for the literal and 
     distance tables.
@@ -2199,7 +2336,7 @@
     Central Header records will be set to 6.3 to indicate the minimum 
     ZIP format version supporting this feature.
 
-    5.8.4 File data compressed using the LZMA algorithm must be placed 
+    5.8.4 File data compressed using the LZMA algorithm MUST be placed 
     immediately following the Local Header for the file.  If a standard 
     ZIP encryption header is required, it will follow the Local Header 
     and will precede the LZMA compressed file data segment.  The location 
@@ -2211,7 +2348,7 @@
         [data descriptor 1]
         [local header file 2]
 
-    5.8.5 The encryption header and data descriptor records may
+    5.8.5 The encryption header and data descriptor records MAY
     be conditionally present.  The LZMA Compressed Data Segment 
     will consist of an LZMA Properties Header followed by the 
     LZMA Compressed Data as shown:
@@ -2221,7 +2358,7 @@
 
     5.8.6 The LZMA Compressed Data will be stored as provided by the 
     LZMA compression library.  Compressed size, uncompressed size and 
-    other file characteristics about the file being compressed must be 
+    other file characteristics about the file being compressed MUST be 
     stored in standard ZIP storage format.
 
     5.8.7 The LZMA Properties Header will store specific data required 
@@ -2242,19 +2379,19 @@
        byte will store the minor number.  
 
        5.8.8.2 LZMA Properties Size - this field defines the size of the 
-       remaining property data.  Typically this size should be determined by 
+       remaining property data.  Typically this size SHOULD be determined by 
        the version of the SDK.  This size field is included as a convenience
-       and to help avoid any ambiguity should it arise in the future due
+       and to help avoid any ambiguity arising in the future due
        to changes in this compression algorithm. 
 
        5.8.8.3 LZMA Property Data - this variable sized field records the 
        required values for the decompressor as defined by the LZMA SDK.  
-       The data stored in this field should be obtained using the 
+       The data stored in this field SHOULD be obtained using the 
        WriteCoderProperties() in the version of the SDK defined by 
        the "LZMA Version Information" field.  
 
        5.8.8.4 The layout of the "LZMA Properties Data" field is a function of 
-       the LZMA compression algorithm.  It is possible that this layout may be
+       the LZMA compression algorithm.  It is possible that this layout MAY be
        changed by the author over time.  The data layout in version 4.3 of the 
        LZMA SDK defines a 5 byte array that uses 4 bytes to store the dictionary 
        size in little-endian order. This is preceded by a single packed byte as 
@@ -2267,11 +2404,11 @@
        Refer to the LZMA documentation for a more detailed explanation of 
        these fields.  
 
-    5.8.9 Data compressed with method 14, LZMA, may include an end-of-stream
+    5.8.9 Data compressed with method 14, LZMA, MAY include an end-of-stream
     (EOS) marker ending the compressed data stream.  This marker is not
     required, but its use is highly recommended to facilitate processing
-    and implementers should include the EOS marker whenever possible.
-    When the EOS marker is used, general purpose bit 1 must be set.  If
+    and implementers SHOULD include the EOS marker whenever possible.
+    When the EOS marker is used, general purpose bit 1 MUSY be set.  If
     general purpose bit 1 is not set, the EOS marker is not present.
 
 5.9 WavPack - Method 97
@@ -2294,13 +2431,13 @@
 
     5.9.3 An implementation note for storing digital sample data when using 
     WavPack compression within ZIP files is that all of the bytes of
-    the sample data should be compressed.  This includes any unused
+    the sample data SHOULD be compressed.  This includes any unused
     bits up to the byte boundary.  An example is a 2 byte sample that
     uses only 12 bits for the sample data with 4 unused bits.  If only
     12 bits are passed as the sample size to the WavPack routines, the 4 
     unused bits will be set to 0 on extraction regardless of their original 
     state.  To avoid this, the full 16 bits of the sample data size
-    should be provided. 
+    SHOULD be provided. 
 
 5.10 PPMd - Method 98
 ---------------------
@@ -2342,6 +2479,87 @@
             (Model restoration method << 12)
 
 
+5.11 AE-x Encryption marker - Method 99
+-------------------------------------------
+
+5.12 JPEG variant - Method 96
+-------------------------------------------
+
+5.13 PKWARE Data Compression Library Imploding -  Method 10
+-----------------------------------------------------------
+
+5.14 Reserved -  Method 11
+-------------------------------------------
+
+5.15 Reserved -  Method 13
+-------------------------------------------
+
+5.16 Reserved -  Method 15
+-------------------------------------------
+
+5.17 IBM z/OS CMPSC Compression - Method 16
+-------------------------------------------
+
+Method 16 utilizes the IBM hardware compression facility available
+on most IBM mainframes.  Hardware compression can significantly 
+increase the speed of data compression.  This method uses a variant 
+of the LZ78 algorithm.  CMPSC hardware compression is performed
+using the COMPRESSION CALL instruction.  
+
+ZIP archives can be created using this method only on mainframes
+supporting the CP instruction.  Extraction MAY occur on any
+platform supporting this compression algorithm.  Use of this 
+algorithm requires creation of a compression dictionary and
+an expansion dictionary.  The expansion dictionary MUST be
+placed into the ZIP archive for use on the system where
+extraction will occur.
+
+Additional information on this compression algorithm and dictionaries
+can be found in the IBM provided document titled IBM ESA/390 Data 
+Compression (SA22-7208-01). Storage requirements for using CMPSC 
+compression are as follows.
+
+The format for the compressed data stream placed into the ZIP
+archive following the Local Header is:
+
+    [dictionary header]
+    [expansion dictionary]
+    [CMPSC compressed data] 
+
+If encryption is used to encrypt a file compressed with CMPSC, these 
+sections MUST be encrypted as a single entity.
+
+The format of the dictionary header is:
+
+          Value            Size          Description
+          -----            ----          -----------
+          Version          1 byte        1
+          Flags/Symsize    1 byte        Processing flags and
+                                         symbol size
+          DictionaryLen    4 bytes       Length of the 
+                                         expansion dictionary
+
+Explanation of processing flags and symbol size:
+
+The high 4 bits are used to store the processing flags.  The low
+4 bits represent the size of a symbol, in bits (values range
+from 9-13).  Flag values are defined below.
+
+    0x80 - expansion dictionary
+    0x40 - expansion dictionary is compressed using Deflate
+    0x20 - Reserved
+    0x10 - Reserved
+
+
+5.18 Reserved -  Method 17
+-------------------------------------------
+
+5.19 IBM TERSE -  Method 18
+-------------------------------------------
+
+5.20 IBM LZ77 z Architecture -  Method 19
+-----------------------------------------
+
 6.0  Traditional PKWARE Encryption
 ----------------------------------
 
@@ -2360,7 +2578,7 @@
     encryption.
 
     6.1.2 PKZIP encrypts the compressed data stream.  Encrypted files 
-    must be decrypted before they can be extracted to their original
+    MUST be decrypted before they can be extracted to their original
     form.
 
     6.1.3 Each encrypted file has an extra 12 bytes stored at the start 
@@ -2427,7 +2645,7 @@
     end decrypt_byte
 
     After the header is decrypted,  the last 1 or 2 bytes in Buffer
-    should be the high-order word/byte of the CRC for the file being
+    SHOULD be the high-order word/byte of the CRC for the file being
     decrypted, stored in Intel low-byte/high-byte order.  Versions of
     PKZIP prior to 2.0 used a 2 byte CRC check; a 1 byte CRC check is
     used on versions after 2.0.  This can be used to test if the password
@@ -2517,10 +2735,10 @@
    7.1.7 Version 6.3 introduces support for encrypting data using the Blowfish
    and Twofish algorithms.  These are symmetric block ciphers developed 
    by Bruce Schneier.  Blowfish supports using a variable length key from 
-   32 to 448 bits.  Block size is 64 bits.  Implementations should use 16
+   32 to 448 bits.  Block size is 64 bits.  Implementations SHOULD use 16
    rounds and the only mode supported within ZIP files is CBC. Twofish 
    supports key sizes 128, 192 and 256 bits.  Block size is 128 bits.  
-   Implementations should use 16 rounds and the only mode supported within
+   Implementations SHOULD use 16 rounds and the only mode supported within
    ZIP files is CBC.  Information and source code for both Blowfish and 
    Twofish algorithms can be found on the internet.  Consult with the author
    of these algorithms for information on terms or restrictions on use.
@@ -2532,8 +2750,8 @@
    Central Directory structure cannot rely on the data in the corresponding 
    Local Header for decompression information.  
 
-   7.1.9 Extra Field records that may contain information about a file that should 
-   not be exposed should not be stored in the Local Header and should only 
+   7.1.9 Extra Field records that MAY contain information about a file that SHOULD 
+   not be exposed SHOULD NOT be stored in the Local Header and SHOULD only 
    be written to the Central Directory where they can be encrypted.  This 
    design currently does not support streaming.  Information in the End of 
    Central Directory record, the Zip64 End of Central Directory Locator, 
@@ -2544,11 +2762,11 @@
 
    7.1.10 Older ZIP compatible programs not familiar with the Central Directory 
    Encryption feature will no longer be able to recognize the Central 
-   Directory and may assume the ZIP file is corrupt.  Programs that 
+   Directory and MAY assume the ZIP file is corrupt.  Programs that 
    attempt streaming access using Local Headers will see invalid 
    information for each file.  Central Directory Encryption need not be 
    used for every ZIP file.  Its use is recommended for greater security.  
-   ZIP files not using Central Directory Encryption should operate as 
+   ZIP files not using Central Directory Encryption SHOULD operate as 
    in the past. 
 
    7.1.11 This strong encryption feature specification is intended to provide for 
@@ -2635,10 +2853,10 @@
                   VData     VSize-4  Password validation data
                   VCRC32    4 bytes  Standard ZIP CRC32 of password validation data
 
-       7.2.4.1 IVData - The size of the IV should match the algorithm block size.
+       7.2.4.1 IVData - The size of the IV SHOULD match the algorithm block size.
        The IVData can be completely random data.  If the size of
        the randomly generated data does not match the block size
-       it should be complemented with zero's or truncated as
+       it SHOULD be complemented with zero's or truncated as
        necessary.  If IVSize is 0,then IV = CRC32 + Uncompressed
        File Size (as a 64 bit little-endian, unsigned integer value).
 
@@ -2679,9 +2897,9 @@
         derive keys.  File session keys are derived from a master 
         session key generated from the user-supplied password.
         If the Flags field in the decryption header contains 
-        the value 0x4000, then the ErdData field must be 
+        the value 0x4000, then the ErdData field MUST be 
         decrypted using 3DES. If the value 0x4000 is not set,
-        then the ErdData field must be decrypted using AlgId.
+        then the ErdData field MUST be decrypted using AlgId.
 
 
         7.2.4.7 Reserved1 - Reserved for certificate processing, if value is
@@ -2699,7 +2917,7 @@
         VCRC32 data and will be greater than 4 bytes.
 
         7.2.4.10 VData - Random data for password validation.  This data is VSize
-        in length and VSize must be a multiple of the encryption
+        in length and VSize MUST be a multiple of the encryption
         block size.  VCRC32 is a checksum value of VData.  
         VData and VCRC32 are stored encrypted and start the
         stream of encrypted data for a file.
@@ -2714,7 +2932,7 @@
         account for a discrepancy found in the implementation of the RC2
         algorithm in the cryptographic library on Windows XP SP1 and all 
         earlier versions of Windows.  It is recommended that zero length files
-        not be encrypted, however programs should be prepared to extract them
+        not be encrypted, however programs SHOULD be prepared to extract them
         if they are found within a ZIP file.
 
         7.2.5.2 A pseudo-code representation of the encryption process is as follows:
@@ -2754,9 +2972,9 @@
     Masking replaces the true content of the fields for a file in the Local 
     Header with false information.  When masked, the Local Header is not 
     suitable for streaming access and the options for data recovery of damaged
-    archives is reduced.  Extra Data fields that may contain confidential
-    data should not be stored within the Local Header.  The value set into
-    the Version needed to extract field should be the correct value needed to
+    archives is reduced.  Extra Data fields that MAY contain confidential
+    data SHOULD NOT be stored within the Local Header.  The value set into
+    the Version needed to extract field SHOULD be the correct value needed to
     extract the file without regard to Central Directory Encryption. The fields 
     within the Local Header targeted for masking when the Central Directory is 
     encrypted are:
@@ -2777,12 +2995,12 @@
 
     The Base 16 value assigned as a masked file name is simply a sequentially
     incremented value for each file starting with 1 for the first file.  
-    Modifications to a ZIP file may cause different values to be stored for 
+    Modifications to a ZIP file MAY cause different values to be stored for 
     each file.  For compatibility, the file name field in the Local Header 
-    should never be left blank.  As of Version 6.2 of this specification, 
+    SHOULD NOT be left blank.  As of Version 6.2 of this specification, 
     the Compression Method and Compressed Size fields are not yet masked.
     Fields having a value of 0xFFFF or 0xFFFFFFFF for the ZIP64 format
-    should not be masked.  
+    SHOULD NOT be masked.  
 
     7.3.3 Encrypting the Central Directory
 
@@ -2792,7 +3010,7 @@
     of Central Directory record.  The ZIP file comment data is never
     encrypted.
 
-    Before encrypting the Central Directory, it may optionally be compressed.
+    Before encrypting the Central Directory, it MAY optionally be compressed.
     Compression is not required, but for storage efficiency it is assumed
     this structure will be compressed before encrypting.  Similarly, this 
     specification supports compressing the Central Directory without
@@ -2865,7 +3083,7 @@
              0x800E          SHA512
 
      7.3.5 When the Central Directory data is signed, the same hash algorithm
-     used to hash the Central Directory for signing should be used.
+     used to hash the Central Directory for signing SHOULD be used.
      This is recommended for processing efficiency, however, it is 
      permissible for any of the above algorithms to be used independent 
      of the signing process.
@@ -2873,7 +3091,7 @@
      The Hash Data will contain the hash data for the Central Directory.
      The length of this data will vary depending on the algorithm used.
 
-     The Version Needed to Extract should be set to 62.
+     The Version Needed to Extract SHOULD be set to 62.
 
      The value for the Total Number of Entries on the Current Disk will
      be 0.  These records will no longer support random access when
@@ -2905,11 +3123,11 @@
          0x0007 - reserved for future use
          0x000F - reserved for future use
          0x0100 - Indicates non-OAEP key wrapping was used.  If this
-                  this field is set, the version needed to extract must
+                  this field is set, the version needed to extract MUST
                   be at least 61.  This means OAEP key wrapping is not
                   used when generating a Master Session Key using
                   ErdData.
-         0x4000 - ErdData must be decrypted using 3DES-168, otherwise use the
+         0x4000 - ErdData MUST be decrypted using 3DES-168, otherwise use the
                   same algorithm used for encrypting the file contents.
          0x8000 - reserved for future use
 
@@ -3023,7 +3241,7 @@
     Decryption Header if the Central Directory is encrypted.
 
     7.5.2 The Archive Extra Data record will be used to store the following
-    information.  Additional data may be added in future versions.
+    information.  Additional data MAY be added in future versions.
 
     Extra Data Fields:
 
@@ -3034,8 +3252,8 @@
     The 0x0014 and 0x0016 Extra Data records that otherwise would be 
     located in the first record of the Central Directory for digital 
     certificate processing. When encrypting or compressing the Central 
-    Directory, the 0x0014 and 0x0016 records must be located in the 
-    Archive Extra Data record and they should not remain in the first 
+    Directory, the 0x0014 and 0x0016 records MUST be located in the 
+    Archive Extra Data record and they SHOULD NOT remain in the first 
     Central Directory record.  The Archive Extra Data record will also 
     be used to store the 0x0019 data. 
 
@@ -3082,12 +3300,23 @@
     certificate processing method set a value of 61 into the 
     version needed to extract field for a file.  This indicates that 
     non-OAEP key wrapping is used.  This affects certificate encryption 
-    only, and password encryption functions should not be affected by 
-    this value.  This means values of 61 may be found on files encrypted
+    only, and password encryption functions SHOULD NOT be affected by 
+    this value.  This means values of 61 MAY be found on files encrypted
     with certificates only, or on files encrypted with both password
     encryption and certificate encryption.  Files encrypted with both
     methods can safely be decrypted using the password methods documented.
 
+7.8 Additional Encryption/Decryption Data Records
+-----------------------------------------------------
+
+    7.8.1 Additional information MAY be stored within a ZIP file in support
+    of the strong password and certificate encryption methods defined above.
+    These include, but are not limited to the following record types.
+
+      0x0021        Policy Decryption Key Record
+      0x0022        Smartcrypt Key Provider Record
+      0x0023        Smartcrypt Policy Key Data Record
+
 8.0  Splitting and Spanning ZIP files
 -------------------------------------
 
@@ -3132,14 +3361,14 @@
 
       8.3.4 The .ZIP extension is used on the last segment to support
       quickly reading the central directory.  The segment number
-      n should be a decimal value.
+      n SHOULD be a decimal value.
         
     8.4  Spanned Self-extracting ZIP Files
         
-      8.4.1 Spanned ZIP files may be PKSFX Self-extracting ZIP files.
-      PKSFX files may also be split, however, in this case
-      the first segment must be named filename.exe.  The first
-      segment of a split PKSFX archive must be large enough to
+      8.4.1 Spanned ZIP files MAY be PKSFX Self-extracting ZIP files.
+      PKSFX files MAY also be split, however, in this case
+      the first segment MUST be named filename.exe.  The first
+      segment of a split PKSFX archive MUST be large enough to
       include the entire executable program.
 
     8.5  Capacities and Markers
@@ -3147,20 +3376,20 @@
       8.5.1 Capacities for split archives are as follows:
 
       Maximum number of segments = 4,294,967,295 - 1
-      Maximum .ZIP segment size = 4,294,967,295 bytes
+      Maximum .ZIP segment size = 4,294,967,295 bytes 
       Minimum segment size = 64K
       Maximum PKSFX segment size = 2,147,483,647 bytes
           
-      8.5.2 Segment sizes may be different however by convention, all 
-      segment sizes should be the same with the exception of the 
-      last, which may be smaller.  Local and central directory 
-      header records must never be split across a segment boundary. 
+      8.5.2 Segment sizes MAY be different however by convention, all 
+      segment sizes SHOULD be the same with the exception of the 
+      last, which MAY be smaller.  Local and central directory 
+      header records MUST NOT be split across a segment boundary. 
       When writing a header record, if the number of bytes remaining 
       within a segment is less than the size of the header record,
       end the current segment and write the header at the start
-      of the next segment.  The central directory may span segment
+      of the next segment.  The central directory MAY span segment
       boundaries, but no single record in the central directory
-      should be split across segments.
+      SHOULD be split across segments.
 
       8.5.3 Spanned/Split archives created using PKZIP for Windows
       (V2.50 or greater), PKZIP Command Line (V2.50 or greater),
@@ -3170,7 +3399,7 @@
       followed immediately by the local header signature for
       the first file in the archive.  
 
-      8.5.4 A special spanning marker may also appear in spanned/split 
+      8.5.4 A special spanning marker MAY also appear in spanned/split 
       archives if the spanning or splitting process starts but 
       only requires one segment.  In this case the 0x08074b50 
       signature will be replaced with the temporary spanning 
@@ -3189,7 +3418,7 @@
 ------------------
 
    9.1 In order for the .ZIP file format to remain a viable technology, this
-   specification should be considered as open for periodic review and
+   specification SHOULD be considered as open for periodic review and
    revision.  Although this format was originally designed with a 
    certain level of extensibility, not all changes in technology
    (present or future) were or will be necessarily considered in its
@@ -3204,7 +3433,7 @@
 
    9.3 Periodic revisions to this specification will be published as
    DRAFT or as FINAL status to ensure interoperability. We encourage 
-   comments and feedback that may help improve clarity or content.
+   comments and feedback that MAY help improve clarity or content.
 
 
 10.0 Incorporating PKWARE Proprietary Technology into Your Product
@@ -3216,7 +3445,7 @@
    PKWARE at zipformat@pkware.com or +1-414-289-9788 with regard to 
    acquiring such a license.
 
-   10.2 Additional information regarding PKWARE proprietray technology is 
+   10.2 Additional information regarding PKWARE proprietary technology is 
    available at http://www.pkware.com/appnote.
 
 11.0 Acknowledgements
@@ -3265,7 +3494,7 @@
 
 A.1 Field Definition Structure:
 
-   a. field length including length             2 bytes
+   a. field length including length             2 bytes Big Endian
    b. field code                                2 bytes
    c. data                                      x bytes
 
@@ -3280,7 +3509,7 @@
    4008     Database file and fields definition
    4009     GZIP file type                      2 bytes
    400B     IFS code page                       2 bytes
-   400C     IFS Creation Time                   4 bytes
+   400C     IFS Time of last file status change 4 bytes
    400D     IFS Access Time                     4 bytes
    400E     IFS Modification time               4 bytes
    005C     Length of the records in the file   2 bytes
@@ -3291,7 +3520,7 @@
 
 B.1 Field Definition Structure:
 
-   a. field length including length             2 bytes
+   a. field length including length             2 bytes Big Endian
    b. field code                                2 bytes
    c. data                                      x bytes
 
@@ -3404,6 +3633,22 @@
    0072     Archive device UNIT                 6 bytes  EBCDIC
    0073     Archive 1st Volume                  6 bytes  EBCDIC
    0074     Archive 1st VOL File Seq#           2 bytes  Binary
+   0075     Native I/O Flags                    2 bytes
+   0081     Unix File Type                      1 byte   enumerated
+   0082     Unix File Format                    1 byte   enumerated
+   0083     Unix File Character Set Tag Info    4 bytes
+   0090     ZIP Environmental Processing Info   4 bytes
+   0091     EAV EATTR Flags                     1 byte
+   0092     DSNTYPE Flags                       1 byte   
+   0093     Total Space Allocation (Cyls)       4 bytes  Big Endian
+   009D     NONVSAM DSORG                       2 bytes  
+   009E     Program Virtual Object Info         3 bytes  
+   009F     Encapsulated file Info              9 bytes
+   400C     Unix File Creation Time             4 bytes
+   400D     Unix File Access Time               4 bytes
+   400E     Unix File Modification time         4 bytes
+   4101     IBMCMPSC Compression Info           variable
+   4102     IBMCMPSC Compression Size           8 bytes  Big Endian
 
 APPENDIX C - Zip64 Extensible Data Sector Mappings 
 ---------------------------------------------------
@@ -3444,22 +3689,22 @@
 languages. To address this limitation, this specification will support the 
 following change. 
 
-D.2 If general purpose bit 11 is unset, the file name and comment should conform 
+D.2 If general purpose bit 11 is unset, the file name and comment SHOULD conform 
 to the original ZIP character encoding.  If general purpose bit 11 is set, the 
-filename and comment must support The Unicode Standard, Version 4.1.0 or 
+filename and comment MUST support The Unicode Standard, Version 4.1.0 or 
 greater using the character encoding form defined by the UTF-8 storage 
 specification.  The Unicode Standard is published by the The Unicode
 Consortium (www.unicode.org).  UTF-8 encoded data stored within ZIP files 
 is expected to not include a byte order mark (BOM). 
 
-D.3 Applications may choose to supplement this file name storage through the use 
+D.3 Applications MAY choose to supplement this file name storage through the use 
 of the 0x0008 Extra Field.  Storage for this optional field is currently 
 undefined, however it will be used to allow storing extended information 
-on source or target encoding that may further assist applications with file 
+on source or target encoding that MAY further assist applications with file 
 name, or file content encoding tasks.  Please contact PKWARE with any
-requirements on how this field should be used.
+requirements on how this field SHOULD be used.
 
-D.4 The 0x0008 Extra Field storage may be used with either setting for general 
+D.4 The 0x0008 Extra Field storage MAY be used with either setting for general 
 purpose bit 11.  Examples of the intended usage for this field is to store 
 whether "modified-UTF-8" (JAVA) is used, or UTF-8-MAC.  Similarly, other 
 commonly used character encoding (code page) designations can be indicated 
@@ -3471,7 +3716,7 @@
 
 D.5 General purpose bit 11 will not imply any encoding of file content or
 password.  Values defining character encoding for file content or 
-password must be stored within the 0x0008 Extended Language Encoding 
+password MUST be stored within the 0x0008 Extended Language Encoding 
 Extra Field.
 
 D.6 Ed Gordon of the Info-ZIP group has defined a pair of "extra field" records 
@@ -3487,11 +3732,42 @@
 Extra Field) and 0x7075 (Info-ZIP Unicode Path Extra Field).
 
 D.8 The choice of which storage method to use when writing a ZIP file is left
-to the implementation.  Developers should expect that a ZIP file may 
-contain either method and should provide support for reading data in 
+to the implementation.  Developers SHOULD expect that a ZIP file MAY 
+contain either method and SHOULD provide support for reading data in 
 either format. Use of general purpose bit 11 reduces storage requirements 
 for file name data by not requiring additional "extra field" data for
 each file, but can result in older ZIP programs not being able to extract 
 files.  Use of the 0x6375 and 0x7075 records will result in a ZIP file 
-that should always be readable by older ZIP programs, but requires more 
+that SHOULD always be readable by older ZIP programs, but requires more 
 storage per file to write file name and/or file comment fields.
+
+APPENDIX E - AE-x encryption marker
+-----------------------------------
+
+E.1 AE-x defines an alternate password-based encryption method used 
+in ZIP files that is based on a file encryption utility developed by 
+Dr. Brian Gladman.  Information on Dr. Gladman's method is available at 
+
+   http://www.gladman.me.uk/cryptography_technology/fileencrypt/
+
+E.2 AE-x uses AES with CTR (counter mode) and HMAC-SHA1.  It defines
+encryption using key sizes of 128 bits or 256 bits.  It does not 
+restrict support for decrypting 192 bits.
+
+E.3 This method uses the standard ZIP encryption bit (bit 0) 
+of the general purpose bit flag (section 4.4.4) to indicate a
+file is encrypted.  
+
+E.4 The compression method field (section 4.4.5) is set to 99 
+to indicate a file has been encrypted using this method.
+
+E.5 The actual compression method is stored in an extra field
+structure identified by a Header ID of 0x9901. Information on this
+record structure can be found at http://www.winzip.com/aes_info.htm.
+
+E.6 Two versions are defined for the 0x9901 structure.  
+
+   E.6.1 Version 1 stores the file CRC value in the CRC-32 field
+   (section 4.4.7). 
+
+   E.6.2 Version 2 stores a value of 0 in the CRC-32 field.
diff --git a/lib/zip_algorithm_zstd.c b/lib/zip_algorithm_zstd.c
index 1bd25d4..0c7712e 100644
--- a/lib/zip_algorithm_zstd.c
+++ b/lib/zip_algorithm_zstd.c
@@ -197,7 +197,7 @@
     compress_allocate,
     deallocate,
     general_purpose_bit_flags,
-    63,
+    20,
     start,
     end,
     input,
@@ -210,7 +210,7 @@
     decompress_allocate,
     deallocate,
     general_purpose_bit_flags,
-    63,
+    20,
     start,
     end,
     input,