ZIOP 1.0 FTF Avatar
  1. OMG Issue

ZIOP — ZIOP issue - compliance

  • Key: ZIOP-1
  • Legacy Issue Number: 13344
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Dave Stringer)
  • Summary:

    Specification: GIOP Compression (ZIOP)

    Section: 7.4.1 and 2


    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?

  • Reported: ZIOP 1.0b1 — Mon, 26 Jan 2009 05:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT