Section 17.3.1 of CORBA 3.1 / 3.2 says:

17.3.1 Structures

PolicyValue

This structure contains the value corresponding to a Policy of the
PolicyType indicated by its ptype. This representation allows the
compact transmission of QoS policies within IORs and Service
Contexts. **The format of pvalue for each type is given in the
specification of that Policy.**

When the ZIOP 1.0 specification describes the ZIOP policies, it does not
give the format for pvalue.

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

In the ZIOP 1.0 specification, Annex A has:

Compressor get_compressor(
in CompressorId compressor_id,
in CompressorLevel compression_level)
raises (UnknownCompressorId);

CompressorLevel should be CompressionLevel.

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

In the ZIOP 1.0 specification, the IDL in Annex A has:

typedef unsigned short CompressorId { };

The braces are invalid and should be removed.

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

The ZIOP body format contains the original length of the compressed
data, which is important because it allows the compressor to efficiently
allocate a buffer to uncompress it. Unfortunately, the
Compressor::decompress() operation is not given that size, meaning that
it has to guess how big the uncompressed data will be.

The original data size should be given to the decompress() operation.
One way to do that without changing the operation signature would be to
specify that the inout Buffer target sequence should have its length
pre-populated to the expected size.

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

The LwCCM removes the usage of cidl from CCM, but this looses also the fixed name of the base class of the executor. The spec should define how the base class of an executor is generated by the framework, so that the implementor of the executor can write a portable executor

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

The IDL file 07-02-01 related to CCM we have the following exceptions

exception LastConfiguration {
};

exception InvalidReference {
};

LastCOnfiguration is not listed at all in 06-04-01 and 06-04-02

InvalidReference is listed in 06-04-02 in text and diagrams, but not in idl at all

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

The CCM spec describes the event mechanism default part of CCM. We want to propose to change this event machine to a connector based model as part of the DDS4CCM specification. Then there would be an event connector and the container then is much more light weight and easier to use. People that don't want to use CORBA event machinisms don't pull in all the dependent code

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

In section 10.3.1.2 the typedef CCMObjectSeq is listed, we propose to move it to Section 6.11.1 just after the definition of CCMObject

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

The spec mentions InvalidConfiguration as exception but there is no idl in this spec that describes this exception and its members

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

The IDL file 07-02-01 related to CCM is lacking ResourceCommitmentManager

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

In chapter 6.6.8, sub paragraph "connect_consumer" the following statement is given:

The cookie return value can be used to disconnect from the source.

I think that this sentence should be removed from the specification since connect_consumer is declared as follows:

void connect_consumer (
in FeatureName emitter_name,
in EventConsumerBase consumer)
raises (InvalidName, AlreadyConnected,
InvalidConnection);

Also, disconnect_consumer doesn't provide a cookie as input parameter.

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

HomeConfiguration::set_configuration_values documentation should mention which exception to thrown when an any/name value pair has a not supported name or when the any can't be extracted

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

The ZIOP specification is an addition to CORBA and should be merged into the main CORBA specification instead of being a stand alone specification

Move the ZIOP Compression module to CORBA Part 1, section 18
Move the ZIOP Module to CORBA Part 2, section 12

Summary:
Location:
1 Scope
Comment:
There are many references to PIM/PSM. However, those definitions aren't prescribed.
Proposed change:
Add reference to MDA prescription. http://www.omg.org/docs/omg/03-06-1/pdf

Agreed to add refernce to MDA Guide version 1.0.1, and to use it in abbreviation
definitions for PIM and PSM

