Issue 6050: 15.3.3 - codesets must be "explicitly defined" (corba-rtf) Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com) Nature: Uncategorized Issue Severity: Summary: For codesets in encapsulations we have: 15.3.3 - codesets must be "explicitly defined" Issue 4824 - "it is an error for a Service Context to depend on information that is not contained within the encapsulation to determine the codeset used within it" But in 13.8 there is no prescribed way of "explicitly defining" the codeset. Please, please can we simply define that the fallbacks in 13.10.2.6 apply everywhere that the codeset is not known (whether negotiated or not) and be done with it. Another alternative would be to add codeset parameters to the encode() and decode() functions of 13.8. Resolution: Revised Text: Actions taken: August 26, 2003: received issue April 11, 2012: Deferred Discussion: End of Annotations:===== X-Sender: andyp:san-francisco.beasys.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 26 Aug 2003 10:49:29 -0700 To: issues@omg.org, corba-rtf@omg.org From: Andy Piper Subject: More codeset and encapsulation issues. For codesets in encapsulations we have: 15.3.3 - codesets must be "explicitly defined" Issue 4824 - "it is an error for a Service Context to depend on information that is not contained within the encapsulation to determine the codeset used within it" But in 13.8 there is no prescribed way of "explicitly defining" the codeset. Please, please can we simply define that the fallbacks in 13.10.2.6 apply everywhere that the codeset is not known (whether negotiated or not) and be done with it. Another alternative would be to add codeset parameters to the encode() and decode() functions of 13.8. Thanks andy Date: Tue, 26 Aug 2003 15:53:21 -0400 From: Tom Rutt Reply-To: tom@coastin.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en To: Andy Piper CC: corba-rtf@omg.org Subject: Re: More codeset and encapsulation issues. Andy Piper wrote: For codesets in encapsulations we have: 15.3.3 - codesets must be "explicitly defined" Issue 4824 - "it is an error for a Service Context to depend on information that is not contained within the encapsulation to determine the codeset used within it" But in 13.8 there is no prescribed way of "explicitly defining" the codeset. The intent is to have it done in the textual description of the service context data content type. This would have to be hard coded with each service context, the intent of the RTF was to allow different codesets for different Service contexts. Tom Rutt past Interop RFT Chair Fujitsu Please, please can we simply define that the fallbacks in 13.10.2.6 apply everywhere that the codeset is not known (whether negotiated or not) and be done with it. Another alternative would be to add codeset parameters to the encode() and decode() functions of 13.8. Thanks andy -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 X-Sender: andyp:san-francisco.beasys.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 26 Aug 2003 16:49:24 -0700 To: tom@coastin.com From: Andy Piper Subject: Re: More codeset and encapsulation issues. Cc: corba-rtf@omg.org At 03:53 PM 8/26/2003 -0400, Tom Rutt wrote: For codesets in encapsulations we have: 15.3.3 - codesets must be "explicitly defined" Issue 4824 - "it is an error for a Service Context to depend on information that is not contained within the encapsulation to determine the codeset used within it" But in 13.8 there is no prescribed way of "explicitly defining" the codeset. The intent is to have it done in the textual description of the service context data content type. This would have to be hard coded with each service context, the intent of the RTF was to allow different codesets for different Service contexts. Understood, but there is no way to do this using the Codec APIs which are, as I understand it, primarily intended to manipulate service context data andy Date: Tue, 26 Aug 2003 20:20:23 -0400 From: Tom Rutt Reply-To: tom@coastin.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en To: Andy Piper CC: corba-rtf@omg.org Subject: Re: More codeset and encapsulation issues. Andy Piper wrote: At 03:53 PM 8/26/2003 -0400, Tom Rutt wrote: For codesets in encapsulations we have: 15.3.3 - codesets must be "explicitly defined" Issue 4824 - "it is an error for a Service Context to depend on information that is not contained within the encapsulation to determine the codeset used within it" But in 13.8 there is no prescribed way of "explicitly defining" the codeset. The intent is to have it done in the textual description of the service context data content type. This would have to be hard coded with each service context, the intent of the RTF was to allow different codesets for different Service contexts. Understood, but there is no way to do this using the Codec APIs which are, as I understand it, primarily intended to manipulate service context data Please explain this in greater detail. Tom Rutt andy -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 X-Sender: andyp:san-francisco.beasys.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 26 Aug 2003 20:08:24 -0700 To: tom@coastin.com From: Andy Piper Subject: Re: More codeset and encapsulation issues. Cc: corba-rtf@omg.org At 03:53 PM 8/26/2003 -0400, Tom Rutt wrote: For codesets in encapsulations we have: 15.3.3 - codesets must be "explicitly defined" Issue 4824 - "it is an error for a Service Context to depend on information that is not contained within the encapsulation to determine the codeset used within it" But in 13.8 there is no prescribed way of "explicitly defining" the codeset. I wish to encode a ServiceContext via a PortableInterceptor. The way I do it is with Codec.encode(). My ServiceContext needs to contain wchar data, what codeset is used for that data? There is no way to tell the Codec, the ServiceContext is not allowed to reference the negotiated codeset, so we fall back on that defined for encapsulations - i.e. error! The JDK ORB - reasonably I think - picks default codesets of UTF-8/UTF-18 for GIOP 1.2 Codecs, but this is not implied by the spec and there is no way from a user perspective to select anything else. andy Date: Wed, 27 Aug 2003 11:00:40 -0400 From: Jishnu Mukerji Organization: Software Business Unit, Hewlett-Packard User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Andy Piper Cc: tom@coastin.com, corba-rtf@omg.org Subject: Re: More codeset and encapsulation issues. Andy Piper wrote: At 03:53 PM 8/26/2003 -0400, Tom Rutt wrote: For codesets in encapsulations we have: 15.3.3 - codesets must be "explicitly defined" Issue 4824 - "it is an error for a Service Context to depend on information that is not contained within the encapsulation to determine the codeset used within it" But in 13.8 there is no prescribed way of "explicitly defining" the codeset. I wish to encode a ServiceContext via a PortableInterceptor. The way I do it is with Codec.encode(). My ServiceContext needs to contain wchar data, what codeset is used for that data? There is no way to tell the Codec, the ServiceContext is not allowed to reference the negotiated codeset, so we fall back on that defined for encapsulations - i.e. error! The JDK ORB - reasonably I think - picks default codesets of UTF-8/UTF-18 for GIOP 1.2 Codecs, but this is not implied by the spec and there is no way from a user perspective to select anything else. andy It looks like the best way to fix this one needs to do two things: 1. Specify that for Codecs created via the CodecFactory::create_codec operation the codeset used shall be the default codeset of the ORB implementation. And that the default codeset for the ORB implementation, unless documented explicitly by the ORB implementation to be something else, shall be UTF-8/UTF-8 for GIOP 1.2 (thus making the common use case the default that applies unless it is documented to be something else). 2. Enhance the CodecFactory interface with an additional operation - something like create_codec_with_codeset, which takes an additional parameter specifying the codeset, perhaps of type CONV_FRAME::CodeSetContext for the Codec that is created. Then this operation can be used for creating codecs for specific codesets. Of course an ORB should be allowed to not support a specific codeset if it so desires, in which case it should be able to return a new exception UnsupportedCodeset or some such. Thoughts? Comments? Jishnu. -- Jishnu Mukerji Senior Systems Architect 1001 Frontier Road, Suite 300 Strategy & Technology Office Bridgewater NJ 08807, USA Software Business Unit Tel: +1 908 243 8924 Hewlett-Packard Company Fax: +1 908 243 8850 mailto: jishnu@hp.com X-Sender: andyp:san-francisco.beasys.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 27 Aug 2003 09:12:54 -0700 To: Jishnu Mukerji From: Andy Piper Subject: Re: More codeset and encapsulation issues. Cc: tom@coastin.com, corba-rtf@omg.org At 11:00 AM 8/27/2003 -0400, Jishnu Mukerji wrote: 1. Specify that for Codecs created via the CodecFactory::create_codec operation the codeset used shall be the default codeset of the ORB implementation. And that the default codeset for the ORB implementation, unless documented explicitly by the ORB implementation to be something else, shall be UTF-8/UTF-8 for GIOP 1.2 (thus making the common use case the default that applies unless it is documented to be something else). Sounds good. I don't understand why UTF-8 should be the implicit codeset for wchar, when for negotiation fallbacks it is UTF-16. Is there something I'm missing? 2. Enhance the CodecFactory interface with an additional operation - something like create_codec_with_codeset, which takes an additional parameter specifying the codeset, perhaps of type CONV_FRAME::CodeSetContext for the Codec that is created. Then this operation can be used for creating codecs for specific codesets. Of course an ORB should be allowed to not support a specific codeset if it so desires, in which case it should be able to return a new exception UnsupportedCodeset or some such. Gets my vote, and I might be able to persuade BEA :) What I would really like to see in addition is create_codec_with_negotiated_codeset(), but I know you're never going to allow me that :) And while I'm dreaming an encapsulation with the codeset encoded inside it would be nice to. andy X-Authentication-Warning: greene.case.syr.edu: polar owned process doing -bs Date: Wed, 27 Aug 2003 12:33:31 -0400 (EDT) From: Polar Humenn X-X-Sender: polar@greene.case.syr.edu To: Andy Piper cc: Jishnu Mukerji , , Subject: Re: More codeset and encapsulation issues. On Wed, 27 Aug 2003, Andy Piper wrote: [snip] > > What I would really like to see in addition is > create_codec_with_negotiated_codeset(), but I know you're never going to > allow me that :) And while I'm dreaming an encapsulation with the codeset > encoded inside it would be nice to. How can you do that anyway? When you create the codec, you don't know the channel on which you will send any of its encodings. -Polar > andy > -- ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Wed, 27 Aug 2003 13:55:57 -0400 From: Jishnu Mukerji Organization: Software Business Unit, Hewlett-Packard User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Andy Piper Cc: tom@coastin.com, corba-rtf@omg.org Subject: Re: More codeset and encapsulation issues. Andy Piper wrote: At 11:00 AM 8/27/2003 -0400, Jishnu Mukerji wrote: 1. Specify that for Codecs created via the CodecFactory::create_codec operation the codeset used shall be the default codeset of the ORB implementation. And that the default codeset for the ORB implementation, unless documented explicitly by the ORB implementation to be something else, shall be UTF-8/UTF-8 for GIOP 1.2 (thus making the common use case the default that applies unless it is documented to be something else). Sounds good. I don't understand why UTF-8 should be the implicit codeset for wchar, when for negotiation fallbacks it is UTF-16. Is there something I'm missing? It is the comedy of mistypings of the finger on keyboard kind. You ahd said UTF-8/UTF-18(!!) in your message and I somehow managed to change it to UTF-8/UTF-8:-( UTF-8/UTF-16 it should be, I agree. 2. Enhance the CodecFactory interface with an additional operation - something like create_codec_with_codeset, which takes an additional parameter specifying the codeset, perhaps of type CONV_FRAME::CodeSetContext for the Codec that is created. Then this operation can be used for creating codecs for specific codesets. Of course an ORB should be allowed to not support a specific codeset if it so desires, in which case it should be able to return a new exception UnsupportedCodeset or some such. Gets my vote, and I might be able to persuade BEA :) What I would really like to see in addition is create_codec_with_negotiated_codeset(), but I know you're never going to allow me that :) We might consider it if you could tell me exactly how the approriate context with which a negotiated codeset is associated is established at the time that the create_codec..... operation is invoked, and how do you ensure that the codec will be invoked in a context that has the same codeset associated with it. In short, I don't understand the use case. And while I'm dreaming an encapsulation with the codeset encoded inside it would be nice to. You mean like in the header of the encapsulation? Jishnu. X-Sender: andyp:san-francisco.beasys.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 27 Aug 2003 11:01:53 -0700 To: Jishnu Mukerji From: Andy Piper Subject: Re: More codeset and encapsulation issues. Cc: tom@coastin.com, corba-rtf@omg.org At 01:55 PM 8/27/2003 -0400, Jishnu Mukerji wrote: It is the comedy of mistypings of the finger on keyboard kind. You ahd said UTF-8/UTF-18(!!) in your message and I somehow managed to change it to UTF-8/UTF-8:-( UTF-8/UTF-16 it should be, I agree. Yikes. The irony is that I would prefer UTF-8 to be the fallback for wchar - but its too late for that. What I would really like to see in addition is create_codec_with_negotiated_codeset(), but I know you're never going to allow me that :) We might consider it if you could tell me exactly how the approriate context with which a negotiated codeset is associated is established at the time that the create_codec..... operation is invoked, and how do you ensure that the codec will be invoked in a context that has the same codeset associated with it. In short, I don't understand the use case. I'm just dreaming, the issues are probably too fundamental to solve. You mean like in the header of the encapsulation? Right. You could imagine overloading the endian flag something like: [long][0][ data ] - little endian data, predefined codeset [long][1][ data ] - big endian data, predefined codeset [long][2][ endian ][ char cs][ wchar cs ][ data ] - cs in encapsulation [long][3][ data ] - all properties inherited from enclosing scope This is not a particularly serious suggestion, but I'm not particularly enamored with some of the properties of encapsulations today. andy X-Sender: andyp:san-francisco.beasys.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 27 Aug 2003 11:40:35 -0700 To: Jishnu Mukerji From: Andy Piper Subject: Re: More codeset and encapsulation issues. Cc: tom@coastin.com, corba-rtf@omg.org We might consider it if you could tell me exactly how the approriate context with which a negotiated codeset is associated is established at the time that the create_codec..... operation is invoked, and how do you ensure that the codec will be invoked in a context that has the same codeset associated with it. In short, I don't understand the use case. Actually, probably what would need to happen is to augment the PI RequestInfo object to give access to connection-level information - such as the negotiated codeset - this could then be used with the new Codec.encode_...() function. Interestingly the JDK ORB already does this to give you access to the socket (which IMO is a good thing also). The other piece of information you would probably want there is the codebase. andy X-Authentication-Warning: greene.case.syr.edu: polar owned process doing -bs Date: Wed, 27 Aug 2003 15:17:09 -0400 (EDT) From: Polar Humenn X-X-Sender: polar@greene.case.syr.edu To: Andy Piper cc: Jishnu Mukerji , , Subject: Re: More codeset and encapsulation issues. On Wed, 27 Aug 2003, Andy Piper wrote: > > >>We might consider it if you could tell me exactly how the approriate > >>context with which a negotiated codeset is associated is established at > >>the time that the create_codec..... operation is invoked, and how do you > >>ensure that the codec will be invoked in a context that has the same > >>codeset associated with it. In short, I don't understand the use case. > > Actually, probably what would need to happen is to augment the PI > RequestInfo object to give access to connection-level information - such as > the negotiated codeset - this could then be used with the new > Codec.encode_...() function. In general, and in some implementations I have seen, on the client side, there may not even be a connection set up at this point let alone the negotiation of codeset or codebase. > Interestingly the JDK ORB already does this to give you access to the > socket (which IMO is a good thing also). That's just one particular implementation. Some might not even use sockets. Cheers, -Polar > The other piece of information you would probably want there is the > codebase. > andy > -- ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Sender: andyp:san-francisco.beasys.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 27 Aug 2003 12:20:42 -0700 To: Polar Humenn From: Andy Piper Subject: Re: More codeset and encapsulation issues. Cc: Jishnu Mukerji , , At 03:17 PM 8/27/2003 -0400, Polar Humenn wrote: > Actually, probably what would need to happen is to augment the PI > RequestInfo object to give access to connection-level information - such as > the negotiated codeset - this could then be used with the new > Codec.encode_...() function. In general, and in some implementations I have seen, on the client side, there may not even be a connection set up at this point let alone the negotiation of codeset or codebase. Sure, so you wouldn't be able to access this information at that point (or else you would get returned the ORB defaults). Nothing wrong with that. > Interestingly the JDK ORB already does this to give you access to the > socket (which IMO is a good thing also). That's just one particular implementation. Some might not even use sockets. I, personally, am weary of this argument. IMO most do, and the minority use-cases inhibit the majority from doing useful stuff. If we follow this argument to its conclusion IIOP would not exist, and yet without it CORBA would have been dead long ago. andy Date: Wed, 27 Aug 2003 15:29:52 -0400 From: Tom Rutt Reply-To: tom@coastin.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en To: Jishnu Mukerji CC: Andy Piper , corba-rtf@omg.org Subject: Re: More codeset and encapsulation issues. Jishnu Mukerji wrote: Andy Piper wrote: At 03:53 PM 8/26/2003 -0400, Tom Rutt wrote: For codesets in encapsulations we have: 15.3.3 - codesets must be "explicitly defined" Issue 4824 - "it is an error for a Service Context to depend on information that is not contained within the encapsulation to determine the codeset used within it" But in 13.8 there is no prescribed way of "explicitly defining" the codeset. I wish to encode a ServiceContext via a PortableInterceptor. The way I do it is with Codec.encode(). My ServiceContext needs to contain wchar data, what codeset is used for that data? There is no way to tell the Codec, the ServiceContext is not allowed to reference the negotiated codeset, so we fall back on that defined for encapsulations - i.e. error! The JDK ORB - reasonably I think - picks default codesets of UTF-8/UTF-18 for GIOP 1.2 Codecs, but this is not implied by the spec and there is no way from a user perspective to select anything else. andy It looks like the best way to fix this one needs to do two things: 1. Specify that for Codecs created via the CodecFactory::create_codec operation the codeset used shall be the default codeset of the ORB implementation. And that the default codeset for the ORB implementation, unless documented explicitly by the ORB implementation to be something else, shall be UTF-8/UTF-8 for GIOP 1.2 (thus making the common use case the default that applies unless it is documented to be something else). 2. Enhance the CodecFactory interface with an additional operation - something like create_codec_with_codeset, which takes an additional parameter specifying the codeset, perhaps of type CONV_FRAME::CodeSetContext for the Codec that is created. Then this operation can be used for creating codecs for specific codesets. Of course an ORB should be allowed to not support a specific codeset if it so desires, in which case it should be able to return a new exception UnsupportedCodeset or some such. Thoughts? Comments? I like this approach. Tom Rutt Jishnu. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Date: Wed, 27 Aug 2003 13:02:26 -0700 From: Jon Biggar User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en To: Polar Humenn , corba-rtf@omg.org Subject: Re: More codeset and encapsulation issues. Polar Humenn wrote: On Wed, 27 Aug 2003, Andy Piper wrote: Actually, probably what would need to happen is to augment the PI RequestInfo object to give access to connection-level information - such as the negotiated codeset - this could then be used with the new Codec.encode_...() function. In general, and in some implementations I have seen, on the client side, there may not even be a connection set up at this point let alone the negotiation of codeset or codebase. IMO, the semantics of the send_request() interception point *require* that the connection be set up before it is called. Otherwise it is impossible to implement ClientRequestInfo functionality like effective_profile() or get_effective_component() or get_request_policy(). -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Authentication-Warning: greene.case.syr.edu: polar owned process doing -bs Date: Wed, 27 Aug 2003 17:17:23 -0400 (EDT) From: Polar Humenn X-X-Sender: polar@greene.case.syr.edu To: Jon Biggar cc: corba-rtf@omg.org Subject: Re: More codeset and encapsulation issues. On Wed, 27 Aug 2003, Jon Biggar wrote: > Polar Humenn wrote: > > On Wed, 27 Aug 2003, Andy Piper wrote: > > >>Actually, probably what would need to happen is to augment the PI > >>RequestInfo object to give access to connection-level information - such as > >>the negotiated codeset - this could then be used with the new > >>Codec.encode_...() function. > > > > > > In general, and in some implementations I have seen, on the client side, > > there may not even be a connection set up at this point let alone the > > negotiation of codeset or codebase. > > IMO, the semantics of the send_request() interception point *require* > that the connection be set up before it is called. Otherwise it is > impossible to implement ClientRequestInfo functionality like > effective_profile() or get_effective_component() or get_request_policy(). If that were the case, then no request could be intercepted before the connection was set up. Then a security interceptor would not be able to stop a connection being made that it may not want to allow. I know, its 50/50 on both sides of that argument. Also, as far as get_effective_component(s), connection set up or not, nothing guarantees that just because you selected an 1 effective component from multiple different ones, such as codesets, doesn't mean that any negotiation had to be set up prior to that request, i.e. the first on on the channel, and its interception. The effective profile and components, may be the only one(s) your ORB happens to allow, without anything happening connectionwise or negotiationwise. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Sender: andyp:san-francisco.beasys.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Sep 2003 08:25:49 -0700 To: Jishnu Mukerji From: Andy Piper Subject: Re: More codeset and encapsulation issues. Cc: tom@coastin.com, corba-rtf@omg.org Ok, so here's an attempt at a proposal to fix this: 13.8.2 After the definition of Encoding add: exception UnsupportedCodeset { CONV_FRAME::CodeSetId codeset; }; struct Encoding_1_2 { EncodingFormat format; octet major_version; octet minor_version; CONV_FRAME::CodeSetId char_codeset; CONV_FRAME::CodeSetId wchar_codeset; }; To CodecFactory add: Codec create_codec_with_codesets (in Encoding_1_2 enc) raises (UnknownEncoding, UnsupportedCodeset); 13.8.2.2 - after, "Create a Codec of the given encoding." add: "Unless otherwise specified, the codesets used by the encoding shall be the default codesets of the ORB implementation. The default codesets of the ORB implementation, unless documented explicitly by the ORB implementation to be something else, shall be UTF-8 for char data and UTF-16 for wchar data." add the section: "create_codec_with_codesets Create a Codec of the given encoding using the specified codesets. This operation raises UnknownEncoding if this factory cannot create a Codec of the given encoding. This operation raises UnsupportedCodeset if the ORB cannot support one or both of the specified codesets. Parameter enc The Encoding_1_2 for which to create a Codec. Return Value A Codec obtained with the given encoding. Date: Wed, 10 Sep 2003 10:59:08 -0700 From: Jon Biggar User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en To: Andy Piper CC: Jishnu Mukerji , tom@coastin.com, corba-rtf@omg.org Subject: Re: More codeset and encapsulation issues. Andy Piper wrote: Ok, so here's an attempt at a proposal to fix this: [snip] Looks good to me. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org