RE: Suspected SPAM - RE: [tosca] TOSCA v2.0 zip file compression methods

["Nguyenphu, Thinh (Nokia - US/Dallas)" <thinh.nguyenphu@nokia.com>]

Hi,

I have incorporated Tal comment into the proposed text below.  Also, I am requesting this topic to be discuss and decision on upcoming Tuesday, June 23.  The urgency is critical because ETSI NFV SOL004 and SOL007 are scheduled for WG approval next week.  My goal is to ensure TOSCA and ETSI NFV SOL004/007 are using same reference (container and compression requirement).

 

The reference [x] defines container format and compression too.

Change #1:

1      TOSCA Cloud Service Archive (CSAR) format

This section defines the metadata of a cloud service archive as well as its overall structure. Except for the examples, this section is normative.

1.1 Overall Structure of a CSAR

A CSAR is a zip file where TOSCA definitions along with all accompanying artifacts (e.g. scripts, binaries, configuration files) can be packaged together. The zip file format shall conform to Document Container Format File [x].  A CSAR zip file MUST contain one of the following:

         A TOSCA.meta metadata file that provides entry information for a TOSCA orchestrator processing the CSAR file. The TOSCA.meta file may be located either at the root of the archive or inside a TOSCA-Metadata directory (the directory being at the root of the archive). The CSAR may contain only one TOSCA.meta file.

         a yaml (.yml or .yaml) file at the root of the archive, the yaml file being a valid tosca definition template.

The CSAR file MAY contain other directories and files with arbitrary names and contents.

1.2 TOSCA Meta File

â.

Change #2:

1.3 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.4 Normative References

[RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC8174]         Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.

[YAML-1.2]        YAML, Version 1.2, 3rd Edition, Patched at 2009-10-01, Oren Ben-Kiki, Clark Evans, Ingy dÃt Net http://www.yaml.org/spec/1.2/spec.html

[YAML-TS-1.1]   Timestamp Language-Independent Type for YAML Version 1.1, Working Draft 2005-01-18, http://yaml.org/type/timestamp.html

[x]       ISO/IEC 21320-1 "Document Container File â Part 1: Core", https://www.iso.org/standard/60101.html 

 

Regards,

Thinh

 

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Nguyenphu, Thinh (Nokia - US/Dallas)
Sent: Tuesday, June 16, 2020 11:46 AM
To: Tal Liron <tliron@redhat.com>
Cc: tosca@lists.oasis-open.org
Subject: Suspected SPAM - RE: [tosca] TOSCA v2.0 zip file compression methods

 

Hi Tal,

Do you have access to the ISO spec? Thinh

 

From: Tal Liron <tliron@redhat.com>
Sent: Tuesday, June 16, 2020 11:13 AM
To: Nguyenphu, Thinh (Nokia - US/Dallas) <thinh.nguyenphu@nokia.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] TOSCA v2.0 zip file compression methods

 

Thanks, Thinh!

 

I think it may also be a good idea to refer to the zip container format standard, not just compression:

ISO/IEC 21320-1 "Document Container File â Part 1: Core"
https://www.iso.org/standard/60101.html

 

 

On Tue, Jun 16, 2020 at 10:43 AM Nguyenphu, Thinh (Nokia - US/Dallas) <thinh.nguyenphu@nokia.com> wrote:

Hi,

 

Last week call, I volunteered to prepare additional clarification text on CSAR zip file compression method to be use with CSAR.

 

I reviewed multiple source of references. It seems that the  common denominator is uncompressed and DEFLATE compression methods.  So, I propose TOSCA v2.0 to use same approach, see my recommendation change text (in yellow highlighted text). If possible, I would like these change to apply to next draft release, as soon as possible.

 

Other source of references:

• Wiki: https://en.wikipedia.org/wiki/Zip_(file_format)#Standardization
• EPUB: http://idpf.org/epub/30/spec/epub30-ocf.html#sec-zip-container-zipreqs
• OASIS ODF: https://docs.oasis-open.org/office/OpenDocument/v1.3/cs01/part2-packages/OpenDocument-v1.3-cs01-part2-packages.html#__RefHeading__752789_826425813
• Java: https://docs.oracle.com/javase/7/docs/api/java/util/zip/package-summary.html#package_description

 

Change #1:

1      TOSCA Cloud Service Archive (CSAR) format

This section defines the metadata of a cloud service archive as well as its overall structure. Except for the examples, this section is normative.

1.1 Overall Structure of a CSAR

A CSAR is a zip file where TOSCA definitions along with all accompanying artifacts (e.g. scripts, binaries, configuration files) can be packaged together. The files in the zip file MUST be stored either uncompressed, or using the âDEFLATEâ compression method specified in [RFC1951].  A CSAR zip file MUST contain one of the following:

         A TOSCA.meta metadata file that provides entry information for a TOSCA orchestrator processing the CSAR file. The TOSCA.meta file may be located either at the root of the archive or inside a TOSCA-Metadata directory (the directory being at the root of the archive). The CSAR may contain only one TOSCA.meta file.

         a yaml (.yml or .yaml) file at the root of the archive, the yaml file being a valid tosca definition template.

The CSAR file MAY contain other directories and files with arbitrary names and contents.

1.2 TOSCA Meta File

â.

 

Change #2:

1.3 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.4 Normative References

[RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC8174]         Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.

[YAML-1.2]        YAML, Version 1.2, 3rd Edition, Patched at 2009-10-01, Oren Ben-Kiki, Clark Evans, Ingy dÃt Net http://www.yaml.org/spec/1.2/spec.html

[YAML-TS-1.1]   Timestamp Language-Independent Type for YAML Version 1.1, Working Draft 2005-01-18, http://yaml.org/type/timestamp.html

[RFC1951]         DEFLATE Compressed Data Format Specification version 1.3. P. Deutsch. May 1996, https://tools.ietf.org/html/rfc1951

 

Regards,

Thinh

 

Thinh Nguyenphu

Bell Labs CTO

Nokia

thinh.nguyenphu@nokia.com

+1 817-313-5189