Issue 2338: Potential interop. problem in CORBA 2.3: pseudo-operation marshalling (interop) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Existing CORBA 2.2 compatible CORBA clients will fail when invoking the non_existent pseudo-operation with a compliant CORBA 2.3 server. We have observed this problem in practice with at least one other commercial Java ORB, who changed from the Corba 2.2 marshalling to the Corba 2.3 marshalling when they changed the version of their product, thereby breaking our existing customer"s code. Section 15.4.1.2 (p. 15-31) of ptc/98-12-04 CORBA 2.3a defines the CDR marshalling for pseudo-operation non_existent in Object pseudo-interface to be _non_existent. The spec is worded in such a way that it implies that this marshalling applies for all GIOP clients, not just GIOP 1.2 client However, p. 13-23 of the CORBA 2.2 specification defines the mapping of the same pseudo-operation as _not_existent. Resolution: see below Revised Text: Resolution: ORB vendors agreed that the text "_not_existent" was a typographic error, and "_non_existent" is what the concensus was as the correct operation name for GIOP. GIOP 1.2 will only accept "_non_existent". However, since some legacy GIOP 1.0 and 1.1 mplementations respond to "_not_existent", some clarification is required to reflect the facts of legacy implementations. Based on comments earlier circulated revision for vote, the proposed replacement makes conformance require use of _non_existent, but allows implementations of GIOP 1.0 and 1.1 to respond to "_not_existent", which came from a typographical error. Proposed Revised Text: add the following text after the introduction of "_non_existent" in 15.4.1.2: " For GIOP 1.2 and later versions, only the operation name "_non_existent" shall be used. The correct operation name to use for GIOP 1.0 and 1.1 is "_non_existent". Due to a typographical error in CORBA 2.0, 2.1, and 2.2, some legacy implementations of GIOP 1.0 and 1.1 respond to the operation name "_not_existent". For maximum interoperability with such legacy implementations, new implementations of GIOP 1.0 and 1.1 may wish to respond to both operation names, "_non_existent" and "_not_existent". " Actions taken: January 22, 1999: received issue March 8, 1999: closed issue Discussion: End of Annotations:===== Date: Fri, 22 Jan 1999 13:39:49 -0800 From: Lewis Stiller To: juergen@omg.org Subject: [stiller@emerald.omg.org: Potential interoperability problem in CORBA 2.3: pseudo-operation marshalling] Here is the message I sent to ORBOS. I was told to make an issue out of it. Date: Mon, 18 Jan 1999 16:47:29 -0800 From: Lewis Stiller To: orbos@omg.org Subject: Potential interoperability problem in CORBA 2.3: pseudo-operation marshalling Existing CORBA 2.2 compatible CORBA clients will fail when invoking the non_existent pseudo-operation with a compliant CORBA 2.3 server. We have observed this problem in practice with at least one other commercial Java ORB, who changed from the Corba 2.2 marshalling to the Corba 2.3 marshalling when they changed the version of their product, thereby breaking our existing customer's code. Section 15.4.1.2 (p. 15-31) of ptc/98-12-04 CORBA 2.3a defines the CDR marshalling for pseudo-operation non_existent in Object pseudo-interface to be _non_existent. The spec is worded in such a way that it implies that this marshalling applies for all GIOP clients, not just GIOP 1.2 client However, p. 13-23 of the CORBA 2.2 specification defines the mapping of the same pseudo-operation as _not_existent. Therefore, I recommend one of the following: --------------action options------------------------------- A. Revert the pseudo-operation mapping of non_existent in GIOP 1.2 and CORBA 2.3 to that used in CORBA 2.2. B. Explicitly require in the text of Core 2.3 that GIOP 1.1 and earlier clients be allowed to use the CORBA 2.2 marshalling of non_existent pseudo-operation. C. Allow either _non_existent or _not_existent in GIOP 1.2. ---------------discussion of options------------------- Option A seems to me the most logical. Supporting two distinct and subtly incompatible pseudo-operation marshalling rules has: Ai. no benefit for the user, for whom CDR marshalling rules are immaterial Aii. no benefit for current ORB implementors, who must support two marshalling rules in both the client and the server for the forseeable future in order to assure interoperability. Aiii. no benefit for future ORB implementors, who must read not only the published 2.3 spec regarding _non_existent marshalling, but also the 2.2 spec, in order to determine how old GIOP marshalling schemes worked and thus legacy clients. Aiv. Actual disadvantages for legacy GIOP/IIOP users who will find that their code, in practise, can suddenly break. (That is, according to the 2.3 spec, it is compliant for a Core 2.3 compatible ORB to signal an error if it receives a legal GIOP 1.0 request for pseudo_operation invocation. In practice, of course, some ORBs are likely to support both _non_existent and _not_existent; some only the Core 2.3 version, and some only the Core 2.2 version. However, since it might be too late administratively to implement option A, we should at least do option B or C. These are functionally identical for users, but Option C is easier for vendors to implement (because under option B). In conclusion, we should make sure that Core 2.3 ensures interoperability with GIOP 1.1 clients/servers. The current wording does not do this. Date: Mon, 15 Feb 1999 14:32:08 -0500 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies To: Lewis Stiller , interop@omg.org Subject: Re: Issue 2338 - Urgent Discussion Needed References: <199902130045.QAA13487@corba.franz.com> I just realized that the Interop 2.4 RTF report is due on March 8. I think most of the issues can be handled simply (i.e., postpone all GIOP efficiency improvement requests again etc.) but one issue needs discussion. Issue 2338 is stated as follows: Issue 2338: Potential interop. problem in CORBA 2.3: pseudo-operation marshalling (interop) Click here for this issue's archive. Source: Franz (Dr. Lewis Stiller, stiller@franz.com) Nature: Uncategorized Issue Severity: Summary: Existing CORBA 2.2 compatible CORBA clients will fail when invoking the non_existent pseudo-operation with a compliant CORBA 2.3 server. We have observed this problem in practice with at least one other commercial Java ORB, who changed from the Corba 2.2 marshalling to the Corba 2.3 marshalling when they changed the version of their product, thereby breaking our existing customer's code. Section 15.4.1.2 (p. 15-31) of ptc/98-12-04 CORBA 2.3a defines the CDR marshalling for pseudo-operation non_existent in Object pseudo-interface to be _non_existent. The spec is worded in such a way that it implies that this marshalling applies for all GIOP clients, not just GIOP 1.2 client However, p. 13-23 of the CORBA 2.2 specification defines the mapping of the same pseudo-operation as _not_existent. Resolution: ----------- Lewis Stiller wrote: > > Thank you for the reply to my issue regarding the status of the > mapping of the non_existent pseudo-operation. > > First, as a small point of semantics, the phrase "orbs which send > 'not_existent'" below should presumably read "orbs which send > _not_existent". > > Based on the information I: I don't see the evidence that > "_not_existent" was a typo. > > In detail: > > A. The "t" and the "n" are not even close to one another on > the typewriter keyboard. If the phrase had been "_nom_existent", for > example, I could imagine it's being a typo, but I don't think it's > likely that the "t" and the "n" would have been confused by the > typist. > > B. Sometimes the OMG uses "not_exist" and sometimes it uses > "non_exist". For example, there is a system name > OBJECT_NOT_EXISTENT. Can > the OMG suddenly decide "oh, the "T" there is a typo for "N" and all > ORBs which were sending OBJECT_NOT_EXIST are nonconformant and must > send OBJECT_NON_EXIST? Of course not. v > > C. Where is it written that "the marshalling of the > pseudo-op > must be the same as the pseudo-op name prepended by an underscore"? > If > there was such a rule, then the argument might make sense. But there > is no such rule. On the contrary, the marshalling of > get_interface > is as > _interface > and not > _get_interface > > If you want to claim that _not_existent was a typo for > _non_existent, then why not claim that _interface is a typo for > _get_interface as well? > > D. Numerous ORB vendors have implemented the non_existent > pseudo-op using the old specs (2.0, 2.1, and 2.2). Had any of them > felt there was a typo, they would simply have raised the issue at > the > time. In fact, when I send _interface to an ORB, I expect it to send > me back an interfacedef; when I send _not_existent to one I expect > it > to send a boolean. > > As a specific example, consider Visibroker 3.2 for > Java. This > widely used ORB responds to the _not_existent message but will > signal > an error on _non_existent. This is conformant, correct behavior. Who > knows how many other ORBs do this? > > Conclusion: > It seems from the above analysis that a conformant 2.0, 2.1, and 2.2 > orb MUST respond to _not_existent, as there is no way an ORB > implementor could know or deduce that part of the spec for 5 years > or > so was actually a typo. > > ----------- > > > From: Tom Rutt > > Reply-To: terutt@lucent.com > > Organization: Lucent Technologies - Bell Labs > > > > DR. Lewis Stiller > > > > Regarding your issue 2338, I have talked to OMG staff and the > > interpretation of the closed issue which changed "not_existent" > > to "non_existent" had the rationale that the "not" was a typo, > and > > thus should never have been in corba 2.0, 2.1, and 2.2 text. > > > > Thus it is not tied to giop version, in fact orbs which send > > "not_existent" are not in conformance with CORBA GIOP of any > > version. > > > > I want to know what you think of this resolution, before I post > > it for vote on the Interop mailing list. > > -- > > ---------------------------------------------------------------- > > Tom Rutt Tel: +1 732 949 7862 > > Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 > > Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com > > Holmdel NJ, 07733 ---------------------------------------------- > > -- ---------------------------------------------------------------- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com Holmdel NJ, 07733 ---------------------------------------------- Date: Tue, 16 Feb 1999 06:05:41 +1000 (EST) From: Michi Henning To: Tom Rutt cc: Lewis Stiller , interop@omg.org Subject: Re: Issue 2338 - Urgent Discussion Needed Organization: Triodia Technologies On Mon, 15 Feb 1999, Tom Rutt wrote: > Summary: Existing CORBA 2.2 compatible CORBA clients will fail when > invoking the > non_existent pseudo-operation with a compliant CORBA 2.3 server. We > have > observed this problem in practice with at least one other commercial > Java ORB, > who changed from the Corba 2.2 marshalling to the Corba 2.3 > marshalling when > they changed the version of their product, thereby breaking our > existing > customer's code. Section 15.4.1.2 (p. 15-31) of ptc/98-12-04 CORBA > 2.3a defines > the CDR marshalling for pseudo-operation non_existent in Object > pseudo-interface > to be > _non_existent. The spec is worded in such a way that it implies that > this > marshalling applies for all GIOP clients, not just GIOP 1.2 client > However, p. > 13-23 of the CORBA 2.2 specification defines the mapping of the same > pseudo-operation as _not_existent. I have a lot of sympathy for people who complain that the change from _not_existent to _non_existent was gratuitous and unnecessary. As if it mattered how it's spelled. However, changing it seems to upset quite a few people when things break... The only solution I can see now is that 2.4 and later ORBs must accept both spellings and that, for GIOP 1.0 and 1.1, _not_existent must be used. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Mon, 15 Feb 1999 20:11:44 -0500 From: Bob Kukura Organization: IONA Technologies X-Accept-Language: en To: Michi Henning CC: Tom Rutt , Lewis Stiller , interop@omg.org Subject: Re: Issue 2338 - Urgent Discussion Needed References: My recollection is that this was changed because "_not_existent" was considered a typo, and the majority of GIOP implementations known to the RTF members at the time actually expected and generated "_non_existent". See issue 1160. The typo was corrected in order to make the specification match the existing (known to the RTF) implementations. I could see potentially acknowledging that existing GIOP 1.0 and 1.1 implementations might use either, and requiring or suggesting that current implementations of GIOP 1.0 and 1.1 accept either spelling. But this still leaves current GIOP 1.0 and 1.1 implementations with having to choose which old implementations they will interoperate with through the choice of the spelling that they emit. If there really is no consensus on this, the emitted spelling is probably best left as a vendor decision. But I don't see any point in continuing this unfortunate situation in GIOP 1.2. GIOP 1.2 should simply mandate use of one spelling ("_non_existant"). -Bob Michi Henning wrote: > > On Mon, 15 Feb 1999, Tom Rutt wrote: > > Summary: Existing CORBA 2.2 compatible CORBA clients will fail > when invoking the > > non_existent pseudo-operation with a compliant CORBA 2.3 > server. We have > > observed this problem in practice with at least one other > commercial Java ORB, > > who changed from the Corba 2.2 marshalling to the Corba 2.3 > marshalling when > > they changed the version of their product, thereby breaking our > existing > > customer's code. Section 15.4.1.2 (p. 15-31) of ptc/98-12-04 CORBA > 2.3a defines > > the CDR marshalling for pseudo-operation non_existent in Object > pseudo-interface > > to be > > _non_existent. The spec is worded in such a way that it implies > that this > > marshalling applies for all GIOP clients, not just GIOP 1.2 client > However, p. > > 13-23 of the CORBA 2.2 specification defines the mapping of the > same > > pseudo-operation as _not_existent. > > I have a lot of sympathy for people who complain that the change > from > _not_existent to _non_existent was gratuitous and unnecessary. As if > it mattered how it's spelled. However, changing it seems to upset > quite > a few people when things break... > > The only solution I can see now is that 2.4 and later ORBs > must accept both spellings and that, for GIOP 1.0 and 1.1, > _not_existent > must be used. > > Cheers, > > > Michi. > -- > Michi Henning +61 7 3236 1633 > Triodia Technologies +61 4 1118 2700 (mobile) > PO Box 372 +61 7 3211 0047 (fax) > Annerley 4103 michi@triodia.com > AUSTRALIA > http://www.triodia.com/staff/michi-henning.html From: "Martin Chapman" To: "Bob Kukura" , "Michi Henning" Cc: "Tom Rutt" , "Lewis Stiller" , Subject: RE: Issue 2338 - Urgent Discussion Needed Date: Tue, 16 Feb 1999 20:03:28 -0000 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 As the one who raised this molehill, I have to say that Bob gave the right answer. We checked with all vendors active on the RTF and most seem to marshall as _non_existent (the others had no problems to make the change), thus the change was to make the spec reflect reality. Since this change was for 1.2, it wasn't expected to be retroactively applied to 1.0, 1.1. Martin. > -----Original Message----- > From: Bob Kukura [mailto:kukura@iona.com] > Sent: 16 February 1999 01:12 > To: Michi Henning > Cc: Tom Rutt; Lewis Stiller; interop@omg.org > Subject: Re: Issue 2338 - Urgent Discussion Needed > > > My recollection is that this was changed because "_not_existent" was > considered a typo, and the majority of GIOP implementations known to > the > RTF members at the time actually expected and generated > "_non_existent". See issue 1160. The typo was corrected in order > to > make the specification match the existing (known to the RTF) > implementations. > > I could see potentially acknowledging that existing GIOP 1.0 and 1.1 > implementations might use either, and requiring or suggesting that > current implementations of GIOP 1.0 and 1.1 accept either spelling. > But > this still leaves current GIOP 1.0 and 1.1 implementations with > having > to choose which old implementations they will interoperate with > through > the choice of the spelling that they emit. If there really is no > consensus on this, the emitted spelling is probably best left as a > vendor decision. > > But I don't see any point in continuing this unfortunate situation > in > GIOP 1.2. GIOP 1.2 should simply mandate use of one spelling > ("_non_existant"). > > -Bob > > Michi Henning wrote: > > > > On Mon, 15 Feb 1999, Tom Rutt wrote: > > > Summary: Existing CORBA 2.2 compatible CORBA clients will > fail when invoking the > > > non_existent pseudo-operation with a compliant CORBA 2.3 > server. We have > > > observed this problem in practice with at least one other > commercial Java ORB, > > > who changed from the Corba 2.2 marshalling to the Corba 2.3 > marshalling when > > > they changed the version of their product, thereby breaking > our existing > > > customer's code. Section 15.4.1.2 (p. 15-31) of ptc/98-12-04 > CORBA 2.3a defines > > > the CDR marshalling for pseudo-operation non_existent in > Object pseudo-interface > > > to be > > > _non_existent. The spec is worded in such a way that it > implies that this > > > marshalling applies for all GIOP clients, not just GIOP 1.2 > client However, p. > > > 13-23 of the CORBA 2.2 specification defines the mapping of the > same > > > pseudo-operation as _not_existent. > > > > I have a lot of sympathy for people who complain that the change > from > > _not_existent to _non_existent was gratuitous and unnecessary. As > if > > it mattered how it's spelled. However, changing it seems to upset > quite > > a few people when things break... > > > > The only solution I can see now is that 2.4 and later ORBs > > must accept both spellings and that, for GIOP 1.0 and 1.1, > _not_existent > > must be used. > > > > Cheers, > > > > > Michi. > > -- > > Michi Henning +61 7 3236 1633 > > Triodia Technologies +61 4 1118 2700 (mobile) > > PO Box 372 +61 7 3211 0047 (fax) > > Annerley 4103 michi@triodia.com > > AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Thu, 18 Feb 1999 23:56:42 -0800 From: "George Scott" Organization: Inprise Corporation X-Accept-Language: en To: Bob Kukura CC: interop@omg.org Subject: Re: Issue 2338 - Urgent Discussion Needed References: <36C8C5D0.A1CD38C8@iona.com> Bob Kukura wrote: > > > But I don't see any point in continuing this unfortunate situation > in > GIOP 1.2. GIOP 1.2 should simply mandate use of one spelling > ("_non_existant"). Bob, I'm assuming that you meant "_non_existent" and not "_non_existant". I was hoping we wouldn't have to add a third spelling of this operation to our product. ;-) George Date: Tue, 23 Feb 1999 11:15:44 +1000 (EST) From: Michi Henning To: Tom Rutt cc: interop@omg.org Subject: Re: Interop 2.4 RTF Vote 1 Organization: Triodia Technologies Content-ID: On Fri, 19 Feb 1999, Tom Rutt wrote: > zPlease vote on the attached proposed issue resolutions for Interop RTF 2.4, by > 5:00 PM EST, February 26, 1999. DSTC votes as follows: YES to 543, 1129, 1653, 1948, 1975, 1982, 2045, 2315, 2324, 2333. YES with option (c) to 1968. NO to 2068 and 2338 (2338 with a friendly amendment) 2068 rationale: > Resolution: Add clarification note stating use of both components is not > understood > Proposed Revised Text: Add a note after the definition of TAG_IIOP_ALTERNATE_ADDRESSS: > " > Note: The use of a TAG_IIOP_ALTERNATE_ADDRESS component together with a > TAG_SSL_SEC_TRANS component in the same IOR profile is for further study. To paraphrase: "We have no idea what this stuff actually means but we are confident we'll figure it out eventually." I don't think there is room in a specification for such words (blunt or not). 2338 rationale: > For GIOP 1.2 only the operation name "_non_existent" shall be used. ^^^^^^^^^^^^^^^^ I have no problem with the proposed resolution, but I suggest to change the wording of the above to "For GIOP 1.2 and later versions". Otherwise, we have to endlessly go back and patch this phrase as the protocol evolves. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Sender: jis@fpk.hp.com Date: Wed, 03 Mar 1999 14:59:40 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: terutt@lucent.com CC: jeffm@inprise.com, kukura@iona.com, jon@biggar.org, drs@nortelnetworks.com, stephen@aptest.ie, randyfox@austin.ibm.com, janssen@parc.xerox.com, michi@triodia.com, bill@novell.com, bill.beckwith@ois.com, ed.cobb@beasys.com, Ken Cavanaugh , interop@omg.org Subject: Re: Resend Interop 2.4 RTF Vote 2 (due Friday) References: <36CDCCC8.A56C7C0B@lucent.com> <36CDDE9C.660B21B0@lucent.com> <36CDE13C.C5FA5660@lucent.com> <36D5B46F.23437F78@lucent.com> <36DC6033.5BDACD0D@lucent.com> <36DC63FC.4A4521E4@lucent.com> HP votes in favor of all issues on Interop 2.4 Vote 2, except 2338 on which we ABSTAIN. In the proposed resolution for 2338 it says: "The correct operation name to use for GIOP 1.0 and 1.1 is "_non_existent". Due to a typographical error in CORBA 2.0, 2.1, and 2.2, some legacy implementations of GIOP 1.0 and 1.1 respond to the operation name "_not_existent". For maximum interoperability with such legacy implementations, new implementations of GIOP 1.0 and 1.1 may wish to respond to both operation names, "_non_existent" and "_not_existent"." Shouldn't the last sentence say: "new implementations of GIOP 1.0 and 1.1 must respond to both operation names, "_non_existent" and "_not_existent"." How do you get interoperability if you have no idea whether it will or will not respond? Afterall, it wasn't the fault of those that implemented their GIOP 1.0/1.1 by reading published OMG specs which had the incorrect spelling in it for years. I am ABSTAINING instead of voting NO mainly because, at the end of the day the most prevalent already existing implementations of 1.0/1.1 are not going to change whatever they are doing, unless some customer of them beats them up, and then too if they consider their market share to be threatened and not otherwise.:-) So in effect this will have very little impact on the state of affairs. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA.