Subject: WG last call on "duplicate entries"

From: Roland Hedberg <[email-masked]>
Date: Fri, 23 Mar 2001 16:57:12 +0100

Hi !

The IETF50 meeting is sort of over, at least concerning LDAP. So I thought
I should start issueing the last calls that are in the pipe.

I will not issue all of them at once, to not tax your limited time available 
for document review too much.

LDAPEXTers,

The purpose of this message is to initiate the LDAPEXT
working group last call on the "LDAP Control for a Duplicate Entry 
Representation of Search Results" document.

WHAT DOCUMENT?

The document in last call is:

http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-dupent-06.txt

WHAT IS A LAST CALL FOR?

The purpose of the working group last call is to ensure
that the working group has reached consensus on the
document, believes that all the known outstanding issues
have been addressed, and is ready to put the document
forward for proposed standard status.

During the last call, any comments on the documents are
collected and discussed on the mailing list.

HOW LONG DOES IT LAST?

The last call starts today and will last approximately two
weeks. It will end on April 6th 2001

WHAT'S THE NEXT STEP?

After the last call completes, there are three possible
outcomes:

1) No changes are required and we request our ADs to put
   forward the documents to the IESG for informational
   status.

2) Minor changes agreed to on the list are required, and
   the documents are revised. We then ask our ADs to put
   forward the revised documents to the IESG for
   informational status.

3) Major issues are raised and no consensus is reached on
   the list. In this case, we slink back and discuss
   things until consensus is reached, at which time another
   working group last call will be issued.

Assuming we achieve outcome 1) or 2), and that the ADs
agree with our assessment, the next stop for the documents
is with the IESG. The IESG reads them and may approve the
documents (with or without changes), or send the documents
back to the working group to have major issues addressed.

If the first outcome happens, the documents are put forward
for a two-week last call to the entire IETF, and after
successful completion the documents are published as RFCs
with proposed standard status.

If the second outcome happens, we go back and address
the issues, putting the documents forward again when we
believe they're ready.

WHAT SHOULD YOU DO?

You should read the documents, making sure that 1) there
are no problems or deficiencies or outstanding issues that
need to be resolved; and 2) that there are no typos,
formatting problems, grammatical errors, etc.

Any substantive problems you find, you should send to the
list. Any minor problems (typos, etc.) you may send to the
list or just to the authors. If, for some reason, you have
comments you don't want to send to the entire list, you may
send them to me or my co-chair Mark Wahl.

Silence means consent.

Read, enjoy, and send your comments in!

regards,
Roland Hedberg and Mark Wahl

---

From: Dave Watts <[email-masked]>
Date: Mon, 26 Mar 2001 09:33:18 +0100

Jim,

I have a minor query about draft-ietf-ldapext-ldapv3-dupent-06.txt.

Section 4.1.1 contains the following paragraph.

   <snip>

   While processing a search request, a server implementation examines
   this list.  If a specified attribute or attribute subtype exists in
   an entry to be returned by search, and that attribute holds multiple
   values, the server treats the entry as if it were multiple,
   duplicate entries -- the specified attributes each holding a single,
   unique value from the original set of values of that attribute.

   <snip>

When you talk about attribute subtypes, are you thinking of:
- subtyping via attribute options (eg 'cn;lang-en' is a subtype of 'cn')
- subtyping via attribute hierarchy (eg 'cn' is a subtype of 'name')
- both?

I'd guess you didn't intend subtyping via attribute hierarchy, because
you want to align with RFC RFC2891 (server-side-sorting) as far as possible.
Although RFC2891 doesn't explicitly discuss subtyping, I don't think it
intends subtyping via attribute hierarchy (and so is aligned with X.511).

Either way, I suggest you add a small clarification to the above paragraph.

Cheers,

David

-----Original Message-----
From: Roland Hedberg [mailto:[email-masked]]
Sent: 23 March 2001 15:57
To: [email-masked]
Subject: WG last call on "duplicate entries"

Hi !

LDAPEXTers,

WHAT DOCUMENT?

WHAT IS A LAST CALL FOR?

HOW LONG DOES IT LAST?

WHAT'S THE NEXT STEP?

WHAT SHOULD YOU DO?

Silence means consent.

regards,

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 26 Mar 2001 06:57:07 -0800

>   unique value from the original set of values of that attribute.

I would suggest a minor editorial change.
s/attribute or attribute subtype/attribute or its subtype/

>- subtyping via attribute hierarchy (eg 'cn' is a subtype of 'name')

