Issue 3861: module name used for PMF should comply with the OMG IDL Style Guide (partyman-fac-rtf) Source: Gazebo Software Solutions (Ms. Amy Griffis, ) Nature: Uncategorized Issue Severity: Summary: The module name used for PMF should comply with the OMG IDL Style guide. "Df" should be used as a prefix to be recognized as a domain facility. Resolution: Revised Text: Actions taken: September 18, 2000: received issue Discussion: End of Annotations:===== From: "Amy Griffis" To: Cc: Subject: Issue to be added to PMF RTF 3 Date: Mon, 18 Sep 2000 15:50:46 -0700 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal X-MS-TNEF-Correlator: Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_01C02188.35791350" X-UIDL: $c)e9]m'!!]^:e9F"'e9 New issue for PMF... Severity: minor Summary: The module name used for PMF should comply with the OMG IDL Style guide. "Df" should be used as a prefix to be recognized as a domain facility. [] winmail1.dat From: "Rutt, T E (Tom)" To: "'interop@omg.org'" Cc: "Rutt, T E (Tom)" Subject: wordsmithing issue 3861 proposed resolution Date: Tue, 7 Nov 2000 13:29:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: :=$!!flJe9TIKe9B[7!! Please review this proposed resolution. If I have no comments before Friday noon, I will put it out for vote of interop rtf. Tom Rutt -------- Issue 3681: interop issue: CodeSets service context in GIOP 1.0 request (interop) Click here for this issue's archive. Source: Xerox (Mr. William C. Janssen, Jr., janssen@parc.xerox.com) Nature: Uncategorized Issue Severity: Summary: Well, a new Java release is upon us, and with it comes a new CORBA implementation. I'm trying Java 2 SE 1.3 CORBA clients against an ILU 2.0beta1 CosNaming server, and we find that the Java ORB cannot reliably connect to the server. Why not? First, we must analyze the IOR provided by the ILU service: IOR:000000000000002849444C3A6F6D672E6F72672F436F734E616D696E672F4E616 D696E67436F6E746578743A312E300000000002000000000000002F00010000000000 16776174736F6E2E706172632E7865726F782E636F6D00270F0000000B4E616D65536 572766963650000000001000000240001000000000001000000010000001400010018 00010001000000000001010000000000 If we look at this (those who've received it un-truncated) we find that it advertises the following: _IIOP_ParseCDR: byte order BigEndian, repository id , 2 profiles _IIOP_ParseCDR: profile 1 is 47 bytes, tag 0 (INTERNET), BigEndian byte order _IIOP_ParseCDR: profile 2 is 36 bytes, tag 1 (MULTIPLE COMPONENT), BigEndian byte order (iiop.c:parse_IIOP_Profile): bo=BigEndian, version=1.0, hostname=watson.parc.xerox.com, port=9999, object_key= (iiop.c:parse_IIOP_Profile): encoded object key is (iiop.c:parse_IIOP_Profile): non-native cinfo is (iiop.c:parse_MultiComponent_Profile): profile contains 1 component (iiop.c:parse_MultiComponent_Profile): component 1 of type 1, 20 bytes (iiop.c:parse_MultiComponent_Profile): native codeset for SHORT CHARACTER is 00010001, with 0 converters (iiop.c:parse_MultiComponent_Profile): native codeset for CHARACTER is 00010100, with 0 converters That is, there's a vanilla Internet profile (bo=BigEndian, version=1.0, hostname=watson.parc.xerox.com, port=9999, object_key=), plus a Multicomponent profile, noting that the ILU ORB's native codesets are Latin-1 and UCS-2. OK, great. Now we get the first message from the Java ORB: 0000 47 49 4f 50 01 00 00 00 00 00 01 00 GIOP........ 0000 00 00 00 02 00 00 00 01 00 00 00 0c 00 00 00 00 ................ 0010 00 01 00 20 00 01 01 00 00 00 00 06 00 00 00 90 ... ............ 0020 00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e .......(IDL:omg. 0030 6f 72 67 2f 53 65 6e 64 69 6e 67 43 6f 6e 74 65 org/SendingConte 0040 78 74 2f 43 6f 64 65 42 61 73 65 3a 31 2e 30 00 xt/CodeBase:1.0. 0050 00 00 00 01 00 00 00 00 00 00 00 54 00 01 01 00 ...........T.... 0060 00 00 00 0c 31 33 2e 31 2e 31 30 33 2e 36 38 00 ....13.1.103.68. 0070 0e e9 00 00 00 00 00 18 af ab ca fe 00 00 00 02 ................ 0080 67 d5 93 95 00 00 00 08 00 00 00 00 00 00 00 00 g............... 0090 00 00 00 01 00 00 00 01 00 00 00 14 00 00 00 00 ................ 00a0 00 01 00 20 00 00 00 00 00 01 01 00 00 00 00 00 ... ............ 00b0 00 00 00 05 01 00 00 00 00 00 00 07 53 79 6e 65 ............Syne 00c0 72 67 79 00 00 00 00 06 5f 69 73 5f 61 00 00 00 rgy....._is_a... 00d0 00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e .......(IDL:omg. 00e0 6f 72 67 2f 43 6f 73 4e 61 6d 69 6e 67 2f 4e 61 org/CosNaming/Na 00f0 6d 69 6e 67 43 6f 6e 74 65 78 74 3a 31 2e 30 00 mingContext:1.0. Note that we are seeing a CodeSets service context, even though the request is GIOP 1.0. The service context specifies a TCS-C of ASCII, and a TCS-W of UCS-2. The question is, what should the server do with it? First of all, there seems to be no way in which the algorithm in section 13.2.7.6 can result in the TCS-C specified in the service context. So perhaps this bug should be detected and signalled back to the sending ORB. How? Using CODESET_INCOMPATIBLE might make sense, but that really doesn't flag the bug in the client-side implementation of the codesets determination algorithm. Perhaps a straight COMM_FAILURE would be better. Opinions? Secondly, since this is GIOP 1.0, the client could reasonably ignore the service context, and go ahead with using its default codeset (Latin-1). However, to do so risks comm failure down the line, as ASCII (the TCS-C assumed by the client) does not permit many Latin-1 characters. It seems better to flag this situation up front. Discussion: The IOR does not have the codeset component in the INTEROP IOR Profile. A client may choose to ignore the MULTIPLE COMPONENTS profile safely. The Interop chapters require profiles to be complete, the MULTIPLE COMPONENTS profile is not complete, since it has no addressing information or object key. The server should not process codeset service context in GIOP 1.0, if present. If client sends other than LATIN-1 in GIOP 1.0, errors may arise. They should be dealt with in the response to each request message, rather than in the processing of the service context in the first message.. We need to clarify what is valid within the GIOP protocol for the server to do in this situation. The client should not be including a codeset service context in a GIOP 1.0 message, and certainly cannot transmit any wide characters or strings over a GIOP 1.0 connection. The codeset service context might be considered harmless if its TCS-C matched the fixed codeset used in GIOP 1.0 for chars and strings. The client is wrong to send the service context in this case of GIOP 1.0, (irrespective of its contents). 13.7.2 of Core states: " The following are the rules for processing a received service context: * The service context is in the OMG defined range: * If it is valid for the supported GIOP version, then it must be processed correctly according to the rules associated with it for that GIOP version level. * If it is not valid for the GIOP version, then it may be ignored by the receiving ORB, however it must be passed on through a bridge and must be made available to interceptors. No exception shall be raised. " Based on the above quote, the server is also wrong to look at it. If the client "pumps" ascii over the connection, the server will have no problems, since ascii is a subset of Latin-1. However, the server might "pump back" string return results or out parameters using the fully extended 8 bit space of Latin-1, and the client has to deal with it. We also need to use the propose/dispose mechanism that has been setup between Sun and the OMG provide for feeding back bug reports to Sun and having them run it through a Java standards process moral equivalent of OMG's "Urgent bugfix process"? That also needs to happen to fix this particular problem.. Resolution: Section 13.7.2 makes it very clear that the server should not raise an exception if a codeset service context is contained in a GIOP 1.0 request message. No clarification is needed in that section. If a client or a server sends character data which is not encoded as LATIN-1, the receiver will not be able to detect it is not being LATIN-1 by examining the received sequence octets. Thus nothing can be stated for this case. However, if an operation with Wchar parameter data is sent over GIOP 1.0 by a client, the server must generate a "BAD PARAM" exception. We need minor code for this case. If a server sends Wchar or wstring data using GIOP 1.0 the client should close the connection. Proposed Revised Text: At the end of section 15.3.1.6 add the following: " If a client sends wchar data in a GIOP 1.0 message, the server shall generate a BAD_PARAM standard system exception, with standard minor code 25+i. If a server sends wchar data in a GIOP 1.0 response, the client shall close the connection. " Add the following minor code to table 4-3 for BAD_PARAM Standard System exception: " BAD_PARAM 25+i wchar or wstring data not allowed in GIOP 1.0 message " Actions taken: July 5, 2000: received issue