Issue 2708: Which codeset is used in CDR encoding (interop) (sec-rev) Source: University of California, Irvine (Mr. Carlos O'Ryan, nobody) Nature: Clarification Severity: Minor Summary: Minor full_desc: The 2.2 spec states: "The hexadecimal strings are generated by first turning an object reference into an IOR, and then encapsulating the IOR using the encoding rules of CDR." but it does not state which codeset is used in that CDR encoding, since IIOP profiles contain strings (the hostname) the choice of codeset is crucial for interoperability Though most implementors will probably use ASCII (UTF8) for that encoding a clarification seems to be required. Resolution: to Close with agreed change Revised Text: add the following text to the definition of encapsulation in 15.3.3 " Whenever the use of an ecapsulation is specified, the GIOP version to use for encoding the encapsulation, if different than GIOP version 1.0, must be explcitly defined (i.e., the default is GIOP 1.0). If a parameter with IDL char or string type is defined to be carried in an encapsulation using GIOP version greater than 1.0, the transmission Code Set for characters (TCS-C), to be used when encoding the encapsulation, shall also be explcitly defined. Actions taken: June 8, 1999: received issue October 4, 2000: Approved by Vote 1 issue closed October 4, 2000: closed issue Discussion: This is closely related to issues 2784 (which describes the same problems pertaining to Wide Strings in IDL encapsulations) and superceded Issue 2457 (which was also concerned with the encoding of strings in GIOP headers and TypeCodes) Since GIOP headers and Type codes may only include Latin-1 strings (Type code names originate from IDL indentifiers, and no Giop header strings have beed defined to carry anything beyond Latin-1) issue 2457 was closed, with its remaining issue already encompassed in this issue 2708. There have been no standard IOR components or Service contexts defined to use any GIOP version other than 1.0. Thus the only way internationalized strings can appear in IORs is through non-standard IOR components or service contexts. The only way to guarantee interoperability for such encapsulations is to declare a default codeSet for use with strings in encapsulations, when the use of that encapsulation is defined. Whenever the use of an Encapsulations is defined for placement in an Octet Sequence (e.g., IOR component or service context definition) , Giop version 1.0 is assumed for the encoding, unless the definition explicitly states otherwise. If the syntax for an encapsulation is defined to be encoded using GIOP versions 1.1 or higher and includes parameters of type string (or wstring), that definition is required During the vote it was clarified that this pertains to char or string types. End of Annotations:===== From: "Rutt, T E (Tom)" To: "'interop@omg.org'" Subject: Interop issue resolution proposal discussions Date: Mon, 6 Dec 1999 11:09:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Ch"e9W_ld9Xm