headers
Andrew Sciberras | 16 Dec 2003 23:04
Picon
Picon

draft-zeilenga-ldap-readentry-01.txt


G'Day,

The following text can be found in section 3.1 and 3.2:

~~~~~~~~~~~~~~~~~
  The server is to return a SearchResultEntry containing, subject
  to access controls and other constraints, values of the requested
  attributes.

  The normal processing of the update operation and the processing of
  this control MUST be performed as one atomic action isolated from
  other update operations.

  If the update operation fails, no response control is provided.
~~~~~~~~~~~~~~~~

On one hand, the first paragraph implies that if the read fails due to
access control restrictions, then no values should be returned.
On the other hand, paragraph two indicates that if the read fails (possibly
due to access controls) then the entire operation should fail.
Paragraph 3 explicitly states that if the update fails then the read should
as well, but fails to address the alternate scenario.

What happens if the read operation fails due to the user not having
sufficient access rights?
Should the update succeed or fail?

Thanks,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kurt D. Zeilenga | 17 Dec 2003 07:10

Re: draft-zeilenga-ldap-readentry-01.txt

At 02:04 PM 12/16/2003, Andrew Sciberras wrote:

>G'Day,
>
>The following text can be found in section 3.1 and 3.2:
>
>~~~~~~~~~~~~~~~~~
>  The server is to return a SearchResultEntry containing, subject
>  to access controls and other constraints, values of the requested
>  attributes.
>
>  The normal processing of the update operation and the processing of
>  this control MUST be performed as one atomic action isolated from
>  other update operations.
>
>  If the update operation fails, no response control is provided.
>~~~~~~~~~~~~~~~~
>
>
>On one hand, the first paragraph implies that if the read fails due to
>access control restrictions, then no values should be returned.

The first paragraph implies that the contains of the entry
is subject to access controls which may cause some subset
of the attributes to be returned and, for those attribute
returned, some subset of their values.  The returned entry
could, in fact, have no attributes.

>On the other hand, paragraph two indicates that if the read fails (possibly
>due to access controls) then the entire operation should fail.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Sciberras | 19 Dec 2003 00:27
Picon
Picon

draft-bergeson-uddi-ldap-schema-02.txt

G'Day,

Just some comments regarding 'LDAP Schema for UDDI'.

Section 5.2
The equality matching rule for a distingushed name cannot be a
caseIgnoreMatch.

For the following attributes:
* uddiName
* uddiServiceKey
* uddiBindingKey
It is explicitly stated that the values of this attribute may not be blank.

The other attributes with a DirectoryString string attributes do not carry
this statement. I'm not sure what this is implying, but I feel that I should
note that none of the DirectoryString attributes are permitted to have a
blank value.

Section 5.17
"When saving a new uddiBusinessService structure, pass an empty
uddiServiceKey value"
Section 5.18
"When saving a new uddiBindingTemplate structure, pass an empty
uddiBindingKey value"
These would be strictly illegal since a DirectoryString must have at least
one character.

Section 5.41
I don't think you intended to have a boolean syntax for this attribute
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hallvard B Furuseth | 19 Dec 2003 11:45
Picon
Picon
Favicon

Referrals in draft-rharrison-ldap-intermediate-resp-01.txt

draft-rharrison-ldap-intermediate-resp-01.txt says:

>   For example, the LDAP delete operation could be extended via a 
>   subtree control to mean that an entire subtree is to be deleted.  A 
>   subtree delete operation needs to return continuation references 
>   based upon subordinate knowledge information contained in the server 
>   so that the client can complete the operation.  Returning references 
>   as they are found instead of with the final result allows the client 
>   to progress the operation more efficiently because it does not have 
>   to wait for the final result to get this continuation reference 
>   information.  

Subtree delete can't return references in the final result anyway,
because from such a referral, only one operation should be performed on
one of the returned URIs to progress the operation.  Subtree delete may
need to return several continuation references.  Also, the referral
result code means that the operation was not performed, not that it was
partially performed.

