Subject: [ldapext] features-05 comments

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 20 Dec 2003 21:07:45 +0100

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].

>   Servers MUST be capable of recognizing this attribute type by the name
>   'supportedFeatures'.  Servers MAY recognize the attribute type by
>   other names.

I don't think the last sentence is necessary.  I can find no similar
statement about other attribute types in [Models] or [Schema], yet I
assume they can be referred to with other names too.

-- 
Hallvard

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 20 Dec 2003 13:27:33 -0800

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.

>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'.

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

Such elaboration may have been nice (with a reference to the
current RFCs).  I'll note this for later updating of this TS.

>  syntax is defined in [Syntaxes].

Such elaboration may have been nice (with a reference to the
current RFCs).  I'll note this for later updating of this TS.

>assume they can be referred to with other names too.

The preceding MUST could be viewed as limiting the server
to only recognizing the attribute by the 'supportedFeatures'
name.  The MAY clarifies that servers are allowed to recognize
this attribute by other names.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 20 Dec 2003 22:43:07 +0100

> 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.

> processing due to presence of a unrecognized value in

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 20 Dec 2003 15:27:44 -0800

>If you mean further discussion should wait, this will be my last

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

>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.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 21 Dec 2003 15:09:03 +0100

> with a ridiculously stupid client.

Suggest s/MUST/can/.

-- 
Hallvard