Summary:
Location:
1 Scope
Comment:
There is a reference to EJB. This should be referred as normative reference. Furthermore, this refers to private web page (http://java.sun.com/products/ejb/javadocs-1.1-fr).
Proposed change:
This reference should move to clause "Normative Reference" and refer to public specification, such as JCP. Furthermore, referred version number should be designated.

Agree that the reference should be changed to use the JCP url for JSR 950 - EJB 1.1 spec
final release with errata

Summary:
Location:
Introduction 3rd paragraph
Comment:
Since this document is submitted as PAS, it is better to reference ISO/IEC standard in addition to OMG standard.
Proposed change:
Add " or this standard (ISO/IEC 19500)" at the end of the first sentence..

Agree to clarify the references

Summary:
Location:
Introduction 3rd paragraph
Comment:
1) The second "Part2" seems to be "Part3" instead.
2) Mixed use of "RM-ODP" and "RM ODP" is confusing.
Proposed change:
1) The second "Part2" should be replaced with "Part3".
2) "RM ODP" should be replaced with "RM-ODP" where applicable..

Accept proposed change.

Summary:
Location:
Foreword 6th paragraph
Comment
1) The year of the standard's issuance need to be corrected.
2) The names in the second half of two referenced standards start with "-" and need to be removed.
Proposed change:
1) The year within the title of RM-ODP Part2 and 3 should be replaced with 1996, like following.
ITU-T Recommendation X.902(1995)|ISO/IEC 10746-2:1996
ITU-T Recommendation X.903(1995)|ISO/IEC 10746-3:1996

accept proposed change

Summary:
Location:
3.1 Normative Reference
Comment:
ZIP is referred to http://www.pkware.com/products/enterprise/white_paper/annnote.txt
Proposed change:
Refer to public document. Otherwise ZIP should be removed.

According to section 6.12.1 (note on Tools), the exact nature of a zip file format is tool
and platform dependent.
Thus the single reference in 14.3.3 should be made informal, and the reference [ZIP]
needs to be removed.

Summary:
Location:
3.1 Normative Reference
Comment:
There are reference to UML 1.5, MOF 1.4 and XMI.
Proposed change:
ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
ISO/IEC 19501:2005 Information technology - Unified Modeling Language (UML)
ISO/IEC 19503:2005 Information technology – XML Metadata Interchange (XMI)

Agreed to add the three references

Summary:
Location:
All Clauses
Comment:
ISO standard documents are described with "shall", "should" and "may".
Proposed Change
Define this with "shall", "should" and "may"

No Data Available

Summary:
Location:
Annex B,C
Comment:
This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as OMG document only.
Proposed Change
Remove Annex D and C from ISO standard.

Agree to remove Annex B and Annex C from both the ISO Standard and the OMG specification (for
consistency)

Summary:
Location:
8.2.6, 8.2.7 Figure 8.1, Figure 8.2
Comment:
Syntax for the composition structure diagram is ambiguous. For example, there are gray dashed arrows, however, the legends only show gray solid arrow.
Proposed change:
The Fig 8.1 and 8.2 should be represented using the symbol of the legend."

The light grey dashed arrows are a fourth type, and are used to represent correspondence
form the composition example to one of the diagram elements.

Summary:
Location:
6.11 Figure 6.2
Comment:
The diagram looks like class diagram. However, its syntax is ambiguous. For example, Inheritance arrowhead is solid black triangle. Generally, Inheritance arrowhead is hollow triangle. Besides, there are dashed lines without definition.
Proposed change:
Replace the diagram with class diagram.

Accommodated by deletion of the Figure, since it is not referred to in the text of the
document

Summary:
Location:
Introduction Last paragraph
Comment:
There is no sentence included with respect to annexes of this standard.
Proposed change:
Add text that says this standard includes normative and non-normative annexes.

Agree to add proposed sentence, however Annex B and C are to be removed, and the Annex A is non
-normative

Summary:
Location:
Introduction Structure of this standard
Comment:
1) This chapter numbers in Structure of this standard are not consistent with actual chapter numbers.
Proposed change:
1) Revise the chapter numbers..

Accommodate by deletion of “Structure of this Standard” unnumbered subsection. This
subsection is not required.

Summary:
Location:
Annex A
Comment:
This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition.
Proposed Change
Remove Annex a or make it informative Annex

Agree to make Annex A an informative Annex