I believe this sentence is the result of prior list discussion.  The
answer is both.  This is consistent with how requested attributes in
search operations are handled in LDAP/X.500.

---

From: Dave Watts <[email-masked]>
Date: Tue, 27 Mar 2001 09:48:41 +0100

Kurt, Jim,

"Both" is a fine answer, but I'm not sure Kurt's suggested minor editorial
change clarifies things explicitly enough. We could add something like the
following to 4.1.1 (or made into a 4th example in section 5).

...

For the purposes of determining multi-valuedness, values of subtypes are
treated as if they were values of the supplied attribute.  eg 'cn;lang-en'
is a subtype of 'cn' is a subtype of 'name', so an entry with
  cn: Johann
  cn;lang-en: John
is considered to have two values of 'name'.

....

This makes things completely explicit, but you might consider it
over-the-top. Your call.

Cheers,

David

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 27 Mar 2001 01:50:05 -0800

>is considered to have two values of 'name'.

That's not how I believe it should be viewed.

If you dupliate 'name' and you have:
        cn: Johann Smith
        cn: John Smith
        sn: Smith

You should get back two entries, one with
        cn: Johann Smith
        sn: Smith

and one with
        cn: John Smith
        sn: Smith

that is, requesting duplication of 'name' implies requesting
duplication of 'name' and its subtypes.

---

From: Dave Watts <[email-masked]>
Date: Tue, 27 Mar 2001 16:29:12 +0100

Kurt,

I'm not sure I agree here.

In your example, duplicating 'name' and an entry ...
        cn: Johann Smith
        cn: John Smith
        sn: Smith

... I'd treat values of 'cn' and 'sn' as if they were all values of the same
att 'name', and thus expect 3 entries to be returned:

  one with
        cn: Johann Smith

  one with
        cn: John Smith

  and one with
        sn: Smith

I think this aligns better with how values would be sorted (although RFC2891
doesn't explicitly talk about subtyping at all).

Whatever, it must mean that it's worthwhile adding a new example section 5.4
to the RFC to illustrate unambiguously how to treat subtypes.

Cheers,

David

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: 27 March 2001 10:50
To: Dave Watts
Cc: [email-masked]'; [email-masked]'; [email-masked]
Subject: RE: WG last call on "duplicate entries"

and one with
        cn: John Smith
        sn: Smith

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 28 Mar 2001 10:02:12 -0800

>att 'name', and thus expect 3 entries to be returned:

But's not how subtypes are treated in general.  When you do a
search and ask for 'name' back.  A separate attribute for name
and each subtype of 'name' is returned.

>doesn't explicitly talk about subtyping at all).

I think without clarification to RFC 2891, it's unclear to how
any dupent subtype handling aligns with RFC 2891.  However,
as this control is specifically designed to (optionally)
be used in conjunction with a sort control, I think we should
first discuss on RFC 2891 treats subtypes.

The question, I guess, is whether or not it makes sense for
a single sort key to encompass multiple attribute types
(though subtyping).  My initial opinion is that it doesn't.
If this is the consensus view, it may actually be best to
revert the behavior of dupent so that it only duplicates
explicitly specified attribute types.  Of course, this could
be optional behavior (yet another BOOLEAN), as the
subtyping I describe (which I believe is consistent with
the I-D) is also useful.

---

From: Dave Watts <[email-masked]>
Date: Thu, 29 Mar 2001 20:23:41 +0100

Kurt,

I agree that we should clarify RFC2891, and then make the dupent I-D
consistent with that.

In terms of how we should clarify it, we disagree. I think it's more natural
from a user point of view (though in general harder to implement!) that
sorting should encompass subtypes. If sorting (and hence dupent) does
include subtypes, then we further disagree on what this actually means.

My opinion isn't particularly strong on sorting and subtypes - it's more
important to agree on something which is well-defined.

Cheers, 

David

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 29 Mar 2001 23:33:40 -0700

FWIW, Kurt's example below reflects the original intent. Any attribute you specify represents that attribute and any subtypes (whether by "natural" attribute subtyping or via attribute description option(s)). If an attribute is specified that has subtypes, it is analogous to specifying that attribute and all its subtypes (as a sequence of attribute descriptions). I believe this is most consistent with the way attribute subtypes are handled in other scenarios (especially when requesting attributes to be returned from search).

That said, the draft is weak on specifying this behavior, and I can fix. 

I don't know how to best resolve with 2891.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 3/27/01 2:50:05 AM >>>

and one with
        cn: John Smith
        sn: Smith