Subject: I-D ACTION:draft-ietf-ldapext-refer-00.txt

From: [email-masked]
Date: Fri, 14 Jul 2000 06:56:25 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the LDAP Extension Working Group of the IETF.

	Title		: Referrals in LDAP Directories
	Author(s)	: R. Hedberg
	Filename	: draft-ietf-ldapext-refer-00.txt
	Pages		: 13
	Date		: 13-Jul-00
	
This document defines two reference attributes and associated 'referral'
object class for representing generic knowledge information in LDAP
directories [RFC2251].
The attribute uses URIs [RFC1738] to represent knowledge,
enabling LDAP and non-LDAP services alike to be referenced.
The object class can be used to construct entries in an LDAP directory
containing references to other directories or services. This document
also defines procedures directory servers should follow when supporting
these schema elements and when responding to requests for which the
directory server does not contain the requested object but may contain
some knowledge of the location of the requested object.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-refer-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ldapext-refer-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ldapext-refer-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 14 Jul 2000 10:12:53 -0700

Roland,

Thanks for putting this together.

I would like to see alignment of named references (per old
nameref or my I-D) and this draft.  I view named references
(which supports only superior and subordinate knowledge
information) as a "base" (or "simple")  functionality.  I
would prefer that other knowledge information (cross, nssr)
be supported through extension of a "base" specification.
I prefer this approach as it allows progression of the
"base" specification separately from extensions (which are
likely require additional time to ready).

I think the WG direction given at IETF#46 is still quite
applicable: "The authors are requested to ensure that by
the next meeting we have a single base document on the
simple (base) referral behavior that is suitable for
last call to become a Proposed Standard."

I would be happy to work with you on ensuring that a
base specification was extensible.

Regards, Kurt

Comments inline.

Excerpts from Referrals in LDAP Directories
<draft-ietf-ldapext-refer-00.txt>:
> 1.  Background and intended usage
> 
>    The broadening of interest in LDAP directories beyond their use as front
>    ends to X.500 directories has created a need to represent knowledge
>    information in a more general way. Knowledge information is information
>    about one or more servers maintained in another server, used to link
>    servers and services together.
>                      
>    This document is based on the following basic assumptions:
> 
>    - several naming domains

s/domains/schemes/   There is only one domain, the global domain.
All naming schemes must produce names which are unique within this
domain. 

>    The usage of LDAP as a access protocol to other than X.500 servers has
>    created islands of directory service systems containing one or more
>    LDAP servers.

The usage of two access protocols did not create islands.  The
lack of infrastructure to manage knowledge information created
islands.  If there was adequate infrastructure, the multiple
access protocol issues (in theory) could be solved by gateways.

>	 Each of these islands are free to pick their own naming
>    domain.

Organizations are free to choose which scheme the choose to
obtain a name within.

>    And that they also do; some use the old country,organization,
>    organizationalUnit naming scheme[X.521], some use the newer domain name
>    based naming scheme but these two are in no way the only ones in use.

And many pull names out of thin air.  Only organizations which
used standard track naming schemes may partcipate in the global
directory.   Knowledge information infrastructure provided for
each scheme varies, so some may have 'islands'.  However, the
protocol (and other models) supports knowledge information equally
well regardless of the naming scheme used.

This I-D proposes a model for managing knowledge information.  It
should be scheme independent.  As such, I find the discussion of
different naming schemes to be bit irrelevant and maybe better
left to other I-Ds.

>    The
>    existence of several naming domains are in itself no real problem as
>    long as they produce unique names for the objects in the directory.

Exactly.

>    Still naming schemes like the domain name based one, might easily create
>    non-continues naming structures because some toplevel domain names
>    might no find organizations that are interested and/or willing
>    to manage them. Therefor tree transversal might not longer be possible
>    except in parts of the whole tree.

This is true with traditional X.500 naming as well.

>       
>    - authoritive structure vs directory structure
>    In some instances even if a part of the tree is delegated to one
>    organization, the organization doing the delegation might want to
>    remain as the authority for the baseobject of the delegated tree.

The LDAP protocol may not be able to support such without modification.

