Issue 8244: Code Set Conversion on Operations (corba-rtf) Source: Motorola (Mr. Gary Duzan, gary.duzan(at)motorola.com) Nature: Uncategorized Issue Severity: Summary: The "operation" field in the RequestHeader_1_2 struct is a string, which implies that it should be subject to code set conversion. However, existing practice seem to be that it is not converted, and there are other factors which could make it difficult for implementations to convert it. In addition, since the operation name is based on IDL/ASCII, conversion doesn't necessarily make sense. The easiest remedy would be to specify this as an exception in the text of the spec. The "correct" remedy would probably be to change the operation field from "string" to "sequence<octet>". This could cause problems at some point, but it might not break too much since the CDR encodings are the same. Resolution: Revised Text: Actions taken: February 7, 2005: received issue April 11, 2012: Deferred Discussion: End of Annotations:===== uthentication-Warning: toulouse.bbn.com: gduzan owned process doing -bs To: issues@omg.org Cc: devo-group@list.isis.vanderbilt.edu Subject: Code Set Conversion on Operations Date: Mon, 07 Feb 2005 12:03:49 -0500 From: Gary Duzan The "operation" field in the RequestHeader_1_2 struct is a string, which implies that it should be subject to code set conversion. However, existing practice seem to be that it is not converted, and there are other factors which could make it difficult for implementations to convert it. In addition, since the operation name is based on IDL/ASCII, conversion doesn't necessarily make sense. The easiest remedy would be to specify this as an exception in the text of the spec. The "correct" remedy would probably be to change the operation field from "string" to "sequence". This could cause problems at some point, but it might not break too much since the CDR encodings are the same. Gary Duzan BBN Technologies Date: Mon, 07 Feb 2005 09:12:16 -0800 From: Jonathan Biggar Organization: LinuxCare User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308 X-Accept-Language: en-us, en To: Gary Duzan CC: issues@omg.org, corba-rtf@omg.org Subject: Re: Code Set Conversion on Operations Gary Duzan wrote: The "operation" field in the RequestHeader_1_2 struct is a string, which implies that it should be subject to code set conversion. However, existing practice seem to be that it is not converted, and there are other factors which could make it difficult for implementations to convert it. In addition, since the operation name is based on IDL/ASCII, conversion doesn't necessarily make sense. Codeset conversion *only* applies to the body of Request & Reply messages, not the header. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Authentication-Warning: toulouse.bbn.com: gduzan owned process doing -bs To: Jonathan Biggar Cc: issues@omg.org, corba-rtf@omg.org Subject: Re: Code Set Conversion on Operations Date: Mon, 07 Feb 2005 13:14:01 -0500 From: Gary Duzan In Message <4207A170.6040904@floorboard.com> , Jonathan Biggar wrote: =>Gary Duzan wrote: =>> The "operation" field in the RequestHeader_1_2 struct is a string, =>> which implies that it should be subject to code set conversion. However, =>> existing practice seem to be that it is not converted, and there are other =>> factors which could make it difficult for implementations to convert it. =>> In addition, since the operation name is based on IDL/ASCII, conversion =>> doesn't necessarily make sense. => =>Codeset conversion *only* applies to the body of Request & Reply =>messages, not the header. I understand that is the practice, but I am not seeing where it is stated in the spec. There is plenty of text in 13.10 about the conversion process, and text about the per-connection negotiation, but as far as where the conversion applies, I only see references to (w)char and (w)string data. Section 15.3.1.6 binds that to the CDR Transfer Syntax, but that applies to both the header and body parts of the message. Section 15.4 doesn't say anything about code sets at the GIOP level. I agree that we really don't want to change existing ORB behavior, but it would be preferable to have the spec reflect existing practice explicitly, either by special casing CDR encoding for the various message headers or by switching to octet sequences to explicitly disallow the conversion. Gary Duzan BBN Technologies