Summary:
Location:
8.2.9.1 Code fragment
Comment:
It is unclear if this description is normative or informative.
Proposed change:
Make distinction between normative and informative.

Agree to clarify that this code fragment is a normative implicit definition

Summary:
Location:
7.6.6.3 p.31, p.32
Comment:
There are sentences each of which begins with "See …".
However, the reference pointers are ambiguous for those who are not familiar with the CORBA work.
Proposed change:
Replace the references as mentioned above.

Agree to change to proper OMG normative references, and to add to normative
references clause. OMG is an Authorized Reference Originator
Replace all the numbered reference text to Firewall spec , showing in the document as
“(ptc/04-03-01)” with the “[FIREWALL]” reference tag.

Summary:
Location:
7.6.6 p.30
Comment:
We can't find where the DCE ESIOP is. There is no clause which names DCE ESIOP in ISO/IEC 19500-2.
What document are CORBA services included in?
Proposed change:
Modify the sentence

Agree to fix by removing deprecated references to DCE ESIOP components

Location:
7.6.4.4 p.29
Comment:
The reference pointer of the "Unreliable Multicast" is necessary for the convenience of the readers.
Proposed change:
Replace the "Unreliable Multicast" with "in clause 11 of ISO/IEC 19500-2, Unreliable Multicast"..

Agree to add reference to clause 11:

Summary:
Location:
Foreword 5th paragraph
Comment:
1) The reference to JTC1 is not correct.
2) The JTC1 subcommittee referenced in this standard is SC32. It seems there is no reference to the reference.
Proposed change:
1)"ISO/IEC/TC JTC1" should be replaced with "ISO/IEC JTC1"
2) Remove reference to SC32.

Accept proposed change

Source: Japan NB, Severity te
Summary:
Japan will approve this DIS if the te comment jp 8, 11, 14 will be satisfactorily resolved
Resolution:
If the te comments JP 8, 11, 14 were accepted in the approved resolutions. See resolutions to OMG Issues

All of the comments JP 8, 11, and 14, were resolved in the approved resolutions. See
resolutions to OMG Issues

Summary:
Location:
All Clauses
Comment:
ISO standard documents are described with "shall", "should" and "may".
Proposed Change
Define this with "shall", "should" and "may"

Specification uses RFC 2119 Terminology

Summary:
Location:
Annex C, D
Comment:
This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as OMG document only.
Proposed Change
Remove Annex C and D from ISO standard.

Agree to remove Annex C and Annex D from both the ISO Standard and the OMG specification (for
consistency)

Summary:
Location:
Annex B
Comment:
This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition.
Proposed Change
Remove Annex B or make it informative Annex

Agree to make Annex B an informative Annex

Summary:
Location:
Introduction p.xviii (Last paragraph)
Comment:
There is no sentence included with respect to annexes of this standard.
Proposed change:
Add a sentence which says that this standard includes normative and non-normative annexes.

Agree to add proposed sentence

Location:
3.1 p 2
Forward p xv
Comment:
The year of ITU-T recommendation is different from that of ISO/IEC. The former is 1995, and the latter is 1996.
Proposed change:
The correct expressions of the Normative references are as follows:
ITU-T Recommendation X.902 (1995)| ISO/IEC 10746-2:1996,
ITU-T Recommendation X.903 (1995)| ISO/IEC 10746-3:1996,

Agree to proposed change

Location:
7.6.4.3 p 28
Comment:
There is a phrase that "see the CORBA/TC Interworking specification". However, we can't find the place.
Proposed change:
Where is this clause ?.

Agree to add proper reference to OMG spec

Summary:
Location:
7.6.3 p.27, l.24
7.6.9 p.33
Comment:
We use the term 'clause' when we need to point to the other sections.
Proposed change:
Replace "see Section 9.7.3" with "see clause 9.7.3".
Replace "see Section 9.3" with "see clause 9.3".

agree to proposed change