Also, 'ietf-ldapext <at> netscape.com' should be 'ldapext <at> ietf.org'.

--

-- 
Hallvard
Permalink | Reply | 1 comment |
headers
Hallvard B Furuseth | 20 Dec 2003 21:07
Picon
Picon
Favicon

features-05 comments

draft-zeilenga-ldap-features-05.txt says:

> 2. Discovery of supported features

>   A client may examine the values of this attribute to
>   determine if a particular feature is supported by the server.  A
>   client MUST ignore values it doesn't recognize as they refer to
>   elective features it doesn't implement.

What's the point of the last sentence?  What else could the client do
with a feature it doesn't know about?

>   The 'supportedFeatures' attribute type is described as follows

...", using the AttributeTypeDescription syntax described in [Models]"  

(and [Models] must be added to the References section).

>       ( 1.3.6.1.4.1.4203.1.3.5
>         NAME 'supportedFeatures'
>         DESC 'features supported by the server'
>         EQUALITY objectIdentifierMatch
>         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
>         USAGE dSAOperation )

This is missing, adapted from similar texts in [Models]:

  The 'objectIdentifierMatch' matching rule and the
  objectIdentifierFirstComponentMatch (1.3.6.1.4.1.1466.115.121.1.38)
  syntax is defined in [Syntaxes].
(Continue reading)

Permalink | Reply | 501 comments |
headers
Kurt D. Zeilenga | 20 Dec 2003 22:27

Re: features-05 comments

Please note that this TS was recently published as RFC 3674.

I hope that this TS will be incorporated into the revised LDAP
TS being produced by the LDAPBIS WG.  If they do so, any known
issues should be addressed during that work.  Otherwise,
I will address them in some future update of RFC 3674.

At 12:07 PM 12/20/2003, Hallvard B Furuseth wrote:
>draft-zeilenga-ldap-features-05.txt says:
>
>> 2. Discovery of supported features
>
>>   A client may examine the values of this attribute to
>>   determine if a particular feature is supported by the server.  A
>>   client MUST ignore values it doesn't recognize as they refer to
>>   elective features it doesn't implement.
>
>What's the point of the last sentence?  What else could the client do
>with a feature it doesn't know about?

Not ignore the unrecognized feature.  That is, fail to continue
processing due to presence of a unrecognized value in
'supportedFeatures'.

>>   The 'supportedFeatures' attribute type is described as follows
>
>...", using the AttributeTypeDescription syntax described in [Models]"  
>
>(and [Models] must be added to the References section).
(Continue reading)

Permalink | Reply | 502 comments |
headers
Kurt D. Zeilenga | 20 Dec 2003 22:37

Re: Referrals in draft-rharrison-ldap-intermediate-resp-01.txt

At 02:45 AM 12/19/2003, Hallvard B Furuseth wrote:
>draft-rharrison-ldap-intermediate-resp-01.txt says:
>>   For example, the LDAP delete operation could be extended via a 
>>   subtree control to mean that an entire subtree is to be deleted.  A 
>>   subtree delete operation needs to return continuation references 
>>   based upon subordinate knowledge information contained in the server 
>>   so that the client can complete the operation.  Returning references 
>>   as they are found instead of with the final result allows the client 
>>   to progress the operation more efficiently because it does not have 
>>   to wait for the final result to get this continuation reference 
>>   information.  
>
>Subtree delete can't return references in the final result anyway,
>because from such a referral, only one operation should be performed on
>one of the returned URIs to progress the operation.  Subtree delete may
>need to return several continuation references.  Also, the referral
>result code means that the operation was not performed, not that it was
>partially performed.

The last sentence does confuse the example.  The issue is
not one of efficiency but functionality (adding support for
continuation references).  I'll ask that the last sentence of
this example be deleted during AUTH48.

