Issue 3576: Absence of Wide Character Code Set (interop) Source: (, ) Nature: Uncategorized Issue Severity: Summary: CORBA is inconsistent on how to deal with the lack wide character code set information in an IOR and the codes set service context. When a server receives a service context without a wide character code set specified, then it is supposed to raise BAD_PARAM when it receives wide characters data from the client. However a client is supposed to raise INV_OBJREF if the IOR is missing from the server's native wchar code set . In CORBA 2.3, section13.7.2.6, "Code Set Negotiation", it says, "... a server that supports interfaces that use wide character data is required to specify its native wchar code set; if one is not specified, then the client-side ORB raises exception INV_OBJREF." This requires a client to know whether a server supports interfaces that use wide character data at the time the client receives an IOR. To determine this when the first IOR is received is a burdensome task. The client orb would be forced to apply an exhaustive examination, such scanning all of the server's IDL bindings or the contents of the IFR looking for wchar types. Additionally the client may need to determine if some Any might flow containing wchar data. I propose that the client's behavior be changed to match the server's. If any wide character data is encountered and the server's IOR was missing the native wchar code set, (which would cause the wide character transmission code set to not be negotiated), the client should raise BAD_PARAM. This will allow common marshal and demarshal code to be independent of whether it is running as a client or server. It also allows users to not configure wide character code sets if they know they aren't using them. Resolution: The check should be able to be done at invoke time by the client orb Revised Text: The check should be able to be done at invoke time by the client orb. This should be clarified in the text describing INV_OBJREF. Revised Text: Add clarification to description of INV_OBJREF, in 4.11.3.6: " If the client invokes an operation which results in an attempt by the client orb to marshall wchar or wstring data for an in parameter (or to unmarshal wchar or wstring data for an in/out parameter, out parameter or the return value), and the associated object reference does not contain a codeset component, the INV_OBJREF standard system exception is raised. " Add the following paragraph to 13.9.2.4: " If a client application invokes an operation which results in an attempt by the client orb to marshall wchar or wstring data for an in parameter (or to unmarshal wchar or wstring data for an in/out parameter, out parameter or the return value), and the associated Object Reference does not include a codeset component, then the client ORB shall raise the INV_OBJREF standard system exception (with standard minor code k) as a response to the operation invocation. " Add the following minor codes to table 4-3 for INV_OBJREF Standard System exception: " INV_OBJREF k Codeset component required for type using wchar or wstring data " Actions taken: April 21, 2000: received issue April 28, 2000: moved from core to Interop February 27, 2001: closed issue Discussion: A Client ORB could check the interface definition upon receipt of an IOR, to determine if the interface type referenced in the IOR has any Wide character or WideString parameters in any of its operations. However, it seems inappropriate for the Client ORB to be required check the use of wchar or wstring in all interfaces of a server system when an IOR is received. End of Annotations:===== From: mbcoats@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA23136 for ; Fri, 21 Apr 2000 14:47:33 -0500 Received: from d54mta08.raleigh.ibm.com (d54mta08.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id PAA26010 for ; Fri, 21 Apr 2000 15:06:43 -0400 Received: by d54mta08.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568C8.0068F656 ; Fri, 21 Apr 2000 15:06:28 -0400 X-Lotus-FromDomain: IBMUS To: issues@omg.org Message-ID: <852568C8.0068EDB3.00@d54mta08.raleigh.ibm.com> Date: Fri, 21 Apr 2000 13:56:44 -0500 Subject: Absence of Wide Character Code Set Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: ~iV!!"A0e9SAQ!!`MY!! CORBA is inconsistent on how to deal with the lack wide character code set information in an IOR and the codes set service context. When a server receives a service context without a wide character code set specified, then it is supposed to raise BAD_PARAM when it receives wide characters data from the client. However a client is supposed to raise INV_OBJREF if the IOR is missing from the server's native wchar code set . In CORBA 2.3, section13.7.2.6, "Code Set Negotiation", it says, "... a server that supports interfaces that use wide character data is required to specify its native wchar code set; if one is not specified, then the client-side ORB raises exception INV_OBJREF." This requires a client to know whether a server supports interfaces that use wide character data at the time the client receives an IOR. To determine this when the first IOR is received is a burdensome task. The client orb would be forced to apply an exhaustive examination, such scanning all of the server's IDL bindings or the contents of the IFR looking for wchar types. Additionally the client may need to determine if some Any might flow containing wchar data. I propose that the client's behavior be changed to match the server's. If any wide character data is encountered and the server's IOR was missing the native wchar code set, (which would cause the wide character transmission code set to not be negotiated), the client should raise BAD_PARAM. This will allow common marshal and demarshal code to be independent of whether it is running as a client or server. It also allows users to not configure wide character code sets if they know they aren't using them. Thanks, Mark Coats _________________________________________ Mark Coats - Component Broker development IBM Austin, Texas mbcoats@us.ibm.com (512) 823-7321 tieline 793-7321 Sender: jbiggar@corvette.floorboard.com Message-ID: <3900B9C9.6E826BFE@floorboard.com> Date: Fri, 21 Apr 2000 13:27:53 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mbcoats@us.ibm.com CC: issues@omg.org Subject: Re: Absence of Wide Character Code Set References: <852568C8.0068EDB3.00@d54mta08.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $@Vd98a*!!U?Ge9Xia!! mbcoats@us.ibm.com wrote: > > CORBA is inconsistent on how to deal with the lack wide character code set > information in an IOR and the codes set service context. > > When a server receives a service context without a wide character code set > specified, then it is supposed to raise BAD_PARAM when it receives wide > characters data from the client. > > However a client is supposed to raise INV_OBJREF if the IOR is missing > from the server's native wchar code set . In CORBA 2.3, section13.7.2.6, > "Code Set Negotiation", it says, "... a server that supports interfaces > that > use wide character data is required to specify its native wchar code set; > if > one is not specified, then the client-side ORB raises exception > INV_OBJREF." > > This requires a client to know whether a server supports interfaces that > use > wide character data at the time the client receives an IOR. To determine > this when the first IOR is received is a burdensome task. The client orb > would be forced to apply an exhaustive examination, such scanning all of > the > server's IDL bindings or the contents of the IFR looking for wchar types. > Additionally the client may need to determine if some Any might flow > containing wchar data. I believe that the spec does not require raising INV_OBJREF at the time the IOR is received, but instead it can be raised at the time a wide character or wide string is marshalled. This allows the ORB to postpone detection of the error until it is easy to discover the problem. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: mbcoats@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA12902; Mon, 24 Apr 2000 10:42:40 -0500 Received: from d54mta08.raleigh.ibm.com (d54mta08.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id KAA28290; Mon, 24 Apr 2000 10:51:28 -0400 Received: by d54mta08.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568CB.00519945 ; Mon, 24 Apr 2000 10:51:16 -0400 X-Lotus-FromDomain: IBMUS To: Jonathan Biggar cc: issues@omg.org Message-ID: <852568CB.005151A1.00@d54mta08.raleigh.ibm.com> Date: Mon, 24 Apr 2000 09:39:14 -0500 Subject: Re: Absence of Wide Character Code Set Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: moHe9+1>e9S]#e9D4J!! Thanks for your input, Jonathan. You're right, there is enough ambiguity in the spec to allow the exception to be raised at the time wchar data is encountered. However that still leaves two points. 1) The error thrown is inconsistent and 2) INV_OBJREF being thrown against an object reference that might have been functioning quite nicely prior to the occurence of wchar data. Any further thoughts? Thanks, Mark _________________________________________ Mark Coats - Component Broker development IBM Austin, Texas mbcoats@us.ibm.com (512) 823-7321 tieline 793-7321 Jonathan Biggar on 04/21/2000 03:27:53 PM To: Mark Coats/Austin/IBM@IBMUS cc: issues@omg.org Subject: Re: Absence of Wide Character Code Set mbcoats@us.ibm.com wrote: > > CORBA is inconsistent on how to deal with the lack wide character code set > information in an IOR and the codes set service context. > > When a server receives a service context without a wide character code set > specified, then it is supposed to raise BAD_PARAM when it receives wide > characters data from the client. > > However a client is supposed to raise INV_OBJREF if the IOR is missing > from the server's native wchar code set . In CORBA 2.3, section13.7.2.6, > "Code Set Negotiation", it says, "... a server that supports interfaces > that > use wide character data is required to specify its native wchar code set; > if > one is not specified, then the client-side ORB raises exception > INV_OBJREF." > > This requires a client to know whether a server supports interfaces that > use > wide character data at the time the client receives an IOR. To determine > this when the first IOR is received is a burdensome task. The client orb > would be forced to apply an exhaustive examination, such scanning all of > the > server's IDL bindings or the contents of the IFR looking for wchar types. > Additionally the client may need to determine if some Any might flow > containing wchar data. I believe that the spec does not require raising INV_OBJREF at the time the IOR is received, but instead it can be raised at the time a wide character or wide string is marshalled. This allows the ORB to postpone detection of the error until it is easy to discover the problem. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@corvette.floorboard.com Message-ID: <390461A9.16F6AC77@floorboard.com> Date: Mon, 24 Apr 2000 08:00:57 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: mbcoats@us.ibm.com CC: issues@omg.org Subject: Re: Absence of Wide Character Code Set References: <852568CB.005151A1.00@d54mta08.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Voad9:Q+!!A(j!!)hBe9 mbcoats@us.ibm.com wrote: > > Thanks for your input, Jonathan. You're right, there is enough ambiguity > in > the spec to allow the exception to be raised at the time wchar data is > encountered. > > However that still leaves two points. 1) The error thrown is inconsistent > and > 2) INV_OBJREF being thrown against an object reference that might have > been functioning quite nicely prior to the occurence of wchar data. INV_OBJREF has the correct semantics for this error. The specification requires that object references which support operations that use wide characters have a valid CodeSet component. If it does not, then the reference is illegal. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jbiggar@corvette.floorboard.com Message-ID: <3904BCF8.1C79F848@floorboard.com> Date: Mon, 24 Apr 2000 14:30:32 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: mbcoats@us.ibm.com, issues@omg.org Subject: Re: Absence of Wide Character Code Set References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: GX;!!RG$!!*nld9(W*e9 Michi Henning wrote: > Where this gets particularly noisome is in the following case: > > interface old { > string op(); > }; > > Two years later, I do: > > interface new : old { > wstring op2(); > }; > > In addition, I want to replace the implementation of my existing old objects > with implementations for new objects, to transparently migrate the server. > However, all old references that I have handed out in the passed won't > worked for new objects, even if new clients can successfully narrow them. > Of course, that's against what we are saying on page 13-17: > > The type ID, if provided by the server, indicates the most > derived type that the server wishes to publish, at the time > the reference is generated. The object's actual most derived > type may later change to a more derived type. Therefore, > the type ID in the IOR can only be interpreted by the client > as a hint that the object supports at least the indicated > interface. The client can succeed in narrowing the reference > to the indicated interface, or to one of its base interfaces, > based solely on the type ID in the IOR, > > With the scenario I outlined, clients will successfully narrow the IOR, > only to be unable to invoked the derived operation, which will raise > INV_OBJREF :-( Which, I suppose again argues for the usefulness of an operation defined on Object that would return a new "refreshed" object reference. This could help in the object migration headaches, too. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 25 Apr 2000 07:49:29 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: mbcoats@us.ibm.com, issues@omg.org Subject: Re: Absence of Wide Character Code Set In-Reply-To: <3904BCF8.1C79F848@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 'M2!!W"Ud9+l=e9J[Oe9 On Mon, 24 Apr 2000, Jonathan Biggar wrote: > > With the scenario I outlined, clients will successfully narrow the IOR, > > only to be unable to invoked the derived operation, which will raise > > INV_OBJREF :-( > > Which, I suppose again argues for the usefulness of an operation defined > on Object that would return a new "refreshed" object reference. This > could help in the object migration headaches, too. Well, I think it argues for the fact that codesets weren't well designed first and foremost. Without codeset negotiation, this becomes a non-issue. The problem here is that it's not even possible to location forward a new reference because INV_OBJREF will be thrown on the client side. I don't like the idea of an explicit refresh operation on Object at all. It brings up things at the API level that should be kept buried in the run time, I think. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@corvette.floorboard.com Message-ID: <3904C3BE.7DC873E2@floorboard.com> Date: Mon, 24 Apr 2000 14:59:26 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: mbcoats@us.ibm.com, issues@omg.org Subject: Re: Absence of Wide Character Code Set References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: V`Wd9^JHe98(C!!=H7e9 Michi Henning wrote: > I don't like the idea of an explicit refresh operation on Object at all. > It brings up things at the API level that should be kept buried in the > run time, I think. Unfortunately, I think that is an impractical desire, since the ORB runtime is not involved in saving object references to persistent store. There will ultimately need to be some sort of system to notify clients that their references are out of date and need to be refreshed. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 25 Apr 2000 08:05:10 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: mbcoats@us.ibm.com, Core Revision Task Force Subject: Re: Absence of Wide Character Code Set In-Reply-To: <3904C3BE.7DC873E2@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ~*Le9$$0e99L'!!6I;e9 On Mon, 24 Apr 2000, Jonathan Biggar wrote: > Michi Henning wrote: > > I don't like the idea of an explicit refresh operation on Object at all. > > It brings up things at the API level that should be kept buried in the > > run time, I think. > > Unfortunately, I think that is an impractical desire, since the ORB > runtime is not involved in saving object references to persistent > store. There will ultimately need to be some sort of system to notify > clients that their references are out of date and need to be refreshed. [ I've changed "issues" to "orb_revision" in the CC list. ] Ah, I see what you mean now. It's the old issue of how to get rid of old references in something like a naming service. In the particular case we are discussing here (if we didn't have codeset negotiation), it actually wouldn't matter because the old and new reference would both be equally valid. But I see your point in general terms -- that's closely related to the LOCATION_FORWARD_PERM idea. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Tue, 25 Apr 2000 06:32:56 +1000 (EST) From: Michi Henning To: mbcoats@us.ibm.com cc: Jonathan Biggar , issues@omg.org Subject: Re: Absence of Wide Character Code Set In-Reply-To: <852568CB.005151A1.00@d54mta08.raleigh.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: g#ld9d=]!!:'@!!-]D!! On Mon, 24 Apr 2000 mbcoats@us.ibm.com wrote: > Thanks for your input, Jonathan. You're right, there is enough ambiguity > in > the spec to allow the exception to be raised at the time wchar data is > encountered. > > However that still leaves two points. 1) The error thrown is inconsistent > and > 2) INV_OBJREF being thrown against an object reference that might have > been functioning quite nicely prior to the occurence of wchar data. > > Any further thoughts? Where this gets particularly noisome is in the following case: interface old { string op(); }; Two years later, I do: interface new : old { wstring op2(); }; In addition, I want to replace the implementation of my existing old objects with implementations for new objects, to transparently migrate the server. However, all old references that I have handed out in the passed won't worked for new objects, even if new clients can successfully narrow them. Of course, that's against what we are saying on page 13-17: The type ID, if provided by the server, indicates the most derived type that the server wishes to publish, at the time the reference is generated. The object's actual most derived type may later change to a more derived type. Therefore, the type ID in the IOR can only be interpreted by the client as a hint that the object supports at least the indicated interface. The client can succeed in narrowing the reference to the indicated interface, or to one of its base interfaces, based solely on the type ID in the IOR, With the scenario I outlined, clients will successfully narrow the IOR, only to be unable to invoked the derived operation, which will raise INV_OBJREF :-( Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: "Interop RTF (E-mail)" Subject: RE: Absence of Wide Character Code Set Date: Tue, 25 Apr 2000 18:04:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ]`dd9RFSd99PC!!k:;e9 Michi, In your example below, the old object references were for type "old" and had no codeset info. If a client is aware of the "new" interface and attempts to narrow one of these old ones, it will need to first determine that is is legal by calling _is_a. If the server has provided new implementations for the old keys, then the normal answer to this would be TRUE. Then, the client would permit the narrowing, and the object would be usable but wouldn't have the codeset info associated. I guess this is the point you are trying to make. There is a workaround for the server writer. Instead of implementing the old keys, it can use new objects with some other keys. It can then provide a servant manager that recognizes the old keys and returns a LOCATION_FORWARD to the new ones. This isn't especially appealing, but it will work. Unfortunately, the client is then left with a connection without the codesets specified by the new object. Apparently in this case it may be required to establish a new connection to use the new objects. This sucks. However this may actually not be necessary. If the old objects specified iiop version 1.0, then the connection would have probably been established as giop 1.0. If the iiop version for the new ior is 1.2, then it should be possible to send a codeset service context on the first giop 1.2 request and establish the proper codeset handling for giop 1.2 messages. Paul > From: Michi Henning [mailto:michi@ooc.com.au] > Where this gets particularly noisome is in the following case: > > interface old { > string op(); > }; > > Two years later, I do: > > interface new : old { > wstring op2(); > }; > > In addition, I want to replace the implementation of my > existing old objects > with implementations for new objects, to transparently > migrate the server. > However, all old references that I have handed out in the passed > won't > worked for new objects, even if new clients can successfully > narrow them. > Of course, that's against what we are saying on page 13-17: > > The type ID, if provided by the server, indicates the most > derived type that the server wishes to publish, at the time > the reference is generated. The object's actual most derived > type may later change to a more derived type. Therefore, > the type ID in the IOR can only be interpreted by the client > as a hint that the object supports at least the indicated > interface. The client can succeed in narrowing the reference > to the indicated interface, or to one of its base interfaces, > based solely on the type ID in the IOR, > > With the scenario I outlined, clients will successfully > narrow the IOR, > only to be unable to invoked the derived operation, which will raise > INV_OBJREF :-( > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > Date: Wed, 26 Apr 2000 08:44:49 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: "Interop RTF (E-mail)" Subject: RE: Absence of Wide Character Code Set In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BE32@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: B7bd97iZd9k5`!!m^`!! On Tue, 25 Apr 2000, Paul Kyzivat wrote: > In your example below, the old object references were for type "old" and had > no codeset info. If a client is aware of the "new" interface and attempts to > narrow one of these old ones, it will need to first determine that is is > legal by calling _is_a. If the server has provided new implementations for > the old keys, then the normal answer to this would be TRUE. Then, the client > would permit the narrowing, and the object would be usable but wouldn't have > the codeset info associated. I guess this is the point you are trying to > make. Yes, exactly. > There is a workaround for the server writer. Instead of implementing the old > keys, it can use new objects with some other keys. It can then provide a > servant manager that recognizes the old keys and returns a LOCATION_FORWARD > to the new ones. This isn't especially appealing, but it will work. Interesting thought, this technique didn't occur to me. Seems somewhat roundabout though... > Unfortunately, the client is then left with a connection without the > codesets specified by the new object. Apparently in this case it may > be > required to establish a new connection to use the new objects. This > sucks. Yes. You can't mix invocations using different codesets on the same connection. Yet another appalling consequence of the lack of a session concept. > However this may actually not be necessary. If the old objects specified > iiop version 1.0, then the connection would have probably been established > as giop 1.0. If the iiop version for the new ior is 1.2, then it should be > possible to send a codeset service context on the first giop 1.2 request and > establish the proper codeset handling for giop 1.2 messages. That's something we are still not sure about, I believe. It's not clear at what point the codeset information can be sent. For example, there may be 1.2 invocations that don't touch an operation with wchar/wstring parameters first. In that case, it's not clear whether the codeset info must be sent regardless, or whether it can be delayed until the first operation invocation that does require a codeset. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@corvette.floorboard.com Message-ID: <39062946.EA85FDC3@floorboard.com> Date: Tue, 25 Apr 2000 16:24:54 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: "Interop RTF (E-mail)" Subject: Re: Absence of Wide Character Code Set References: <9B164B713EE9D211B6DC0090273CEEA926BE32@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: pBZ!!@ofd9[(Qd9#\d!! Paul Kyzivat wrote: > However this may actually not be necessary. If the old objects specified > iiop version 1.0, then the connection would have probably been established > as giop 1.0. If the iiop version for the new ior is 1.2, then it should be > possible to send a codeset service context on the first giop 1.2 request and > establish the proper codeset handling for giop 1.2 messages. Isn't this illegal? I thought we made it clear that the maximum GIOP version that could be used on a connection was the IIOP version in the IOR. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Paul Kyzivat To: "Interop RTF (E-mail)" Subject: RE: Absence of Wide Character Code Set Date: Tue, 25 Apr 2000 19:46:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: &P?!!GYa!!=6Be9Y`W!! > From: Jonathan Biggar [mailto:jon@floorboard.com] > Paul Kyzivat wrote: > > However this may actually not be necessary. If the old > objects specified > > iiop version 1.0, then the connection would have probably > been established > > as giop 1.0. If the iiop version for the new ior is 1.2, > then it should be > > possible to send a codeset service context on the first > giop 1.2 request and > > establish the proper codeset handling for giop 1.2 messages. > > Isn't this illegal? I thought we made it clear that the maximum > GIOP > version that could be used on a connection was the IIOP version in > the > IOR. Which IOR? I have two IORs with the same address, but different giop versions. If the 1.0 ior had no codeset info (it couldn't), and the 1.2 ior did, then we should be fine if we negotiate codeset using giop 1.2 messages on a connection shared with giop 1.0. Practically speaking, (perhaps we need to make this formal), I think pretty much all "connection" state must be distinct for each giop version that might share the connection. In effect, each version has a separate session on the connection. It is hard to do otherwise because the state is defined for particular versions. It may however be necessary to decide if state established in v1.n is also valid in v1.n+1. (I propose that the answer be NO. The only state that need be shared between versions should be the existence of the connection.) Paul From: Paul Kyzivat To: "Interop RTF (E-mail)" Subject: RE: Absence of Wide Character Code Set Date: Tue, 25 Apr 2000 19:53:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: o=)e93U%!!Q'H!!*YC!! > From: Michi Henning [mailto:michi@ooc.com.au] > > There is a workaround for the server writer. Instead of > implementing the old > > keys, it can use new objects with some other keys. It can > then provide a > > servant manager that recognizes the old keys and returns a > LOCATION_FORWARD > > to the new ones. This isn't especially appealing, but it will work. > > Interesting thought, this technique didn't occur to me. Seems somewhat > roundabout though... I won't argue about that! We are being forced into roundabout solutions to lots of problems. > That's something we are still not sure about, I believe. It's > not clear > at what point the codeset information can be sent. For example, > there > may be 1.2 invocations that don't touch an operation with > wchar/wstring > parameters first. In that case, it's not clear whether the > codeset info > must be sent regardless, or whether it can be delayed until the > first > operation invocation that does require a codeset. That is a slightly different question. In this case, it would be sufficient to say that the codeset must be sent on the first message of the correct version that is capable of carrying it. It would however be convenient if this could be delayed further. An interesting question is BiDir giop (if we haven't given up entirely on it). Should separate codeset negotiations take place in the two directions? Or must the reverse flow requests follow the codesets selected for the forward direction? Paul Date: Wed, 26 Apr 2000 10:27:48 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: "Interop RTF (E-mail)" Subject: RE: Absence of Wide Character Code Set In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BE36@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ,+T!!@U_d9%:=!!ZC$"! On Tue, 25 Apr 2000, Paul Kyzivat wrote: > That is a slightly different question. > In this case, it would be sufficient to say that the codeset must be > sent on > the first message of the correct version that is capable of carrying > it. > > It would however be convenient if this could be delayed further. Most definitely. In particular, think of the DII. With the DII, the client-side doesn't know whether or not a particular interface will require codeset negotiation because there are no static stubs. If we don't permit the codeset to be established "late" (that is, with the first message that actually needs it), a DII client-side implementation has no choice but to establish codeset information unconditionally whenever the first request is sent, even if the corresponding interface doesn't use wide characters at all. Again, that seems like an awful waste. It would be better if the codeset could be established "just in time", with the first message that actually send characters. > An interesting question is BiDir giop (if we haven't given up entirely on > it). Tom mentioned that it would be deprecated at the Denver meeting. I'm not sure what that means though, or how we would do this in practice. How do you deprecate only part of version 1.2? By making version 1.3 without the deprecated bits? > Should separate codeset negotiations take place in the two directions? > Or must the reverse flow requests follow the codesets selected for the > forward direction? Who knows... :-( Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html To: Paul Kyzivat cc: "Interop RTF (E-mail)" Subject: Re: Absence of Wide Character Code Set In-Reply-To: Your message of "Tue, 25 Apr 2000 16:42:13 PDT." <9B164B713EE9D211B6DC0090273CEEA926BE35@bos1.noblenet.com> From: Bill Janssen Message-Id: <00Apr25.184927pdt."3438"@watson.parc.xerox.com> Date: Tue, 25 Apr 2000 18:49:39 PDT Content-Type: text X-UIDL: ;INd9)~Od9F->!!5@V!! > Practically speaking, (perhaps we need to make this formal), I think pretty > much all "connection" state must be distinct for each giop version that > might share the connection. At the very least. I'm not at all sure that even two logically different sessions using the same level of GIOP can share the same connection safely. But that would be the San Jose discussion... Bill Date: Thu, 27 Apr 2000 17:35:11 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Boldt Cc: issues@emerald.omg.org, orb_revision@emerald.omg.org Subject: Re: issue 3576 -- Core RTF issue References: <4.2.0.58.20000427153833.00bec7c0@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ;g3!!E/R!!KL;e9fc5!! I suspect this is Interop and not Core, but then again I may be wrong. For now give it to Interop please. Jishnu. Juergen Boldt wrote: > > This is issue # 3576 > > Absence of Wide Character Code Set > > CORBA is inconsistent on how to deal with the lack wide character code set > information in an IOR and the codes set service context. > > When a server receives a service context without a wide character code set > specified, then it is supposed to raise BAD_PARAM when it receives wide > characters data from the client. > > However a client is supposed to raise INV_OBJREF if the IOR is missing > from the server's native wchar code set . In CORBA 2.3, section13.7.2.6, > "Code Set Negotiation", it says, "... a server that supports interfaces > that > use wide character data is required to specify its native wchar code set; > if > one is not specified, then the client-side ORB raises exception > INV_OBJREF." > > This requires a client to know whether a server supports interfaces that > use > wide character data at the time the client receives an IOR. To determine > this when the first IOR is received is a burdensome task. The client orb > would be forced to apply an exhaustive examination, such scanning all of > the > server's IDL bindings or the contents of the IFR looking for wchar types. > Additionally the client may need to determine if some Any might flow > containing wchar data. > > I propose that the client's behavior be changed to match the server's. If > any wide character data is encountered and the server's IOR was missing > the native wchar code set, (which would cause the wide character > transmission > code set to not be negotiated), the client should raise BAD_PARAM. > > This will allow common marshal and demarshal code to be independent of > whether it is running as a client or server. It also allows users to not > configure > wide character code sets if they know they aren't using them. Date: Thu, 26 Oct 2000 17:11:06 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Boldt Cc: interop@omg.org Subject: Re: Interop New Millenia RTF Vote 6 has been posted References: <4.2.0.58.20001026161855.00ac0460@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: =B[d9KGMe9FH#e9;L^!! Juergen Boldt wrote: > > Hi all, > > The Interop New Millenia RTF Vote 6 has been posted at URLs > > http://cgi.omg.org/pub/interop/interopNMVote6.htm Tom, The resolution of issue 3576 needs to specify what standard minor code is used to signal the reason stated in the INV_OBJREF. Suggest that you editorially insert "with standard minor code xxx" in the text that you propose to insert in section 13.9.2.4. Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Date: Thu, 26 Oct 2000 15:57:44 -0700 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rutt, T E (Tom)" , interop@omg.org Subject: Re: interop NM RTF vote 6 announcement: Issue 3576 References: Content-Type: multipart/alternative; boundary="------------22D1A7FC185587FE8CDD5443" X-UIDL: "c`!!+!8!!i/e!!,m5!! Hi all, The resolution still does not explicitly cover other cases such as anys, constructed or templated types containing wchar or wstrings. Can we make a friendly amendment to the proposed text, to replace "which has wchar or wstring data specified" with "resulting in an attempt to marshal wchar or wstring data" in the first replacement text and "which has wchar or wstring as in, in/out" with "resulting in an attempt to marshal wchar or wstring data for in, in/out" in the second. Also, is there any reason for the phrases: "is appropriate to be raised" instead of "is raised" and "ORB may raise the INV_OBJREF" instead of "ORB shall raise" Thanks, Vijay "Rutt, T E (Tom)" wrote: Attached is vote 6 for interop NM rtf. It includes closing deferred "GIOP" wish list items As well as some (hopefully) non controversial proposed resulutions For new issues. The vote is due Friday ,Nov 3 at 5:00 PM Eastern Time Tom Rutt Terutt@lucent.com <> ter From: "Rutt, T E (Tom)" To: Juergen Boldt , "'Jishnu Mukerji'" Cc: interop@omg.org Subject: RE: Interop New Millenia RTF Vote 6 has been posted Date: Fri, 27 Oct 2000 16:31:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: j7~e9ic/e9UmNd9^h`d9 I agree that a minor code for "missing codeset component" is required. If you put that in your vote, we can make the change and send it out again for revote with that change on the next vote. ter ---------- From: Jishnu Mukerji [SMTP:jis@fpk.hp.com] Sent: Thursday, October 26, 2000 5:11 PM To: Juergen Boldt Cc: interop@omg.org Subject: Re: Interop New Millenia RTF Vote 6 has been posted Juergen Boldt wrote: > > Hi all, > > The Interop New Millenia RTF Vote 6 has been posted at URLs > > http://cgi.omg.org/pub/interop/interopNMVote6.htm Tom, The resolution of issue 3576 needs to specify what standard minor code is used to signal the reason stated in the INV_OBJREF. Suggest that you editorially insert "with standard minor code xxx" in the text that you propose to insert in section 13.9.2.4. Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Sender: "Vishy Kasar" Message-ID: <3A12CCC8.ED3CCB77@inprise.com> Date: Wed, 15 Nov 2000 09:50:00 -0800 From: Vishy Kasar Organization: Inprise Corporation - Visibroker Development X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: interop@omg.org Subject: Re: interop NM RTF vote 7 announcement: Issue 3576 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 1[C!![-A!!m7'e9Z~g!! I apologize for bringing this out at the voting time and not before. It would be ideal if both client and server throw the same exception BAD_PARAM with same minor code when handling almost the same situation of "trying to marshal wchar/wstring" without the codeset info from the peer. That would help ORB developers to use the common code both in client and server. I believe that was the original intention of the issue and also proposed by Mark Coats. However from the issue archive I do not see any further discussion on BAD_PARAM. Let me know if this there is any opposition to this and how we want to proceed on this. Outright reject of this proposal? Friendly amendment to also include BAD_PARAM from the client side in addition to INV_OBJREF? Another vote? -- Cheers! From: "Rutt, T E (Tom)" To: interop@omg.org, "'Vishy Kasar'" Subject: RE: interop NM RTF vote 7 announcement: Issue 3576 Date: Wed, 15 Nov 2000 20:21:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-UIDL: >KT!!NY""![cJe9;g3!! The IDL had a wstring or wchar in it in the first place, to BAD PARAM seems inappropriate. It is the object reference missing the codeset component which is causing the problem The client might be more confused than the orb implementor if it received one error by a "smart and dilligent non lazy evaluating" orb which does the check when receiving the IOR, and another error type from an orb which does it (quite legitimately) at run time when trying to send wstring data over the operation invocation. Thus, the current wording may be better for the client application. Tom Rutt ter ---------- From: Vishy Kasar [SMTP:vishy@inprise.com] Sent: Wednesday, November 15, 2000 12:50 PM To: interop@omg.org Subject: Re: interop NM RTF vote 7 announcement: Issue 3576 I apologize for bringing this out at the voting time and not before. It would be ideal if both client and server throw the same exception BAD_PARAM with same minor code when handling almost the same situation of "trying to marshal wchar/wstring" without the codeset info from the peer. That would help ORB developers to use the common code both in client and server. I believe that was the original intention of the issue and also proposed by Mark Coats. However from the issue archive I do not see any further discussion on BAD_PARAM. Let me know if this there is any opposition to this and how we want to proceed on this. Outright reject of this proposal? Friendly amendment to also include BAD_PARAM from the client side in addition to INV_OBJREF? Another vote? -- Cheers!