[Date Prev][Date Next] [Chronological] [Thread] [Top]

Summary of changes in protocol-24

Kurt asked me to take time to create a summary of the changes to the most recent doc followed by the remaining issues. If you want to skip this (I know I do), just continue to pay attention to the substantive changes sections at the end of the document.

Changes:

- changed [LIMR] to RFC 3771 and removed associated RFC editor notes (editorial)

- changed 'stream' to 'connection' and 'connection' to 'LDAP exchange' (editorial)

- updated the control combination instructions which will change again, so I'm not going to bother summarizing. (substantive)

- required that clients not send async operations during a bind operation, and suggested that servers not process or respond to async messages while a bind is in process. (substantive)

- updated the compare operation section as agreed on list (distilled down to say that the comparison results in true, false, or an appropriate error) (substantive * well not really when compared to 2251)

- updated Appendix C with the three substantive changes listed above in a much more readable and friendly way than in this email. (editorial)

- minor editorial changes (punctuation, parenthesis changes, etc.) (editorial)


Unresolved Issues:

- control combinations with unknown semantics, or appropriate controls (whatever we're calling the discussion these days)

- definition of "outstanding operations" http://www.openldap.org/lists/ietf-ldapbis/200405/msg00014.html 

- review http://www.openldap.org/lists/ietf-ldapbis/200405/msg00021.html 

- review a mail from Hallvard (attached)

Jim

p.s. I'm taking a vacation beginning Tuesday April 18th and ending Wednesday June 2nd (two weeks). If we reach consensus on any of the above issues in the next couple days, I can update and submit, otherwise my next submission won't likely be until the second week of June.
--- Begin Message --- 
protocol-23 says:

> 4.14.3. Removal of the TLS Layer

>    Two forms of TLS layer

removal

>    -- graceful and abrupt -- are supported.


> 5. Protocol Encoding, Connection, and Transfer
>
>    This protocol is designed to run over connection-oriented, reliable
>    transports, where the data stream is divided into octets (8-bit
>    units), with each octet being significant.
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This change since protocol-22 goes against message
<http://www.openldap.org/lists/ietf-ldapbis/200404/msg00022.html>:

>From: "Jim Sermersheim" <jimse@novell.com>
>> That all bits in an octet are significant need not be stated; that's
>> what anyone would assume unless the opposite was specified.
>
> One would think so but...
>
> We added this because some implementations are wrongly truncating
> attribute values as they come off the wire, and subsequent client
> complaints spurred many hours of discussion on the topic.

Maybe it should be "with each bit in each octet being significant"?


>    Implementations of LDAP over TCP MUST implement the mapping as
>    described in Section 5.3
                            ^^^
Missing period.


About placement of section 5.1: Did you lose the end of this message, or
do you just disagree?
<http://www.openldap.org/lists/ietf-ldapbis/200403/msg00093.html>
> Message-Id: <HBF.20040313inru@bombur.uio.no>
> From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
> Date: Sat, 13 Mar 2004 12:40:06 +0100
> Subject: Re: protocol-22 comments
>
> (...)
>
>>>> 5.2. Transfer Protocols
> 
>>> I think the rest of
>>> the paragraph belongs in a separate section '5.2.2 Connection Closure
>>> Effects'.
>
> Um... on second thought, it fits better as section 4.2 or 4.15.  This
> text is about which directory operations to perform in a particular
> situation.  The rest of section 5 is about transfer protocols and has
> nothing to do with directory operations.
>
>>>>    Protocol operations are tied to a connection, thus if the
>>>>    connection is closed or dropped, the operation is aborted. When this
>>>>    happens, any outstanding operations on the server are, when possible,
>>>>    abandoned, and when not possible, completed without transmission of
>>>>    the response.

-- 
Hallvard

--- End Message ---