Server A delegates the subtree "o=foo" to server B but remains
authority for "o=foo".  A subtree search for "o=foo" sent to A, A 
should return "o=foo" and a search continuation to B.  What would
the scope (implicitly or explicitly) of the LDAP URI provided
in the continuation?

subtree?  no, this would cause B to either return "o=foo" (if it
held a replica of this entry) or a referral (back to A or other)
or noSuchObject.  All are not acceptable.

>    - support for onelevel searches
>    At points in the tree where the responsibility for all or almost all
>    of the children of a object is delegated to different organizations
>    and resides in different directory servers a one-level search is not
>    very efficient if not supported by special facilities in the directory
>    as such.

I assume these special facilities do not change the semantics of 
protocol operations.

>    -- directory server discovery
>    LDAP servers that do not use dc nameing or are not registered with
>    SRV records in the DNS are very hard to find.

You generally do not need to discover the location of an LDAP
service which you have a LDAPURI for...

> 
>    This document defines a general method of representing knowledge
>    information in LDAP directories, based on URIs.
>    Two types of knowledge reference are defined: refer and subRefer.

subRefer?

> 2.1 The refer attribute
>    The refer attribute can be further specified by the use of options as
>    defined in section 4.1.5 of [RFC2251]. This document defines five
>    options and their use. Future documents might defined other options.
 
Is an option required?  If not, what is the semantics of an optionless
refer attribute?

I also question this use of options.  Are there better approaches?
I would suggest tieing the semantics of the attribute to object
classes and/or type of the DSE its contained in.  That is, a refer
in the root dse is a superior reference, a refer in a referral
object (objectclass=referral) is a subordinate, etc..

>    The options defined are:
>   "me", "sup", "cross", "nssr" and "sub" .
> 
>    'refer;me' is used to hold the reference of this server, and is always
>    held in the root DSE
> 
>    'refer;sup' is used to hold the reference of a server superior to this
>    one in this global LDAP naming domain e.g. a server holding the dc=com,
>    dc=se, or the c=se node. The 'refer;sup' is always held in the root DSE.
>    'refer;cross' indicates that this is a cross reference pointing to another
>    naming context within or outside this global LDAP naming domain.
 
Suggest striking "within or outside this global LDAP naming domain".
Naming schemes should be immaterial in the context of this draft.

>    'refer;sub' indicates that this is a subordinate reference pointing to
>    a subordinate naming context in this global LDAP naming domain.

Suggest striking "in this global LDAP naming domain".
Naming schemes should be immaterial in the context of this draft.
 
>    'refer;nssr' indicates that this is a non-specific subordinate reference
>    pointing to a subordinate naming context in this global LDAP naming domain.
 
Suggest striking "in this global LDAP naming domain".
Naming schemes should be immaterial in the context of this draft.
 
> 
> 3. Use of the knowledge attribute

I would prefer to attach the semantics of 'refer' attribute
to the DSE type and if an entry DSE to an object class.  In
the case of subordinate referrals, a structural object class
works well (semantics of DSE are established at instantiation
time).  For superior referrals, presence in the root DSE is
sufficient.

> 4 Behaviour specification
> 
> 4.1 Name resolution for any operation
> 
>    Clients SHOULD perform at least simple "depth-of-referral count" loop
>    detection by incrementing a counter each time a new set of referrals is
>    received.

Client behavior is specified by RFC2251.  This statement replaced
with a statement using wording found in RFC2251 with a clause
"as per RFC2251".

> 4.2.1 base-level
> 
>    If the entry matches the filter and does NOT contain a refer attribute
>    it will be returned to the client as described in [RFC2251].
>    If the entry matches the filter contains a refer attribute without
>    the 'nssr' option it will be returned as a referral as described here.
 
referral or search continuation?

>    If a matching entry contains a refer attribute and the URI
>    contained in the refer attribute is NOT an LDAP URI [RFC2255],
>    the server should return the URI value contained in the refer
>    attribute of that entry in a SearchResultReference.
>         
> 
> Hedberg           Expires September 30, 2000                    [Page 5]
> 
> Internet-Draft    LDAP Knowledge references                   July 2000
> 
> 
>    If a matching entry contains a refer attribute in the LDAP
>    URI syntax, the server will return an SearchResultReference
>    containing the value(s) of the refer attribute minus any optional
>    trailing whitespace and labels that might be present.