Summary:
Location:
6.3.4
Comment:
When referring to clause(s) in other parts of ISO/IEC 19500 from within ISO/IEC 19500-2, it is clearer to explicitly provide the clause number and part number of the standard, rather stating like "this standard(Part 1).
Proposed change:
Replace "in the Interface Repository clause of this standard (Part1)" with "in clause 14 of ISO/IEC 19500-1, Interface Repository clause of CORBA interfaces"..

Agree to refer to clause in 19500-1 as “Part 1 of this Specification” which will hold for both OMG and ISO
versions of text.

Summary:
Location:
4.2
In 'repository', the sentence tells to 'see' the other terms. However, there is no 'implementation repository' in the definitions list.
Proposed change:
Modify the definition of this 'repository' or add the reference to the definition of 'implementation repository', which is mentioned in the clause 6.1.4 of ISO/IEC 19500-1.

Agree that there is no specialized definition of the word repository as used in this spec

Location:
4.1
Comment:
As the terms 'transparency', 'domain' and 'service' are used in clause 7, and these terms are important for the concept of interoperability, it is preferable to explain the difference or resemblance of usage between the RM-ODP and this CORBA in the document. One way to do this is to define the meaning of the terms. The term 'domain' is defined in clause 4.2. However, other terms are not defined in this document. Where are the definitions of 'transparency' and 'service' ?
Proposed change:
If the terms are already defined in the other documents, make a reference to the documents in which the terms are defined. Otherwise, define these terms in this document..

Add “transparency” and “service” to the list of terms defined in ODP Reference Model 10746-2

Summary:
Location:
6.2
Comment:
ISO documents are not a book but consist of several parts of documents.
Proposed change:
Correct the expression of the phrase "ORB Interface clause of this book(Part1)" , such as "clause 8 of ISO/IEC 19500-1, ORB Interface"..

Agree to change reference to a neutral designation for 19500-1 as “Part 1 of this Specification” which will
hold for both OMG and ISO versions of text. Use of clause names in other spec references rather than
clause numbers is more robust to amendments/corrigenda on the references external specification.

Summary:
Location:
Clause 5
Comment:
The term ESIOP plays important roles in the document.
Proposed change:
ESIOP should be added in the symbols.

Agree to add ESIOP to symbols

Summary:
Location:
4.2
Comment:
It seems that the definition of a 'request' is circular.
Proposed change:
Modify the definition which is not circular. A candidate is " A message issued by a client to cause a service to be performed."..

Agree to proposed change of definition text

Location:
4.2
Comment:
There are misspellings in the definitions list.
Proposed change:
Correct the word 'wiat' to 'wait' in the definition of the "synchronous request".
Correct the word 'tow' to 'two' in the definition of the 'interoperability'..

agree to proposed changes

Comment:
This document is revision for 19500-2:2003. Therefore, status of the old document is ambiguous.
Proposed Change
It is desirable to withdraw the old standard (19500-2:2003) to avoid confusion, if possible.

Clarify upon publication by ISO that This PAS specification is intended to supersede the
2003 version

Summary:
Japan will approve this DIS if the te comment jp 20 will be satisfactorily resolved
Resolution:
If the te commentsJP17 were accepted in the approved resolutions. See resolutions to OMG Issues

The comment JP20 was resolved in the approved resolutions. See resolutions to OMG
Issues

Location:
4.1 1st line
Comment:
The delimiter between X and 902 is not a comma but a dot, and the part number following a document number should be connected by a hyphen.
Proposed change:
X,902 should be X.902 and 10746.2 should be 10746-2..

agree to proposed change

Summary:
Location:
Clause 2 2nd paragraph
Comment:
What does ESIOP mean? There are no descriptions on it.
Proposed Change:
Change 'additional ESIOPs' to 'additional Environment-Specific Inter-ORB Protocols(ESIOPs)'

Agree to proposed change

Location:
All Clauses
Comment:
1) Both terms, "OMG IDL" and "IDL," are used in the document, and this usage is not consistent.
Proposed Change
1) It is suggested to use "OMG IDL" for the first appearance, and with the text explaining that IDL hereafter means OMG IDL, use just IDL for the rest of the document.