>Also, 'ietf-ldapext <at> netscape.com' should be 'ldapext <at> ietf.org'.

That text will be deleted automatically by the RFC Editor.
(Note that the document is at the RFC Editor.)

Kurt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hallvard B Furuseth | 20 Dec 2003 22:43
Picon
Picon
Favicon

Re: features-05 comments

Kurt D. Zeilenga writes:
> I hope that this TS will be incorporated into the revised LDAP
> TS being produced by the LDAPBIS WG.  If they do so, any known
> issues should be addressed during that work.  Otherwise,
> I will address them in some future update of RFC 3674.

If you mean further discussion should wait, this will be my last
message until then.

>At 12:07 PM 12/20/2003, Hallvard B Furuseth wrote:
>>> 2. Discovery of supported features
>>
>>>   A client may examine the values of this attribute to
>>>   determine if a particular feature is supported by the server.  A
>>>   client MUST ignore values it doesn't recognize as they refer to
>>>   elective features it doesn't implement.
>>
>>What's the point of the last sentence?  What else could the client do
>>with a feature it doesn't know about?
> 
> Not ignore the unrecognized feature.  That is, fail to continue
> processing due to presence of a unrecognized value in
> 'supportedFeatures'.

Sounds like you are saying 'the client may instead be ridiculously
stupid'.  I don't think a MUST is needed to prevent that, or even that
it's any of our business if the client does this:-)

--

-- 
Hallvard
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kurt D. Zeilenga | 21 Dec 2003 00:27

Re: features-05 comments

At 01:43 PM 12/20/2003, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>> I hope that this TS will be incorporated into the revised LDAP
>> TS being produced by the LDAPBIS WG.  If they do so, any known
>> issues should be addressed during that work.  Otherwise,
>> I will address them in some future update of RFC 3674.
>
>If you mean further discussion should wait, this will be my last
>message until then.

No reason to defer discussion.  I was just letting you know
that how this specification will like be updated.

>>At 12:07 PM 12/20/2003, Hallvard B Furuseth wrote:
>>>> 2. Discovery of supported features
>>>
>>>>   A client may examine the values of this attribute to
>>>>   determine if a particular feature is supported by the server.  A
>>>>   client MUST ignore values it doesn't recognize as they refer to
>>>>   elective features it doesn't implement.
>>>
>>>What's the point of the last sentence?  What else could the client do
>>>with a feature it doesn't know about?
>> 
>> Not ignore the unrecognized feature.  That is, fail to continue
>> processing due to presence of a unrecognized value in
>> 'supportedFeatures'.
>
>Sounds like you are saying 'the client may instead be ridiculously
>stupid'.  I don't think a MUST is needed to prevent that, or even that
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hallvard B Furuseth | 21 Dec 2003 15:09
Picon
Picon
Favicon

Re: features-05 comments

Kurt D. Zeilenga writes:
>>>At 12:07 PM 12/20/2003, Hallvard B Furuseth wrote:
>>>>> 2. Discovery of supported features
>>>>
>>>>>   A client may examine the values of this attribute to
>>>>>   determine if a particular feature is supported by the server.  A
>>>>>   client MUST ignore values it doesn't recognize as they refer to
>>>>>   elective features it doesn't implement.
>>>>
>>>>What's the point of the last sentence?  What else could the client do
>>>>with a feature it doesn't know about?
>>> 
>>> Not ignore the unrecognized feature.  That is, fail to continue
>>> processing due to presence of a unrecognized value in
>>> 'supportedFeatures'.
>>
>>Sounds like you are saying 'the client may instead be ridiculously
>>stupid'.  I don't think a MUST is needed to prevent that, or even that
>>it's any of our business if the client does this:-)
> 
> Maybe so.  I likely put that statement just after dealing
> with a ridiculously stupid client.

Suggest s/MUST/can/.

--

-- 
Hallvard
Permalink | Reply | 0 comments |

Gmane