Wouldn't the server have returned a referral as directed above?
Is this for the with nssr case?  If so, some clarification would
be useful.

>    The URL from the refer attribute must be modified before it is
>    returned by adding or substituting a "base" scope into the URL. If the
>    URL does not contain a scope specifier, the "base" scope specifier must
>    be added. If the URL does contain a scope specifier, the existing scope
>    specifier must be replaced by the "base" scope.
>
> 4.2.2 One-level
> 
>    Any entries matching the filter and one level scope that
>    do NOT contain a refer attribute are returned to the client normally as
>    described in [RFC2251]. Any entries matching the filter and one level
>    scope that contains a refer attribute without the 'nssr' option must
>    be returned as referrals as described here.

s/referrals/search continuations/

> 
>    If a matching entry contains a refer attribute and the URI
>    contained in the refer attribute is NOT an LDAP URI [RFC2255],
>    the server should return the URI value contained in the refer
>    attribute of that entry in a SearchResultReference.
>         
>    If a matching entry contains a refer attribute in the LDAP
>    URI syntax, the server will return an SearchResultReference
>    containing the value(s) of the refer attribute minus any optional
>    trailing whitespace and labels that might be present.
>    The URL from the refer attribute must be modified before it is
>    returned by adding or substituting a "base" scope into the URL. If the
>    URL does not contain a scope specifier, the "base" scope specifier must
>    be added. If the URL does contain a scope specifier, the existing scope
>    specifier must be replaced by the "base" scope.
> 
> 4.2.3 Subtree search evaluation
> 
>    Any entries, held by the server, matching the filter and
>    subtree scope that do NOT contain a refer attribute or contains
>    a refer attribute with the 'nssr' option are
>    returned to the client normally as described in [RFC2251].
>    Any entries matching the subtree scope and containing a refer
>    attribute must be returned as referrals as described here.

s/referrals/search continuations/ 

>    If a matching entry contains a refer attribute and the URI
>    contained in that attribute is NOT an LDAP URI [RFC2255],
>    the server should return the URI value contained in the refer
>    attribute of that entry in a SearchResultReference.
>  
> 
> 
> 
> 
> Hedberg           Expires September 30, 2000                    [Page 6]
> 
> Internet-Draft    LDAP Knowledge references                   July 2000
> 
>    If a matching entry contains a refer attribute in the LDAP
>    URI syntax, the server will return an SearchResultReference
>    containing the value(s) of the refer attribute minus any
>    optional trailing whitespace and labels that might be present.
> 
>    N.B. in subtree search evaluation a entry containing a 
>    refer attribut with the 'nssr' option might appear twice in the
>    result, first as a entry and then as a reference. A client
>    following all references might therefore end up with a resultset
>    containing two representations of the same entry, one from the
>    server getting the original query and one from the server 
>    that the 'nssr' reference points to.

A (non-extended) search operation should not return the same
entry multiple times.  If a server returns a search continuation
that server must be capable of completely the operation.  It
is inappropriate for it to return entries which were returned
by other servers as part of a single distributed search operation.
 
> 5. The referral object class
> 
>    The referral object class is defined as follows.
> 
>    ( 1.2.752.17.2.10
>      NAME 'referral'
>      SUP top
>      STRUCTURAL
>      MAY ( refer ) )
 
I suggest this new object class use a new name.
I suggest LDAPreferral.

>    The referral object class is a subclass of top and may contain the
>    refer attribute.

What are the semantics associated with a referral object without an
refer attribute?  Which such an entry be normally visible? 

>	The referral object class should, in general,
>    be used in conjunction with the extensibleObject object class to support
>    the naming attributes used in the entry's distinguished name.
 
I suggest stating that the refer attribute itself should NOT be used
for naming purposes.

>    Servers must support the refer attributes through use of the
>    referral object class. Any named reference must be of the referral
>    object class and will likely also be of the extensibleObject object
>    class to support naming and use of other attributes.
> 

For all uses of refer?  This seems odd.

---

From: "Steven Legg" <[email-masked]>
Date: Wed, 19 Jul 2000 18:42:58 +1000

Kurt,

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Saturday, 15 July 2000 3:13
> To: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-ldapext-refer-00.txt
> 
> 
> Roland,

[snip]

> object (objectclass=referral) is a subordinate, etc..

I would rather not tie the semantics to the object class, for the sake of
replication. If an entry is represented by its appropriate object class
in one server and by an entry with one of the referral classes in another
it presents a problem to any server replicating from both sources.
What is the object class of the merged object ? Better if the referencing
entry is a DSE with no object class, or has the same object class as
the referenced entry.

I'd prefer to use separate attributes instead of separate options to convey
the semantics but that's not critical.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 19 Jul 2000 08:37:21 -0700

At 06:42 PM 7/19/00 +1000, Steven Legg wrote:

>What is the object class of the merged object ?

This would be a replication error as one server was not using
standard track representation of the referral object.

>Better if the referencing
>entry is a DSE with no object class,

My primary reason of suggesting use of object classes, especially
for subordinate references, is that the semantics need to be
established when the entry is instantiated.  The DSE type associated
with the object should be immutable.

>or has the same object class as
>the referenced entry.

Then the object would be required to have all the required attributes
of these classes.

>the semantics but that's not critical.

This would at least remove the question "what are the semantics
of an optionless 'refer' attribute?".

---

From: "Steven Legg" <[email-masked]>
Date: Thu, 20 Jul 2000 12:16:11 +1000

Kurt,

> Sent: Thursday, 20 July 2000 1:37
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt
> 
> 

That would be so if server A and server B both had references to some
third server, but I was talking about the situation where server A
masters the entry, server B has a reference to the entry in server A,
and server C replicates from both server A and server B. Server A tells
server C that the object class is say, organization, while server B tells
server C that the object class is referral.

Where a DSE is a placeholder for an entry that isn't held locally that
DSE shouldn't contain shared information that contradicts the remote
master entry. It's painful for replication if it does.

> with the object should be immutable.

The DSEType is not immutable in X.500 and is also permitted to be
different between servers having knowledge of the same DN. What is "glue"
for one server will be "entry" for another and maybe "shadow" as well
for a third. The semantics of the reference can be established just as
well from the attribute type or from the attribute type and option.

> Then the object would be required to have all the required attributes

That depends on how you interpret clause 19 of X.501:1993. It might be
legal for a DSE that is not of type "entry", "alias" or "subentry" to
have an objectClass attribute without all the mandatory attributes.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 19 Jul 2000 21:29:24 -0700

>> >> Is an option required?  If not, what is the semantics of 

No answer to this yet.

>server C that the object class is referral.

Yes, this is quite different.  This requires C to maintain clear
separation of information which A is authority over and information
which B is authority over and to restrict updates to accordingly.

>master entry. It's painful for replication if it does.

The proposal suggests using named entries to representing references.
For a subordinate reference, it proposes that this object have
an attributes associates with naming, object class referral, and
object class extensible object.  This information my be in
contradiction with the actual entry DSE it refers to.

When DSE are replicated, receiving server must have a clear
mechanism for determining the update is associated with the
portion of the DSE.  I've suggested one approach, there are others.

>> established when the entry is instantiated.

This is my primary concern.  I am not sure it makes sense
to change an entry into an subordinate reference just by
adding a 'refer' attribute.  I believe you should have to
delete the entry and add a 'referral' entry.  I also think
that a 'referral' entry MUST have a 'refer' attribute.

>The DSEType is not immutable in X.500

Correct, I should have said that DSEtype is not modifiable by the
user.

The implication is that certain DSEtype changes make little
(or no) sense and using the presence or lack of presence of
an attribute type (or types) to indicate such may not be
optimal.

>have an objectClass attribute without all the mandatory attributes.

The proposal models references as entries, with object classes,
with RDN attributes, with musts/may requirements.

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 21 Jul 2000 15:47:58 +1000

Kurt,

> Sent: Thursday, 20 July 2000 14:29

I thought that was a question for Roland, but if you want my opinion,
it doesn't mean anything. Optionless refer attributes are ignored.

> which B is authority over and to restrict updates to accordingly.

You're sort of progressing down the path of X.525's planes of information,
which is fine for single master replication but isn't meaningful in a
multi-master environment where servers have joint authority over
shared data. There really needs to be only one version of the shared data
for multi-master replication.

> portion of the DSE.  I've suggested one approach, there are others.

To be replication friendly, information in a DSE that is different from
one server to another needs to be in DSA-specific attributes if it is
reflected in any attributes at all. In X.500 the specialness of DSEs
containing references to other DSAs is captured in the dseType,
a DSA-specific operational attribute. It looks to me that LDAP needs
something like it, though in this case the refer attribute itself
would be enough. Roland's description of the processing that takes place
depends only on the presence of the refer attribute. The object class
of the entry containing the refer attribute doesn't get a mention that
I could see. The definition of the referral object class near the end
is pretty much incidental.

> that a 'referral' entry MUST have a 'refer' attribute.

If you add a refer attribute to an existing entry then the other
attributes in the entry become meaningless and might as well
be removed. An LDAP DSE type attribute would help if you feel there is a
need to make a more emphatic display of the fundamental change in the
nature of the DSE.

With LDUP it would be possible for a replica to hold both the
actual entry contents and the refer attribute, which is basically what
you get if you just add a refer attribute to an existing entry.
We would need to define what that means. A refer attribute in a read-only
replica is effectively a reference to the server(s) holding the master
entry. Whether you send back a referral in this case would depend
on things like the X.500 dontUseCopy service control. A refer attribute
in a writeable replica could be a self-reference to the server or a
reference to one of the other mastering servers for that entry. In either
case the refer attribute is ignored. Anything else is processed as
Roland describes. 

> Correct, I should have said that DSEtype is not modifiable by the

Not directly, but user actions can affect the DSEType. For example,
adding/removing the administrativeRole attribute changes the admPoint
bit in the DSEType.

> an attribute type (or types) to indicate such may not be

Do I take this to mean that you like the fact that an object class
definition mandates what can and can't be in a referral DSE?
There are other ways to do that, like writing down the requirements, 
which is how X.500 deals with the permitted usage of most of the
operational attributes.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 Jul 2000 02:01:30 -0700

>You're sort of progressing down the path of X.525's planes of information,

Well, I'm trying to understand the referral model were proposing.
Is it the X.500 model with planes of information with DSAspecific,
DSAshared, distributed operational attributes or something
else.  It seems we're mixing in new ideas which are not well
defined.

In particular, the old namedref proposal (and my updated version)
seems much akin to DNS zone delegation model than the X.500 model.
(Which needs to be better specified)

Rolands proposal seems to mix of the two models which I find
quite confusing.

>for multi-master replication.

I think the DNS zone delegation model better support multi-master
environments.  However, it has other limitations (such as upon
the types of knowledge information that can be represented).

>reflected in any attributes at all.

Yes, but 'refer' is distributedOperation and, if DSA-specific, why
would your replicate it?

>In X.500 the specialness of DSEs

Excepting when creating an entry to represent a subordinate referral...

>be removed.

But the server can hold both the entry and the referral DSE.
Are saying it cannot hold both?

>An LDAP DSE type attribute would help if you feel there is a

What I think is we either need to follow more closely the X.500
model (including planes of information) or we describe another
model.

>you get if you just add a refer attribute to an existing entry.

Note you just said the entries contents are ignored if a 'refer'
attribute is present.

>We would need to define what that means.

Exactly.

>definition mandates what can and can't be in a referral DSE?

This too!  I like the fact that referral object class is structural
and disallows certain modifications of the allowed/required attributes.

>which is how X.500 deals with the permitted usage of most of the

Yes.

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 24 Jul 2000 16:25:05 +1000

Kurt,

> Sent: Friday, 21 July 2000 19:02

The referral model is what Roland described except that it needs to be
generalized to account for the effects of replication, and some of the
details of the distribution knowledge representation could be different
to avoid compromising LDUP.

> else.  It seems we're mixing in new ideas which are not well

Some of it is well defined and well practiced in X.500 but we still need
the new ideas because of the consequences of multi-master replication.

> Rolands proposal seems to mix of the two models which I find

I'm not familiar with DNS zone delegation so Roland's proposal looked
to me like it was inspired just by the X.500 distributed knowledge model.
It has the same sorts of references in the same sorts of places.

> the types of knowledge information that can be represented).

After a quick read of the DNS RFCs I have two, possibly bogus,
observations to make.

Firstly, DNS doesn't look like a multi-master environment.
All name servers holding authoritative data for a particular zone
can trace back to the same original configuration file. All changes
occur at, and are propagated from, this original file. That's single
master replication even though the single master is just a text file.

Secondly, the resource records are the same everywhere they are stored
regardless of whether they are cached or authoritative, and regardless
of what name server holds them. DNS would be messy if the records were
represented differently depending on location, just as LDUP/URP will be
messy if shared data has different representations depending on the
context of the directory server.

> Yes, but 'refer' is distributedOperation and, if DSA-specific, why

In this case the DSA specific data is whether the DSE represents a
reference or entry contents. It's one, or the other, or with LDUP it
can be both. This varies from server to server.
In X.500 that information would be held by the dseType (DSA-specific).
For the moment I'm assuming that the presence of the refer attribute
tells us the DSE is a reference without it saying anything about whether
the DSE has normal entry content.

The shareable data is the refer attribute (distributedOperation
is appropriate) and any other non-DSA-specific entry contents
(including the object class).

> Excepting when creating an entry to represent a subordinate 

Yes, "near the end". The presence of the referral object class is
incidental to the task of generating referrals.

> Are saying it cannot hold both?

Sorry for the confusion. There's important context that I neglected
to make explicit. For a DSE that contains both referral information
and entry contents;

If the DSE is in an area of replication that is singly or jointly mastered
and the refer attribute references the server itself, or one of the other
masters, then the entry contents are used and the refer attribute is
ignored.

If the DSE is in an area of replication that is read-only and the refer
attribute references the server itself then the refer attribute is ignored.
If the refer attribute references some other server it will be a master,
so whether the entry contents or a referral is returned will depend
on service controls like dontUseCopy.

If the DSE is not in an area of replication and the refer attribute
references the server itself the refer attribute is ignored.

Otherwise the entry contents are ignored.

Of course the above would need to be generalized to account for multiple
values of the refer attribute.

> model (including planes of information) or we describe another

Some aspects of the X.500 distribution and/or replication model are
worth using for both DISP and LDUP compatibility (like the clean
separation between DSA-shared and DSA-specific data) but other
aspects don't apply in the multi-master environment (like planes of
information). What we need is not quite like anything that has gone
before in the directory space.

> Note you just said the entries contents are ignored if a 'refer'

Yeah, sorry again.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 24 Jul 2000 01:14:56 -0700

As I think this thread has gone astray and suggest we
discontinue it for now.  Not to mean that I'm dropping
or conceding any particular position, just that I think
it will be hard to continue under the current thread.
Further clarification is need from the authors.  We
surely revisit the relevant issues later.

For now, I'll defer further discussion until the author
has a chance to respond to the specific questions I
asked in my first post in this thread.

http://www.openldap.org/lists/ietf-ldapext/200007/msg00135.html

Regards, Kurt

---

From: "David Chadwick" <[email-masked]>
Date: Tue, 25 Jul 2000 14:53:04 +0100

Steven said

> 
> I'd prefer to use separate attributes instead of separate options to
> convey the semantics but that's not critical.
> 

In fact the two can be the same to my mind. An option is an 
attribute subclass, and by defining an OID for the option/subclass, 
you achieve the same thing. (Similar to name and commonName)

> > >    defined in section 4.1.5 of [RFC2251]. This document defines
> > >    five options and their use. Future documents might defined 
> > other options.

In fact it defines six. If just forgot to describe refer;other at the start 
of the ID

> >  
> > Is an option required?  If not, what is the semantics of an
> > optionless refer attribute?

Good question. In fact, I would say that the attribute should always 
have an option defined. (just as we never use the name attribute on 
its own, but always a subtype of it)

However, there is one problem with the option/subtype route, and 
that is the DSAOperation vs. DistributedOperation question. I 
believe that some (sup, me) are for local DSAOperation use, whilst 
others (cross, sub, other) are domain replicable i.e. for 
DistributedOperation use. This is why in my 1998 ID I had TWO 
attribute types, named sharedRef and privateRef. I still think this 
requirement exists.

David
***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************