Agree to proposed change

Location:
Clause 5
Comment:
1) OMA is mentioned but no reference to OMA document is included.
Proposed Change
Add the reference to Object Management Architecture Guide

Agree to add reference to OMG OMA Guide

Summary:
Location:
Annex B
Comment:
This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition.
Proposed Change
Remove Annex B or make it informative Annex
Resolution:

Agree to make Annex B an informative Annex

Summary:
Location:
Clause 8.5.2 and other places Table 8.1
Comment:
1) There are places where the reference to Part 2 is describe like the following:
"See CORBA, Part 2: ORB Interoperability Architecture clause".
Proposed Change
Change the text of referring to other part of the standard throughout the document to:
"See ISO/IEC 19500-2 Common Object Request Broker Architecture (CORBA) specification - Part 2: Interoperability"
or
"See ISO/IEC 19500-2 CORBA specification Part 2: Interoperability"
or
"See Part 2 of this standard"

Agree to second proposed change

Summary:
Location:
Clause 7.3 1st paragraph
Comment:
1) There is a stand-alone term "1998" in the second line of this paragraph.
Proposed Change
1) Change the standard name to "ISO/IEC 14882:2003" or "ISO/IEC 14882:1998" or remove this number from the text.

Agree to proposed change to incorporate reference from normative references

Summary:
Location:
All Clauses
Comment:
ISO standard documents are described with "shall", "should" and "may".
Proposed Change
Define this with "shall", "should" and "may"

Change the title of clause 4 to the following:
“
4 Additional information
“
Add a new sub section header at beginning of clause 4:
“
4.1 Outline of specification contents
“
Add new subsection to end of section 4:
“
4.2 Keywords for Requirement statements”
The keywords "must", "must not", "shall", "shall not", "should", "should not", and "may” in this
specification are to be interpreted as described in [RFC 2119].“
“
Add the following reference in the normative references - section 3.2:
[RFC2119] IETF RFC2119, “Key words for use in RFCs to Indicate Requirement Levels”, S. Bradner,
March 1997. Available from http://ietf.org/rfc/rfc2119

Summary:
Location:
Annex C, D
Comment:
This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as OMG document only.
Proposed Change
Remove Annex C and D from ISO standard.

Agree to remove Annex C and Annex D from both the ISO Standard and the OMG specification (for
consistency)

Location:
Clause 4
Comment:
1) There seems to be duplication between "structure of this standard" section of Introduction and clause 4, and therefore it is better to make text simpler.
Proposed Change
1) Structure of this standard section of Introduction and clause 4 should be merged and placed in one place.

Accommodated by removal of Structure of Standard subsection from Issue 14369.

Summary:
Location:
Clause 3 Bullet items
Comment:
1) The year of the standard's issuance need to be corrected.
Proposed Change
1) The years within the title of RM-ODP Part 2 and 3 should be replaced with 1996, like the following.
o ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1996
o ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1996

Accept proposed change

Location:
Clause 2
Comment:
1) It would be better to have reference to programming language C++ standard, since it is used in mapping examples.
2) It would be better to have reference to programming language C standard too.
Proposed Change
1) Add the reference to C++, which is ISO/IEC 14882:2003, somewhere in the document.
See also a comment on Clause 7.3.
2) Add the reference to C, which is ISO/IEC 9899:1999, somewhere in the document.

Agree to proposed change

Introduction last paragraph
Comment:
1) There is no sentence included with respect to annexes of this standard.
Proposed Change
1) Add text that says this standard includes normative and non-normative annexes.
Resolution:

Agree to add proposed sentence, however Annex B and C are to be removed, and the Annex A is non
-normative

