Regarding 4. Sorting, Paging and Scrolling
I was one of the people that asked about the addition of a cookie exchange for
virtual list views, and have a known case where it is needed. I think that this
should be added to the current draft prior to going to last call.
There was one question asked on virtual list views: there didn't seem to
be a cookie exchange in the protocol, which Mark Smith said was by
design.
WG ACTION: The Virtual List Views and Server-side Sorting drafts will be sent
to working group last call to become standards track.
WG ACTION: The simple paged draft will be published as Informational, not as
standards track.
Cheers
RFW
Mark Wahl wrote:
> Minutes for LDAPEXT Meeting at Chicago IETF
> Reported by Mark Wahl
>
> 1. Recommended Authentication Methods for LDAP draft
>
> There is a requirement for interoperability between implementations
> that perform updates to the directory. The IESG had added a note to the
> LDAPv3 RFCs stating this interoperability would potentially only be
> possible with exchange of passwords in the clear. Therefore the
> recommended authentication methods draft and related "Start TLS" draft
> addressed defining an authentication method better than passwords in the
> clear that would be mandatory for LDAP implementations to support.
>
> It was noted that the mandatory to implement algorithm is not
> mandatory for any organization to deploy.
>
> The Start TLS document passed last call with minor edits.
>
> The authentication methods draft did not successfully complete last
> call, primarily as there was significant discussion on the choice of
> authentication mechanism.
>
> There were four options discussed at the meeting:
> 1) The document as is: make CRAM-MD5 mandatory for updates,
> 2) Use another existing SASL mechanism,
> 3) Wait for a new mechanism to be defined,
> 4) Make Start TLS (encryption service) mandatory
>
> The area director Patrik Falstrom advised the WG that other documents
> produced by the WG that do not depend on this can go forward to IETF
> last call, so long as progress is being made on the mandatory-to-implement
> authentication method issued.
>
> This discussion focussed on:
> - was CRAM-MD5 viable?
> - is TLS acceptable to client vendors? Many vendors of clients present
> indicated they planned to implement TLS/SSL, although there were comments
> that it would not be acceptable to builders of embedded LDAP clients for
> small devices, and that it was overkill to encrypt an entire session just
> for a single password exchange.
> - Was there a need for a single mandatory to implement for all LDAP
> implementations, or could there be different profiles for different
> application requirements?
> - Would a situation in which there were a choice of mechanisms, of which a
> server must implement ALL but a client AT LEAST ONE, be acceptable?
>
> A pre-meeting on applications area mandatory to implement mechanisms had
> resulted in a plan by Chris Newman and Paul Leach to work on a new
> protected password mechanism that would be acceptable for use in many
> application area protocols and replace CRAM-MD5 and RFC 2069.
>
> The Start TLS draft will have its dependencies on the recommend authentication
> methods draft removed, and will progress. Should a new acceptable mechanism
> become available in a few weeks, the recommended authentication methods draft
> will have CRAM-MD5 replaced by that mechanism.
>
> WG ACTION: Start TLS to IETF last call
>
> 2. Access Control
>
> The WG chairs had sent a poll on the mailing list on how progress should
> be made on this topic. The results had been:
> - Should the WG work on this? yes
> - Was the requirements draft generally accepted? yes
> - Was the ACL Model draft generally accepted? no
> - Should X.500 ACLs be investigated further as the basis for LDAP? yes
> - Should just a framework, or a framework and model be defined? both
>
> A framework draft, based on that of the X.500, will be written and sent to
> the list before the next meeting.
>
> Bob Blakely discussed a new approach for building an access control model:
> define new protocol operations for "grant", "deny" and "get effective" rights.
> These could be specified with least common denominator subjects and rights
> information, and allow clients to modify and test access controls without
> needing to be aware of the encodings of access control inside the server.
> A quick poll showed a lot of interest in having minimum semantics, however
> the majority of the discussion on this approach was centered on the issue
> of how this information could be replicated. In particular, did there need to
> be a transfer syntax, and if so, how this would be different from the vendor's
> own representation format.
>
> WG ACTION: the requirements draft to go to WG last call
>
> 3. Language Tags
>
> The Use of Language Tags in LDAP draft had completed working group
> last call. It is not dependent on authentication methods.
>
> WG ACTION: send to IESG for IETF last call
>
> 4. Sorting, Paging and Scrolling
>
> There was one question asked on virtual list views: there didn't seem to
> be a cookie exchange in the protocol, which Mark Smith said was by
> design.
>
> WG ACTION: The Virtual List Views and Server-side Sorting drafts will be sent
> to working group last call to become standards track.
>
> WG ACTION: The simple paged draft will be published as Informational, not as
> standards track.
>
> 5. Referrals
>
> The referrals document had gone through last call and significant
> comments on it were received. This will be split into two separate
> drafts: one on the hierarchical (superior/subordinate refererence)
> use of referrals, and the other on a CIP-like mesh on referrals.
> The two drafts will progress independently, as the hierarchical part
> appears to have consensus to move to standards track, while the
> mesh part is still under discussion.
>
> 6. SASL mechanism for X.511 authentication
>
> There was not much interest seen at the meeting by vendors to
> implement or standardize this draft. It will go informational.
>
> WG ACTION: send to RFC editor as informational
>
> 7. Transactions
>
> The draft is going to be revised.
>
> 8. Persistent or Triggered Search
>
> The two drafts were to be merged into a single draft, and this has not
> yet occured. At least another revision will be needed.
>
> There were comments that the document does not caution safe use on the
> Internet and there had been little operational experience, so may not yet
> be suitable for being a Proposed Standard. The document may also need to
> refine or state its domain of applicablilty as a small number of clients.
>
> 9. Signed Operations
>
> The Signed Operations draft was not discussed as the authors were not
> present. Some comments were that it needed better clarification of
> purpose and a less generic title.
>
> 10. LDAP APIs
>
> The C API draft is nearly ready for last call after one more revision.
>
> The Java draft needs to be revised, and there were at least one set of
> comments on it.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature