Issue 2344: More nil/NULL arguments that need to be removed (sec-rev) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: As we realized during the RTF 1.5, we have erroneous text for operations that describe passing nil/NULL for parameters. I"ve tracked down a few more: p. 15-96 [495]: For the requested_privileges parameter, the phrase "(A null attribute set requests default attributes.)" should read "A zero length attribute list requests the default attributes." p. 15-130 [666]: For the data_included_in_token parameter, the phrase "(may be null)" should read "(may be a zero length sequence)". p. 15-156 [784]: The object_type (which is a repository id) parameter is allowed to be nil. It should read "If this is the empty string, all types are implied." p. 15-157 [787]: Same as above. p. 15-171 [846]: For the mechanism parameter, the phrase "Normally NULL" should read "Normally the empty string". p. 15-171 [846]: For the chain_bindings parameter, the phrase "Normally NULL (zero length)" should read "Normally a zero length octet sequence". Resolution: Close issue 2344: More nil/NULL argument that need to be removed: Revised Text: Close issue 2344: More nil/NULL argument that need to be removed: with the following modifications: [ Thank you Andre! ]. As we realized during the RTF 1.5, we have erroneous text for operations that describe passing nil/NULL for parameters. I’ve tracked down a few more: p. 15-96 [495]: For the requested_privileges parameter, the phrase "(A null attribute set requests default attributes.)" should read "A zero length attribute list requests the default attributes." [Fixed in Resolution 6] p. 15-130 [666]: For the data_included_in_token parameter, the phrase "(may be null)" should read "(may be a zero length sequence)". p. 15-156 [784]: The object_type (which is a repository id) parameter is allowed to be nil. It should read "If this is the empty string, all types are implied." p. 15-157 [787]: Same as above. p. 15-171 [846]: For the mechanism parameter, the phrase "Normally NULL" should read "Normally the empty string". p. 15-171 [846]: For the chain_bindings parameter, the phrase "Normally NULL (zero length)" should read "Normally a zero length octet sequence". Reason: We agreed these changes are editorial. Resolution 14: Action: Close issues 1787 and 2069 "Current:get_policy() is semantically inconsistent with curr. object model" Reason: We agreed that all thread related security policies will be handled by the ORB’s PolicyCurrent object. Actions taken: January 25, 1999: received issue April 20, 1999: closed issue Discussion: End of Annotations:===== From: "Andre Srinivasan" Date: Mon, 25 Jan 1999 16:02:28 -0800 (PST) To: sec-rev@omg.org, issues@omg.org Subject: More nil/NULL arguments that need to be removed Reply-To: andre@inprise.com X-Disclaimer: These are my statements and opinions. Mine Mine Mine Mine. X-Disclaimer: To assume or infer that these statements represent X-Disclaimer: Inprise Corporation would be, without a doubt, your error. As we realized during the RTF 1.5, we have erroneous text for operations that describe passing nil/NULL for parameters. I've tracked down a few more: p. 15-96 [495]: For the requested_privileges parameter, the phrase "(A null attribute set requests default attributes.)" should read "A zero length attribute list requests the default attributes." p. 15-130 [666]: For the data_included_in_token parameter, the phrase "(may be null)" should read "(may be a zero length sequence)". p. 15-156 [784]: The object_type (which is a repository id) parameter is allowed to be nil. It should read "If this is the empty string, all types are implied." p. 15-157 [787]: Same as above. p. 15-171 [846]: For the mechanism parameter, the phrase "Normally NULL" should read "Normally the empty string". p. 15-171 [846]: For the chain_bindings parameter, the phrase "Normally NULL (zero length)" should read "Normally a zero length octet sequence". -andre. To: Polar Humenn Cc: sec-rev@omg.org Subject: Re: Open Issues References: From: "Andre Srinivasan" Date: 09 Mar 1999 22:53:04 -0800 Lines: 65 Issue 339: I vote to close Issue 357: I vote to defer Issue 374: Isn't this the same as 998? I think we've made this even more difficult with the addition of ReceivedCredentials (since we no longer even have a chance of seeing the delegation chain). Vote to argue. Issue 375: Its moot whether we took care of this in 1.5. I don't recall the conversation so we need to talk about it again. Issue 379: Already closed Issue 714: Vote to close. We'll get back into this with CSIv2. Issue 716: Already closed Issue 998: Same as 374 Issue 1633: Same as 714 Issue 1723: I vote to accept Polar's picture. Issue 2027: I vote to get rid of the policy stuff in Current and stick with get/set credentials. Issue 2033: I vote to Defer. Issue 2063: I was pretty sure everyone liked Polar's suggestion. We should discuss again. Issue 2069: Need to finish meeting with messaging folks. I vote to defer. Issue 2086: Yuck. Issue 2169: I vote to make the editorial change. Issue 2170: I vote to make the editorial change. Issue 2199: I vote to make the editorial change. Issue 2259: More discussion Issue 2344: I vote to make the editorial change Question: Are nulls *allowed* to be passed to locality constrained y are not for non-locality constrained. I would argue that making that distinction is just asking for trouble. Let's be consistent and stick with the no nulls rule. Besides with the Component/Persistence spec, there's a new IDL modifier for locality constrained objects. Issue 2437: I vote no on Polar's recommendataion. We need to discuss this more. Issue 2440: I vote no on Polar's recommendataion. The credentials that the client sees from the server must come from the object reference. Cool, we need another policy. Issue 2451: We need discussion. Issue 2452: We need discussion. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 10 Mar 1999 10:32:30 -0500 (EST) From: Polar Humenn To: sec-rev@omg.org Subject: Re: Open Issues On 9 Mar 1999, Andre Srinivasan wrote: > Issue 2344: I vote to make the editorial change > > Question: Are nulls *allowed* to be passed to locality > constrained y are not for non-locality constrained. > > I would argue that making that distinction is just asking for > trouble. Let's be consistent and stick with the no nulls > rule. Besides with the Component/Persistence spec, there's a > new IDL modifier for locality constrained objects. Oh, I totally agree. I was just looking for clarification. I believe Jishnu mentioned something about that to me once. Just wondering. -Polar Sender: jis@fpk.hp.com Date: Wed, 10 Mar 1999 16:20:41 +0000 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Polar Humenn CC: sec-rev@omg.org Subject: Re: Open Issues References: Polar Humenn wrote: > On 9 Mar 1999, Andre Srinivasan wrote: > > > Issue 2344: I vote to make the editorial change > > > > Question: Are nulls *allowed* to be passed to locality > > constrained y are not for non-locality constrained. > > > > I would argue that making that distinction is just asking for > > trouble. Let's be consistent and stick with the no nulls > > rule. Besides with the Component/Persistence spec, there's a > > new IDL modifier for locality constrained objects. > > Oh, I totally agree. I was just looking for clarification. I believe > Jishnu mentioned something about that to me once. Just wondering. I agree with Andre. I don't think it is a good idea to allow passing nulls in one case and not in the other. In principle one should not be able to tell whether one is talking to a colocated object or not, and certainly not depend on such things to decide what to pass in a parameter. So I'd say go with uniformly "no nulls". Jishnu.