Issue 4200: Module SSLIOP Does Not Contain Host (csiv2-ftf) Source: Mansurus LLC (Mr. Donald Flinn, flinn(at)alum.mit.edu) Nature: Uncategorized Issue Severity: Critical Summary: In some situations, e.g. a multi-homed system, there would have to be a profile for each port number supported by SSL. This is inefficient. Adding a String host_name to the struct SSL in the Module SSLIOP would resolve this issue. Resolution: Close issue with revised text. Revised Text: Base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] Add Minor Heading Section before TAG_TLS_SEC_TRANS Transport Address The TransportAddress structure indicates an INTERNET address where the TSS is listening for connection requests. struct TransportAddress { string host_name; unsigned short port; }; typedef sequence <TransportAddress> TransportAddressList; The host_name field identifies the Internet host to which connection requests will be made. The host_name field shall not contain an empty string. The port field contains the TCP/IP port number (at the specified host) where the TSS is listening for connection requests. The port number shall not be zero. [2] Replace paragraph 130 with the following: When an instance of the TAG_TLS_SEC_TRANS component occurs in the transport_mech field of the CompoundSecMech structure, it defines the sequence of transport addresses that the target will be listening for SSL/TLS protected invocations. The supported (target_supports) and required (target_requires) association options defined in the component shall define the transport level security characteristics of the target at the given addresses. [3] Change the IDL for TLS_SEC_TRANS after paragraph 130 to the following: struct TLS_SEC_TRANS { AssociationOptions target_supports; AssociationOptions target_requires; TransportAddressList addresses; }; [4] Add the following paragraph following the IDL after paragraph 130: The addresses field provides a shorthand for defining multiple security mechanisms that differ only in their transport addresses. The addresses field shall contain at least one address. [5] Add the following IDL for TransportAddress 16.9.4 on page 16-65 after the definition of CompoundSecMechList: struct TransportAddress { string host_name; unsigned short port; }; typedef sequence <TransportAddress> TransportAddressList; [6] Change the IDL for TLS_SEC_TRANS in section 16.9.4 on page 16-66 to the following: struct TLS_SEC_TRANS { AssociationOptions target_supports; AssociationOptions target_requires; TransportAddressList addresses; }; Actions taken: February 12, 2001: received issue October 3, 2001: closed issue Discussion: We add a minor section describing a TransportAddress structure with wording close to that of the IIOP profile on page 15-50 of CORBA 2.3. formal/99-10-07. We also add a typedef for a sequence of these structures. We change the TLS_SEC_TRANS structure to use a list of these addresses. End of Annotations:===== Issue XXXX: Module SSLIOP Does Not Contain Host Click here for this issue's archive. Source: Iona Technologies (Don Flinn, don.flinn@iona.com) Document: http://cgi.omg.org/cgi-bin/doc?orbos/2000-08-04 Nature: Uncategorized Issue Severity: Critical Summary: The Module SSLIOP does not contain the host name. Discussion: In some situations, e.g. a multi-homed system, there would have to be a profile for each port number supported by SSL. This is inefficient. Adding a String host_name to the struct SSL in the Module SSLIOP would resolve this issue. Resolution: Revised Text: Actions taken: February 12, 2000: received issue From: "Don Flinn" To: "csiv2-ftf" Cc: "Bob Kukura" Subject: Issues 4200 & 4118 Date: Mon, 12 Mar 2001 12:12:04 -0500 Message-ID: <000001c0ab17$8f5fc670$7485413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: mE$e9G- addresses; }; In addition I feel that on the question of multiple privilege authorities, issue 4118, that there should be only one privilege authority. At present there are no implementations that use this field to find a privilege authority. Until we have some experience with using this functionality and understand how it will work in the real world I think that we should keep it simple and just allow one privilege authority name. Don ======================== Down the mid-tier Over the Firewall Nothing but Net ======================== Don Flinn Iona Technologies don.flinn@iona.com Tel: 781-902-8559 FAX: 781-902-8001 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 12 Mar 2001 13:50:35 -0500 (EST) From: Polar Humenn To: Don Flinn cc: csiv2-ftf , Bob Kukura Subject: Re: Issues 4200 & 4118 In-Reply-To: <000001c0ab17$8f5fc670$7485413f@boston.amer.iona.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: TUM!!3(Ie9e,$e9#!g!! On Mon, 12 Mar 2001, Don Flinn wrote: > I would like to propose the following for the SSLIOP module. The use of > multiple Address structures in the sequence addresses would be semantically > equivalent to using multiple mechanisms with one address in each, i.e. a > sequence containing one Address. > > const IOP::ComponentId TAG_SSL_SEC_TRANS = 21; // New tag number > > struct Address { > string host_name; > unsigned short port; > }; > > struct SSLSecTransComponent { > Security::AssociationOptions target_supports; > Security::AssociationOptions target_requires; > sequence
addresses; > }; I still feel that the sequence is unecessary and forboding. However, by bringing multiple addresses up to this level, you are requiring the client security service to multiply the mechanism for each address? So my questions are: What if the length is zero? If length is more than one, is this short hand for multiplying the mechanism in the order of the target security service desired preference? If it is not that way, then that changes quite a bit. > In addition I feel that on the question of multiple privilege authorities, > issue 4118, that there should be only one privilege authority. At present > there are no implementations that use this field to find a privilege > authority. Until we have some experience with using this functionality and > understand how it will work in the real world I think that we should keep it > simple and just allow one privilege authority name. Well, I wouldn't say because we have no experience in this matter. :) It is quite evident in the past that I do not want the client's security service to become a privilege authority service negotiator or a fault management service for any type of privilege authority. The client should do it quickly, get in, get out, by whatever mechanism the service states. If if the privilege service fault tolerant, the ServiceConfiguration should say so. I can not see any notion of having multiple privilege authorities listed for a mechanism, without any semantics defined what it means. In that light, I say that we should deprecate ServiceConfiguationSyntax for GSS_ExportName and DN as well, as they have absolutely no meaning in the specification. Cheers, -Polar > Don > > ======================== > Down the mid-tier > Over the Firewall > Nothing but Net > ======================== > > Don Flinn > Iona Technologies > don.flinn@iona.com > Tel: 781-902-8559 > FAX: 781-902-8001 > ------------------------------------------------------------------- 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: Mon, 12 Mar 2001 14:04:37 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Flinn CC: csiv2-ftf , Bob Kukura Subject: Re: Issues 4200 & 4118 References: <000001c0ab17$8f5fc670$7485413f@boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: _7$"!'k$!!CFa!!@JJe9 Don, We have agreed as part of the resolution of issue 4141/4142 to replace TAG_SSL_SEC_TRANS with TAG_TLS_SEC_TRANS = 36. Among other things this gives us the ability to modify the definition of this component to handle problems like that presented by issue 4200. A similar change will also be necessary to the SECIOP transport component. I'll have a modified document out either today, or tomorrow to help us keep track of what we've done so far. Linda passed Juergen the Published Spec last fri. and he will be giving us a pointer to it on the OMG site some time soon. I am merging the issue resolutions on top of that doc (which is csiv2-011701 + a title page inserted by Linda). Ron Don Flinn wrote: > > I would like to propose the following for the SSLIOP module. The use of > multiple Address structures in the sequence addresses would be semantically > equivalent to using multiple mechanisms with one address in each, i.e. a > sequence containing one Address. > > const IOP::ComponentId TAG_SSL_SEC_TRANS = 21; // New tag number > > struct Address { > string host_name; > unsigned short port; > }; > > struct SSLSecTransComponent { > Security::AssociationOptions target_supports; > Security::AssociationOptions target_requires; > sequence
addresses; > }; > > In addition I feel that on the question of multiple privilege authorities, > issue 4118, that there should be only one privilege authority. At present > there are no implementations that use this field to find a privilege > authority. Until we have some experience with using this functionality and > understand how it will work in the real world I think that we should keep it > simple and just allow one privilege authority name. > > Don > > ======================== > Down the mid-tier > Over the Firewall > Nothing but Net > ======================== > > Don Flinn > Iona Technologies > don.flinn@iona.com > Tel: 781-902-8559 > FAX: 781-902-8001 From: "Don Flinn" To: "Polar Humenn" Cc: "csiv2-ftf" , "Bob Kukura" Subject: RE: Issues 4200 Date: Mon, 19 Mar 2001 13:45:12 -0500 Message-ID: <000d01c0b0a4$bb2f0580$7485413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: k==!!HF_!!3%G!!gZ$e9 Polar Good catch on the undefined empty sequence. If the Address sequence is zero it could have two meanings - 1. the host/port in the profile should be used with the target_supports and target_requires from the SSLSecTransComponent. or 2. It is an error and an exception should be thrown. The first meaning is ugly so am proposing that an SSLSecTransComponent containing an empty addresses sequence is an error. I agree with your second statement that if the length is more than one then this short hand for multiplying the mechanism in the order of the target security service desired preference. Don > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Monday, March 12, 2001 1:51 PM > To: Don Flinn > Cc: csiv2-ftf; Bob Kukura > Subject: Re: Issues 4200 & 4118 > > > > On Mon, 12 Mar 2001, Don Flinn wrote: > > > I would like to propose the following for the SSLIOP module. > The use of > > multiple Address structures in the sequence addresses would be > semantically > > equivalent to using multiple mechanisms with one address in each, i.e. a > > sequence containing one Address. > > > > const IOP::ComponentId TAG_SSL_SEC_TRANS = 21; // New tag number > > > > struct Address { > > string host_name; > > unsigned short port; > > }; > > > > struct SSLSecTransComponent { > > Security::AssociationOptions target_supports; > > Security::AssociationOptions target_requires; > > sequence
addresses; > > }; > > I still feel that the sequence is unecessary and forboding. > > However, by bringing multiple addresses up to this level, you are > requiring the client security service to multiply the mechanism for each > address? > > So my questions are: > > What if the length is zero? > > If length is more than one, is this short hand for multiplying the > mechanism in the order of the target security service desired preference? > > If it is not that way, then that changes quite a bit. > > > In addition I feel that on the question of multiple privilege > authorities, > > issue 4118, that there should be only one privilege authority. > At present > > there are no implementations that use this field to find a privilege > > authority. Until we have some experience with using this > functionality and > > understand how it will work in the real world I think that we > should keep it > > simple and just allow one privilege authority name. > > Well, I wouldn't say because we have no experience in this matter. :) > > It is quite evident in the past that I do not want the client's security > service to become a privilege authority service negotiator or a fault > management service for any type of privilege authority. The client should > do it quickly, get in, get out, by whatever mechanism the service states. > If if the privilege service fault tolerant, the ServiceConfiguration > should say so. > > I can not see any notion of having multiple privilege authorities listed > for a mechanism, without any semantics defined what it means. In that > light, I say that we should deprecate ServiceConfiguationSyntax for > GSS_ExportName and DN as well, as they have absolutely no meaning in the > specification. > > Cheers, > -Polar > > > Don > > > > ======================== > > Down the mid-tier > > Over the Firewall > > Nothing but Net > > ======================== > > > > Don Flinn > > Iona Technologies > > don.flinn@iona.com > > Tel: 781-902-8559 > > FAX: 781-902-8001 > > > > ------------------------------------------------------------------- > 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-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 19 Mar 2001 14:05:16 -0500 (EST) From: Polar Humenn To: Don Flinn cc: csiv2-ftf , Bob Kukura Subject: RE: Issues 4200 In-Reply-To: <000d01c0b0a4$bb2f0580$7485413f@boston.amer.iona.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 3JT!!]e2e9OI_d96X>!! On Mon, 19 Mar 2001, Don Flinn wrote: > Polar > > Good catch on the undefined empty sequence. > > If the Address sequence is zero it could have two meanings - > 1. the host/port in the profile should be used with the > target_supports and > target_requires from the SSLSecTransComponent. Does that also mean all of the ALTERNATE_IIOP_ADDRESS components as well? This approach is getting bizzare. > or > 2. It is an error and an exception should be thrown. Which Exception? Furthermore, shall that exception be thrown even if the CSS disregards the security mechanism? I.e. it doesn't support TLS/SSL, or even that it doesn't support the QOP options. There are other cases that I think should be also be illegal. 1. zero length hostname. 2. a port of zero. It does bring up the point about the hostname in the IIOP profile. Currently, we are changing the core to allow a zero port number in the IIOP profile's port field, specifying that the client must look for other transports, such as the ones in security. No big deal. However, that does beg the question of a zero length hostname in the IIOP's profile "host" field. It would seem like that is possible, since the hostname can be further, and differently specified is security mechanisms. It would almost seem like we should eliminate the host/port field of the IIOP profile altogether (just joking). Again, if there is a zero length host address, or zero port, in an entry is the entire IOR considered invalid, or are those entries simply ignored. I would think that the entries are simply ignored, since anyone can ignore the parsing of a security mechanism just by its association options. If you are going to do this, be thorough. > The first meaning is ugly so am proposing that an SSLSecTransComponent > containing an empty addresses sequence is an error. A bit more invovled. Error, or ignored? > I agree with your second statement that if the length is more than one then > this short hand for multiplying the mechanism in the order of the target > security service desired preference. Some people may not think so. This wording will have to be precise to state that it is merely a short hand for duplicate, *continguous* security mechanisms with a transport mechanism that differs only in address information. Are you going to write this one up? Cheers, -Polar > Don > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Monday, March 12, 2001 1:51 PM > > To: Don Flinn > > Cc: csiv2-ftf; Bob Kukura > > Subject: Re: Issues 4200 & 4118 > > > > > > > > On Mon, 12 Mar 2001, Don Flinn wrote: > > > > > I would like to propose the following for the SSLIOP module. > > The use of > > > multiple Address structures in the sequence addresses would be > > semantically > > > equivalent to using multiple mechanisms with one address in > each, i.e. a > > > sequence containing one Address. > > > > > > const IOP::ComponentId TAG_SSL_SEC_TRANS = 21; // New tag > number > > > > > > struct Address { > > > string host_name; > > > unsigned short port; > > > }; > > > > > > struct SSLSecTransComponent { > > > Security::AssociationOptions target_supports; > > > Security::AssociationOptions target_requires; > > > sequence
addresses; > > > }; > > > > I still feel that the sequence is unecessary and forboding. > > > > However, by bringing multiple addresses up to this level, you are > > requiring the client security service to multiply the mechanism > for each > > address? > > > > So my questions are: > > > > What if the length is zero? > > > > If length is more than one, is this short hand for multiplying the > > mechanism in the order of the target security service desired > preference? > > > > If it is not that way, then that changes quite a bit. > > > > > In addition I feel that on the question of multiple privilege > > authorities, > > > issue 4118, that there should be only one privilege authority. > > At present > > > there are no implementations that use this field to find a > privilege > > > authority. Until we have some experience with using this > > functionality and > > > understand how it will work in the real world I think that we > > should keep it > > > simple and just allow one privilege authority name. > > > > Well, I wouldn't say because we have no experience in this > matter. :) > > > > It is quite evident in the past that I do not want the client's > security > > service to become a privilege authority service negotiator or a > fault > > management service for any type of privilege authority. The client > should > > do it quickly, get in, get out, by whatever mechanism the service > states. > > If if the privilege service fault tolerant, the > ServiceConfiguration > > should say so. > > > > I can not see any notion of having multiple privilege authorities > listed > > for a mechanism, without any semantics defined what it means. In > that > > light, I say that we should deprecate ServiceConfiguationSyntax > for > > GSS_ExportName and DN as well, as they have absolutely no meaning > in the > > specification. > > > > Cheers, > > -Polar > > > > > Don > > > > > > ======================== > > > Down the mid-tier > > > Over the Firewall > > > Nothing but Net > > > ======================== > > > > > > Don Flinn > > > Iona Technologies > > > don.flinn@iona.com > > > Tel: 781-902-8559 > > > FAX: 781-902-8001 > > > > > > > > ------------------------------------------------------------------- > > 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 > > > ------------------------------------------------------------------- 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-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 20 Mar 2001 16:00:42 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Issue 4200 4221 In-Reply-To: <3AB78762.EF3972C0@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: b_!"!O%K!!k"~!!R1)!! I agree with to Sun's proposals for issues 4200 and the trivial fix for 4221. As I stated before, I only agree with putting a sequence of addresses in the TLS_SEC_TRANS structure if it is actually a "shorthand" for duplicate multiple *contingous* security mechanisms, and the length of the sequence SHALL NOT be zero, and the length of the host address SHALL NOT be zero, and the port number SHALL NOT be zero. If any of these are true, the security mechanism should be regarded as invalid, and should in effect be ignorned by the CSS as if it did not exist. Also, the corresponding change should be made to the SECIOP_SEC_TRANS structure. ------------------------------------------------------------------- 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 From: "Don Flinn" To: "csiv2-ftf" Subject: Resolution writeup of issue 4200 Date: Mon, 9 Apr 2001 16:24:03 -0400 Message-ID: <000d01c0c133$04aeeec0$7485413f@boston.amer.iona.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Type: multipart/mixed; boundary="----=_NextPart_000_000E_01C0C111.7DA05C00" X-UIDL: G_X!!~D1!! X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Flinn CC: csiv2-ftf Subject: Re: Resolution writeup of issue 4200 References: <000d01c0c133$04aeeec0$7485413f@boston.amer.iona.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: ,7Qe9!:?!!"<_d9LNb!! Don Flinn wrote: > > Attached for comment is the resolution for issue 4200. Please comment on > this resolution and suggest any changes. Especially, Polar, is this the way > the SECIOP module should be handled? I think it would be better to base your changes on document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf In particular, I think you will find the SECIOP stuff less confusing as only the tag for SECIOP that CSIv2 created should come into play (I don't think we need to describe a change to SECIOP's GenericMechanismInfo structure onlu our TAC_SECIOP_SEC_TRANS tagged component). I am not up to speed on the restrictions: The sequence of addresses is contiguous security mechanisms. The length of the sequence SHALL NOT be zero, and the length of the host address SHALL NOT be zero, and the port number SHALL NOT be zero. If any of these are true, the security mechanism should be regarded as invalid, and should be ignored by the CSS as if it did not exist. Can anyone explain? If there was a port number without a host address, couldn't the port apply to the host address in the IIOP profile, as is currently the case (with a single port number)? If there is a host address and a zero port number couldn't the inverse be true (that is, the port in the IIOP profile is applied at the host address)? If the sequence is empty, couln't that mean that the target supports SSL and raw IIOP at the address and port of the IIOP profile? Ron > > It is intended to put this out for vote with issue 3907 and issue > 4221 as > soon as we get a writeup of all three. I think you might mean 3906 not 3907, and if so, I was hoping to get a little discussion on this. I had a conversation with Polar but no one else has commented. > > Don > > ======================== > Down the mid-tier > Over the Firewall > Nothing but Net > ======================== > > Don Flinn > Iona Technologies > don.flinn@iona.com > Tel: 781-902-8559 > FAX: 781-902-8001 > > ------------------------------------------------------------------------ > Name: 010409_Issue4200.html > 010409_Issue4200.html Type: Hypertext Markup Language > (text/html) > Encoding: quoted-printable a Date: Tue, 10 Apr 2001 14:34:18 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Don Flinn Cc: csiv2-ftf Subject: Re: Resolution writeup of issue 4200 References: <000d01c0c133$04aeeec0$7485413f@boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 4~-!!K),!!Ln,!!Q]J!! Pardon me for being dense, but could someone please explain to me how the proposed resolution relates to the issue at all? The issue talks about module SSLIOP not containing hostname. The discussion says that a host_name string should be added to the SSL struct in module SSLIOP. And then the revised text has no mention of SSL or SSLIOP, and it proceeds to propose all sort of changes to all sorts of other things, which don't appear to be related to either the summary or the discussion of the issue. So, who was planning to defend a resolution like this at the AB?:-) Since neither SSL nor SSLIOP is anymore in cotrnol of this FTF, wouldn't it make sense to transfer this issue to the Security RTF, which appears to own those modules and structs, and then raise an issue more appropriate to the proposed resolution and provide an appropriate discussion to justify the proposed resolution? Confusedly yours, Jishnu. Date: Tue, 10 Apr 2001 16:50:21 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Don Flinn Cc: Ron Monzillo , csiv2-ftf@omg.org Subject: Re: teleconference References: <000401c0c1f1$24c62b60$7485413f@boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: SH:!!VNMd9Ch=e9l=`!! Don Flinn wrote: > > Discussion items: > Jishnu has proposed that issue 4200 might be more appropriately >moved to the > security RTF. Well, it depends. The issue as currently presented does not seem to have anything to do with this FTF. However, the resolution that you proposed, which appears to be a resolution to a different issue that is yet to be raised, or perhaps an issue that this one has morphed into, part of which appears to have a lot to do with this FTF.:-) You certainly cannot do that resolution through the Security RTF. I was just left very confused reading through the thing that's all. Minimally, it requires a considerably expanded Discussion/Resolution section explaining how the creation of TAG_TLS_SEC_TRANS moved the definition of the struct corresponding to that tag out of the SSLIOP module and to the CSIIOP module (BTW, is there a list of resolved issues with their current resolutions readily available online anywhere for me to refer to?). Also this issue is about SSL so it is not clear to me how you can start fixing SECIOP under this issue. If there is a corresponding SECIOP issue, raise that and fix it. Issues are reeeally cheap to raise.:-) Couple of additional point: 1. anonymous sequence declaration have been deprecated. So all IDL lines of the form: sequence bar; that appears within struct declarations need to be split into a typedef followed by usine of the type thus defined in the struct declaration. BTW, in addtiion to this problem appearing in this resolution for 4200, it also appears in the IDL in the spec, in the declaration of structs: CSI::AuthorizationElement sequence the _element CSIIOP::SAS_ContextSec sequence privilege_authorities CSIIOP::CompoundSecMechList sequence mechanism_list All those need to be fixed, and perhaps can be done editorially. 2. Those sequence 's need to at least become sequence's:-) > Write up of Issue 4221 and permanent tabling of issue 3907 for this FTF. > > Where are we on issues - 3906, 4118, 4156 and 4167. > > Ron's editorial change to paragraph 159. I am somewhat lost about this one too. The document csiv2-031401.pdf para 159 does not contain the alleged sentence. Document csiv2-0117011.pdf para 159 is in the Conformance Levels section, and does not contain the alleged sentence either. Aha, doing a pattern search in csiv2-031401.pdf, it looks like the para number is actually 59. I could go with an editorial for that. Jishnu. > > > Don > > > -----Original Message----- > > From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] > > Sent: Tuesday, April 10, 2001 2:37 PM > > To: dflinn@iona.com > > Cc: csiv2-ftf@omg.org > > Subject: teleconference > > > > > > will there be one tomorrow? > > -- 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 From: "Don Flinn" To: "csiv2-ftf" Subject: Issues 3906 3907 4200 Date: Wed, 2 May 2001 14:37:16 -0400 Message-ID: <000d01c0d336$e9847280$7485413f@boston.amer.iona.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Type: multipart/mixed; boundary="----=_NextPart_000_000E_01C0D315.6272D280" X-UIDL: bPQe9%Pc!!Ep4!!nXY!! Attached is the proposal for issues 3906, 3907 and 4200. This is for comment at this time. I have tried to capture the final e-mail discussion and resolutions for these issues. If there are no further comments or discussion required then the resolutions of these issues, as written, will be put out for a vote. There is another issue raised by David Chang which has not yet an issue number. If David submits a resolution for his issue to the mailing list and that issue does not require further discussion and comment then his issue will also be included in Vote 5. All comments, corrections and suggestions cheerfully accepted. Don ======================== Down the mid-tier Over the Firewall Nothing but Net ======================== Don Flinn Iona Technologies don.flinn@iona.com Tel: 781-902-8559 FAX: 781-902-8001 [] csiv2_ftf_vote_5.htm From: "Don Flinn" To: "csiv2-ftf" Subject: Revised text for issue 4200 Date: Sun, 29 Apr 2001 22:19:50 -0400 Message-ID: <001701c0d11c$09301750$2302a8c0@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: VS)!!9*O!!3Se!!SJid9 Attached for comment is the revised resolution for issue 4200. Don ======================== Down the mid-tier Over the Firewall Nothing but Net ======================== Don Flinn Iona Technologies don.flinn@iona.com Tel: 781-902-8559 FAX: 781-902-8001 From: "Don Flinn" To: "csiv2-ftf" Subject: revision to issue 4200 Date: Sun, 29 Apr 2001 22:27:41 -0400 Message-ID: <001801c0d11d$2167a030$2302a8c0@boston.amer.iona.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0019_01C0D0FB.9A560030" X-UIDL: '7Qe9YCZd9S5m!!'Q!!! Sorry I didn't attach it. So here is the revised text for the resolution to issue 4200. Don ======================== Down the mid-tier Over the Firewall Nothing but Net ======================== Don Flinn Iona Technologies don.flinn@iona.com Tel: 781-902-8559 FAX: 781-902-8001 [] 010429_Issue4200_2.htm Date: Wed, 23 May 2001 10:07:53 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: csiv2-ftf@omg.org Subject: [Fwd: Vote 5] Content-Type: multipart/mixed; boundary="------------FD4AADA11B2D3D8AF27B1B9F" X-UIDL: UR8!!VJ(e9,#@e9mFY!! I forgot to reply allMessage-ID: <3B0BC3FE.58B87784@east.sun.com> Date: Wed, 23 May 2001 10:06:54 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Flinn Subject: Re: Vote 5 References: <000601c0e2b5$768b1c00$2302a8c0@boston.amer.iona.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Don, I know you have already called a vote on 4200, and its not that I disagree with the sense of the resolution, its just that in looking at the changes being proposed, they fit into the document like a square peg in a round hole. I'd like to clean this up however it is most appropriate and expedient. Specifically: before the resolution, para 130 in the base doc said When an instance of the TAG_TLS_SEC_TRANS component occurs in a containing TAG_CSI_SEC_MECH_LIST component, it defines the port number at which the target will be listening for SSL/TLS protected invocations. The supported (target_supports) and required (target_requires) association options defined in the component define the transport level security characteristics of the target (at the port). The resolution proposes to change this paragraph as follows: When an instance of the TAG_TLS_SEC_TRANS component occurs in a containing TAG_CSI_SEC_MECH_LIST component, it defines the port number at which the target will be listening for SSL/TLS protected invocations. The supported (target_supports) and required (target_requires) association options defined in the component define the transport level security characteristics of the target at the given addresses. The two sentences of this para are disconnected. The first talks about a port number, and the second describes how the protocol supports addresses. The first sentence also needs to be changed When an instance of the TAG_TLS_SEC_TRANS component occurs in a containing TAG_CSI_SEC_MECH_LIST component, it defines the addresses at which the target will be listening for SSL/TLS protected invocations. There are other considerations. The new paragraph, which the resolution to 4200, would add after 130, talks about the "sequence of addresses", where it probably should more explicitly refer to the addresses field of the TLS_SEC_TRANS structure. In any case, this paragraph would do better to come after the IDL The sequence of addresses provides a shorthand for defining multiple security mechanisms that differ only in their transport addresses. The length of the sequence shall not be zero, and the length of the host address shall not be zero, and the port number shall not be zero. If any of these requirements are violated a CSS shall ignore the associated security mechanism. struct TLS_SEC_TRANS { AssociationOptions target_supports; AssociationOptions target_requires; TransportAddressList addresses; }; for example, The addresses field provides a shorthand for defining multiple security mechanisms that differ only in their transport addresses. The addresses field shall contain at least one address. For each address in the addresses field, the length of the host address shall not be zero, and the port number shall not be zero. If any of these requirements are violated a CSS shall ignore the associated security mechanism. Finally, somewhere along the line the "should" in the last phase of the last sentence was changed to a "shall". I don't think we need to write in requirements for CSS's to reject bad mechanism definitions. They are required to know how to process valid ones. There are losts of ways that mechanisms can be screwed up, we must not create requirements that the CSS must reject bad forms; should rejcet is OK, shall reject is too much. We have another open issue, 4293, on basically the same topic, and we could decide to use the resolution of that issue to clean 4200 up. The last sentence of the preceding paragraph, 129, also has a problem which we introduced when we resolved issue 4141 the document currently states: The semantics associated with existing uses of this component outside of a containing TAG_CSI_SEC_MECH_LIST component are not modified or described by this specification. This sentence was appropriate for the TAG_SSL_SEC_TRANS_TAG, but is no longer appropriate based on the invention of a new tag. It should be removed. Ron Don Flinn wrote: > > Attached is Vote 5. The Vote is due by close of business (19:00 EST) May > 29, 2001. This vote has been out for comment for some time so one week > should be sufficient time for a vote. > > I used Front Page to construct the HTML. Please let me know if there is any > problem. > > Don > > ======================== > Down the mid-tier > Over the Firewall > Nothing but Net > ======================== > > Don Flinn > Iona Technologies > don.flinn@iona.com > Tel: 781-902-8559 > FAX: 781-902-8001 > > ------------------------------------------------------------------------ > Name: csiv2-ftf-vote_5_5.html > csiv2-ftf-vote_5_5.html Type: Hypertext Markup Language (text/html) > Encoding: quoted-printable Issue 4200: Module SSLIOP Does Not Contain Host (csiv2-ftf) Click here for this issue's archive. Source: IONA (Mr. Donald Flinn, donald.flinn@iona.com) Nature: Uncategorized Issue Severity: Critical Summary: In some situations, e.g. a multi-homed system, there would have to be a profile for each port number supported by SSL. This is inefficient. Adding a String host_name to the struct SSL in the Module SSLIOP would resolve this issue. Discussion: We add a minor section describing a TransportAddress structure with wording close to that of the IIOP profile on page 15-50 of CORBA 2.3. formal/99-10-07. We also add a typedef for a sequence of these structures. We change the TLS_SEC_TRANS structure to use a list of these addresses. Resolution: Close issue with revised text. Revised Text: Base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] Add Minor Heading Section before TAG_TLS_SEC_TRANS Transport Address The TransportAddress structure indicates an INTERNET address where the TSS is listening for connection requests. struct TransportAddress { string host_name; unsigned short port; }; typedef sequence TransportAddressList; The host_name field identifiers the Internet host to which connection requests will be made. The host_name field shall not be empty string. The port field contains the TCP/IP port number (at the specified host) where the TSS is listening for connection requests. The port number shall not be zero. [2] Replace paragraph 130 with the following: When an instance of the TAG_TLS_SEC_TRANS component occurs in the transport_mech field of the CompoundSecMech structure, it defines the sequence of transport addresses that the target will be listening for SSL/TLS protected invocations. The supported (target_supports) and required (target_requires) association options defined in the component shall define the transport level security characteristics of the target at the given addresses. [3] Change the IDL for TLS_SEC_TRANS after paragraph 130 to the following: struct TLS_SEC_TRANS { AssociationOptions target_supports; AssociationOptions target_requires; TransportAddressList addresses; }; [4] Add the following paragraph following the IDL after paragraph 130: The addresses field provides a shorthand for defining multiple security mechanisms that differ only in their transport addresses. The addresses field shall contain at least one address. [5] Add the following IDL for TransportAddress 16.9.4 on page 16-65 after the definition of CompoundSecMechList: struct TransportAddress { string host_name; unsigned short port; }; typedef sequence TransportAddressList; [6] Change the IDL for TLS_SEC_TRANS in section 16.9.4 on page 16-66 to the following: struct TLS_SEC_TRANS { AssociationOptions target_supports; AssociationOptions target_requires; TransportAddressList addresses; }; Actions Taken: February 12, 2001: received issue June XX, 2001: closed issue Date: Fri, 01 Jun 2001 13:40:37 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn , csiv2-ftf@omg.org Subject: Re: Issue 4200 and 4293 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~?@!!OY!e9L~Ud9],A!! You ahve the following in both resolutions. "The host_name field identifiers the Internet host to which connection requests will be made. The host_name field shall not be empty string." Polar Humenn wrote: > > Greetings, > > To help Don out with his constraints on his time, I have composed > the resolutions to 4200 (SSL Addresses) and 4293 (SECIOP addresses). > > They are attached and also viewable from the following URLs: > > ftp://greene.case.syr.edu/pub/omg/csiv2-ftf/FTF-Issue4200-1.html > ftp://greene.case.syr.edu/pub/omg/csiv2-ftf/FTF-Issue4293-1.html > > Since both resolutions make use of a common data structure (i.e. > TransportAddress) it is placed in a different section. > > Furthermore, these issues are written in such a manner that they are > compatible with each other, so each can be voted on separately, and there > should be no editorial conflicts. > > 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 > > ------------------------------------------------------------------------ > Name: FTF-Issue4200-1.html > FTF-Issue4200-1.html Type: Hypertext Markup Language (TEXT/html) > Encoding: BASE64 > > Name: FTF-Issue4293-1.html > FTF-Issue4293-1.html Type: Hypertext Markup Language (TEXT/html) > Encoding: BASE64 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 1 Jun 2001 14:12:09 -0400 (EDT) From: Polar Humenn To: Ron Monzillo , Don Flinn cc: Subject: Re: Issue 4200 and 4293 In-Reply-To: <3B17D395.35985E5E@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-427817617-1048416130-991419129=:2948" X-UIDL: cmdd9~K6!!=-4!!UIhd9 On Fri, 1 Jun 2001, Ron Monzillo wrote: > You ahve the following in both resolutions. > > "The host_name field identifiers the Internet host to which > connection requests will be made. The host_name field shall > not be empty string." Yep, I "ahve"! :) Sorry about that. Here's an update with this paragraph: The host_name field identifies the Internet host to which connection requests will be made. The host_name field shall not contain an empty string. They are attached and available at: ftp://greene.case.syr.edu/pub/omg/csiv2-ftf/FTF-Issue4200-2.html ftp://greene.case.syr.edu/pub/omg/csiv2-ftf/FTF-Issue4293-2.html Cheers, -Polar > > Polar Humenn wrote: > > > > Greetings, > > > > To help Don out with his constraints on his time, I have composed > > the resolutions to 4200 (SSL Addresses) and 4293 (SECIOP >addresses). > > > > They are attached and also viewable from the following URLs: > > > > ftp://greene.case.syr.edu/pub/omg/csiv2-ftf/FTF-Issue4200-1.html > > ftp://greene.case.syr.edu/pub/omg/csiv2-ftf/FTF-Issue4293-1.html > > > > Since both resolutions make use of a common data structure (i.e. > > TransportAddress) it is placed in a different section. > > > > Furthermore, these issues are written in such a manner that they >are > > compatible with each other, so each can be voted on separately, >and there > > should be no editorial conflicts. > > > > 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 > > > > >------------------------------------------------------------------------ > > Name: FTF-Issue4200-1.html > > FTF-Issue4200-1.html Type: Hypertext Markup Language >(TEXT/html) > > Encoding: BASE64 > > > > Name: FTF-Issue4293-1.html > > FTF-Issue4293-1.html Type: Hypertext Markup Language >(TEXT/html) > > Encoding: BASE64 > ------------------------------------------------------------------- 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 [] FTF-Issue4200-2.htm [] FTF-Issue4293-2.htm Date: Mon, 11 Jun 2001 17:44:58 -0500 (CDT) From: Chris Cleeland To: Subject: Vote 6 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 9P0!!@9I!!F!?!!`bXd9 OCI Votes for Vote 6 as follows ISSUE VOTE COMMENT ===== ==== ===================================================== 4118 YES 4156 YES 4167 YES 4200 NO See notes below. 4268 YES 4277 YES 4281 YES 4282 YES 4293 NO See notes for 4200 below 4308 YES 4326 YES 4327 NO In conflict with 4167 NOTES ----- 4200 The issue specifically discusses multi-homed systems and talks about using the hostname as a solution for multi-homed systems. I'm sorry that I didn't follow this discussion when it was originally introduced and discussed because I'm unconvinced that this will solve more problems than it creates. Often, the canonical name of a multi-homed system does not resolve to all of its addresses. Therefore, putting the *name* of the host could cause problems if the name doesn't resolve to the IP address associated with the interface on/thru which the application is advertising its services. The application may be unreachable thru the canonical address. I believe that by formalizing the use of the hostname and requiring it (since it can't be empty), you're imposing on the system administration policies of an organization. I've personally observed this problem on embedded systems or systems where, e.g., communication is segregated on a per-interface basis based on the nature of the communication. -- Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris Principal Software Engineer, Object Computing, Inc., +1 314 579 0066 "Everybody wants prosthetic foreheads on their real heads." THANKS TO ALL FOR THE MS150 SPONSORSHIP -- 184.69 miles IN TWO DAYS! X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from 110-94.bestdsl.net (216.162.110.94) by hobbit.omg.org asmtp(1.0) id 25181; Fri, 15 Jun 2001 20:29:50 -0400 (EDT) Received: from ocilap5.ociweb.com (IDENT:cleeland@ocilap5.ociweb.com [205.159.59.8]) by fw.milodesigns.com (8.9.3/8.8.7) with ESMTP id TAA14765; Fri, 15 Jun 2001 19:20:47 -0500 Date: Fri, 15 Jun 2001 19:24:29 -0500 (CDT) From: Chris Cleeland To: cc: Subject: Proposed editorial change to issue 4200 resolution Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: CN X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Cleeland CC: csiv2-ftf@omg.org, kukura@iona.com Subject: Re: Proposed editorial change to issue 4200 resolution References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: -*[d9Ugl!!@O`d9;%5e9 I support this clarification. Chris Cleeland wrote: > > Hi, > > You may recall that I voted NO on issue 4200 due to host name. After > conferring with the originator of the issue to get an understanding, I > would now probably change my vote to YES if that were possible. Doesn't > matter, since it passed anyway. > > On with the issue, however. I would like to propose the following > editorial change to clarify the resolution. If this had been in there, I > probably would've never had a problem with it because it would've been > clearer from the start. > > As as *editorial change*, append the following sentence: > > "The host_name field shall contain a host name or an IP address in > standard numerical address (e.g., dotted-decimal) form." > > to the paragraphs that were added in the resolution for issue 4200 and > 4293, which say: > > "The host_name field identifies the Internet host to which connection > requests will be made. The host_name field shall not contain an empty > string." > > This clarifies what can be in a hostname. By specifying "standard > numerical address", we don't leave it open for IPv6 numerical > representations, and don't force some future RTF into dealing with that. > > Thanks for your late consideration of this clarification. And thanks to > Jishnu and Bob Kukura for helping with the clarification and support in > the change. > > -cj > > -- > Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris > Principal Software Engineer, Object Computing, Inc., +1 314 579 0066 > "Everybody wants prosthetic foreheads on their real heads." > THANKS TO ALL FOR THE MS150 SPONSORSHIP -- 184.69 miles IN TWO DAYS! Date: Mon, 18 Jun 2001 11:06:14 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: csiv2-ftf@omg.org Cc: Ron Monzillo , Chris Cleeland , kukura@iona.com Subject: Re: Proposed editorial change to issue 4200 resolution References: <3B2E07A4.861F3299@east.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: gSW!!mP6e9P/J!!'id!! Ron Monzillo wrote: > > I support this clarification. > > Chris Cleeland wrote: > > > > Hi, > > > > You may recall that I voted NO on issue 4200 due to host name. After > > conferring with the originator of the issue to get an understanding, I > > would now probably change my vote to YES if that were possible. Doesn't > > matter, since it passed anyway. Just a process clarification. The vote in question is closed and cannot be changed anymore. However, as you point out, it is a minor detail and does not make any material difference in the outcome. > > On with the issue, however. I would like to propose the following > > editorial change to clarify the resolution. If this had been in > > there, I > > probably would've never had a problem with it because it would've > > been > > clearer from the start. > > > > As as *editorial change*, append the following sentence: > > > > "The host_name field shall contain a host name or an IP address in > > standard numerical address (e.g., dotted-decimal) form." > > > > to the paragraphs that were added in the resolution for issue 4200 > > and > > 4293, which say: > > > > "The host_name field identifies the Internet host to which > > connection > > requests will be made. The host_name field shall not contain an > > empty > > string." > > > > This clarifies what can be in a hostname. By specifying "standard > > numerical address", we don't leave it open for IPv6 numerical > > representations, and don't force some future RTF into dealing with > > that. > > > > Thanks for your late consideration of this clarification. And > > thanks to > > Jishnu and Bob Kukura for helping with the clarification and > > support in > > the change. Unless there is an objection from anyone, I think this can be carried out as an editorial change. So if you are a voting member of the FTF and do have an objection to the introduction of this clarifying text, please let me know ASAP, but not later than June 21 2400GMT. Thanks, Jishnu. Date: Mon, 18 Jun 2001 10:28:08 -0500 (CDT) From: Chris Cleeland To: "Flinn, Don" cc: "'jishnu_mukerji@hp.com'" , , Ron Monzillo , Subject: RE: Proposed editorial change to issue 4200 resolution In-Reply-To: <0BA85ABE7E49D411A3BF0090279369B40174683F@mars.hi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 0UYd9HS0!!R/k!!b/:e9 On Mon, 18 Jun 2001, Flinn, Don wrote: > > Chris Cleeland wrote: > > > > > As as *editorial change*, append the following sentence: > > > > > > "The host_name field shall contain a host name or an IP address > >in > > > standard numerical address (e.g., dotted-decimal) form." > > > > > > to the paragraphs that were added in the resolution for issue > >4200 and > > > 4293, which say: > > > > > > "The host_name field identifies the Internet host to which > >connection > > > requests will be made. The host_name field shall not contain an > >empty > > > string." > > > > > > This clarifies what can be in a hostname. By specifying > >"standard > > > numerical address", we don't leave it open for IPv6 numerical > > > representations, and don't force some future RTF into dealing > >with that. > > I'm not sure what you mean here. IPv6 supports a standard > >hexidecimal > numeric address. Did you mean to say "we leave it open for IPv6 > numberical representations." Sorry. Damn trying to rush that off while my child was screaming in the background. Yes, it should have said "we leave it open for IPv6 numerical representations". Basically, I didn't want to specify "host name or dotted-decimal numerical address" because that would leave out IPv6. So, I wanted to simply say "numerical representation", thus leaving the door open FOR IPv6 or whatever else may come along. Fortunately, this doesn't affect the proposed change, just the explanation thereof, so anyone who's already given their imprimatur need not necessarily re-evaluate. Thanks! -cj -- Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris Principal Software Engineer, Object Computing, Inc., +1 314 579 0066 "Everybody wants prosthetic foreheads on their real heads." THANKS TO ALL FOR THE MS150 SPONSORSHIP -- 184.69 miles IN TWO DAYS!