Summary:
Location:
Forword 6th paragraph
Comment:
1) The year of the standard's issurance need to be corrected.
2) The names in the second half of four referenced standards start with "-" and need to be removed.
3) ISO/IEC 19500-3 needs to be added in the list of relevant standards.
Proposed Change
1) The years within the title of RM-ODP Part 2 and 3 should be replaced with 1996, like the following.
o ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1996
o ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1996
2) Starting "-"s need to be removed.
3) Add the following to the list of related standards.
ISO/IEC 19500-3, Information Technology - Open Distributed Processing - CORBA Specification Part 3: CORBA Components

Accept proposed change

Source: Japan NB, Severity ed
Summary:
Location:
Forword 5th paragraph
Comment:
1) The reference to JTC1 is not correct.
2) The JTC1 Subcommittee referenced in this standard should be SC7 instead of SC32.
Proposed Change
1) "ISO/IEC/TC JTC1" should be replaced with "ISO/IEC JTC1."
2) "Subcommittee SC 32, Data Management" should be replaced with "Subcommittee SC 7, Software and Systems Engineering."
Resolution:
Revised Text:

Disposition:

To be consistent with resolution of similar comment on part 3 (OMG Issue 14406),
1)”ISO/IEC/TC JTC1” should be replaced with “ISO/IEC JTC1”
2) Remove reference to SC32.

Location:
Forword 5th paragraph
Comment:
1) This document does not have definitions clause.
Proposed Change
1) It is suggested to create definitions clause that covers at least major concepts for this standard

Do not agree to proposed change, since the terms are all defined implicitly by the text in
the body of the document as they are first introduced.

Location:
Clause 4
Comment:
This is a multipart standard, and this clause title is "4 Part1 Document". It is confusing.
Proposed Change
Delete unnecessary "Part1".

agree to proposed change

Introduction Structure of this standard
Comment:
1) The chapter numbers in Structure of this standard are not consistent with actual chapter numbers.
Proposed Change
1) Revise the chapter numbers.

Accommodate by deletion of “Structure of this Standard” unnumbered subsection. This
subsection is not required.

Introduction context of CORBA last para
Comment:
1) Since this document is submitted as PAS, it is better to reference ISO/IEC standard in addition to OMG standard
Proposed Change
1) Add ", or this standard (ISO/IEC 19500)" at the end of the first sentence.
Resolution:

accept proposed changes

Summary:
Location:
Introduction 3rd paragraph
Comment:
1) The second "Part 2" seems to be "Part 3" instead.
2) Mixed use of "RM-ODP" and "RM ODP" is confusing.
Proposed Change
1) The second "Part 2" should be replaced with "Part 3."
2) "RM ODP" should be replaced with "RM-ODP" where applicable.

Accept proposed change

Source: Japan NB, Severity te
Summary:
Japan will approve this DIS if the TH comments will accept.
Resolution:
If The TH comments JP17 were accepted in the approved resolutions. See resolutions to OMG Issues
Revised Text:

Disposition: Duplicate of xxxxxx

No Data Available

the spec defines the following in idl, the reason should be a normal long (not unsigned), some compression libraries do have a negative error number > /** > * Exception thrown when an error occurs during a compress or decompress > * operation. > */ > exception CompressionException >

; >

Change datatype of the reason member of CompressionException from “unsigned long” to “long”

"... is replaced by the CompressionData structure, which contains the
according Message compressed. The length in the GIOP MessageHeader is
updated to reflect the new message length, the other fields are
unchanged.

// PIDL: ZIOP body in ZIOP Message
module ZIOP {
struct CompressionData

;
};
"

to:
"...is replaced by the CompressionData structure, which contains the
following items encoded in this order:

· compressor: contains a identifier which indicates the compressor
algorithm used in current ZIOP message.
· original_length: contains a unsigned long value which represents the
GIOP body length of the current GIOP message without apply any
compression.
· data: is a octet sequence which contains the compressed Message."

About the following sentence, I'm sure if is correct:

"The length in the GIOP MessageHeader is updated to reflect the new
message length, the other fields are unchanged."

"The length in the GIOP Header is updated to reflect the new message
length, the other fields are unchanged as it was described below."

And the following IDL code could be moved before this paragraph:

// PIDL: ZIOP body in ZIOP Message
module ZIOP {
struct CompressionData

;
};

Update the text as proposed in section 7.4.1

compression_ratio must be changed from unsigned long to float? I agree,
more precision.

Change datatype of Compression::CompressionRatio typedef from long to float. Also the calculation of the ratio is changed to compressed_length/original_length

The words "this compressor during compression" must be changed by "this
compressor during decompression

The compressed_bytes/decompressed_bytes are added to calculate the ratio.
The ratio should be calculated based on the original bytes and the
compressed bytes of the compress operation. It doesn't make sense to use the
bytes of the decompression, there is then no relationship to the compress.
Also the decompress is unrelated to the compression level, only the compress
is related to the compression level. The number decompressed_bytes is
really the source bytes of the compress operation.

Specification: GIOP Compression (ZIOP)

Section: 7.4.1 and 2

Description:

Section 7.4.1 includes “To allow interoperability between a ZIOP and a non ZIOP party the client ORB that supports ZIOP will send only ZIOP messages to servers which have been declared to accept ZIOP messages.”

Is the decision to declare, one for the server implementer or for the ORB implementer?

Section 2 “Conformance”, offers “two optional conformance” points and then goes on to assert that at least one of these must be supported. This isn’t the usual meaning of “optional”, perhaps “alternate” would be a better word.

The second alternate would appear not to provide interoperable compression. E.g. interoperability with an ORB conforming to the first alternative.

If indeed, it is the intention that ZIOP, in some form, is mandatory (not optional) then how are existing implementations viewed? If they implement GIOP 1.2 but do not implement ZIOP, are they compliant or not?

Change 7.4.1 to just mention client/server
Change 2 to be more closed

The content of this paragraph could be updated as follows:
"This specification describes the ZIOP pluggable protocol implemented in
TIDorbJ and TIDorbC++ by Telefonica I+D and TAO by Remedy IT."

Add TIDorbJ as proposed to section 6.5

"TBD by OMG" must be replaced with the Policy ID numbers provided by
Andrew Watson

Official Policy Ids have been requested to the OMG and have been assigned.
ZIOP::COMPRESSION_ENABLING_POLICY_ID = 64
ZIOP::COMPRESSOR_ID_LEVEL_LIST_POLICY_ID = 65
ZIOP::COMPRESSION_LOW_VALUE_POLICY_ID = 66
ZIOP::COMPRESSION_MIN_RATIO_POLICY_ID = 67
Revised Text:

Change "ZIPOP" to ZIOP at this sentence: " is not required for ZIPOP at all."

Because of issue 13467 this sentence has been removed

Maybe the following sentence could be removed:
"The ServiceContext list can't be used to transfer that a GIOP
message contains compressed data because a GIOP fragment doesn't contain
a ServiceContext list."
because I think that in this stage we only need describe what is ZIOP,
instead of what is not and why not.

Remove text as proposed

Could be improved adding some words:

• "..compressor during compression *of input data* "
• "..compressor during decompression *of output data* "

The beta 1 spec now explicitly refers to the source/target argument of the
compress operation. Adding input/output doesn't clarify things to my idea,
there is no input/output in the IDL. To clarify these sections I propose to
change "side" into "argument" in section 7.3.1.6 and 7.3.1.7

Section 7.4.1 of the beta 1 spec states "GIOP compression can be applied to send or receive GIOP 1.2 messages and includes fragmented messages." There is no other mention of the GIOP versions to which ZIOP can apply. I believe it should apply to subsequent GIOP versions as well, and recommend changing the quoted text to something like "GIOP compression can be applied to send or receive GIOP 1.2 and higher messages and includes fragmented messages."

Update section as proposed

The words "..this compresso during.." must be changed by "..this
compressor during.."

Fix typo as recommended

This section was in response to OMG Request for Proposal. Only argues
why compression can not be considered at Security Layer, and it doesn't
introduces or describes any other technical issue about ZIOP. Maybe at
this stage could be removed also.

Removed section 7.5