Re: RFC 2255bis

[mcs@netscape.com (Mark C Smith)]

> >>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 10/24/00 1:54:28 PM >>>
> >At 11:27 AM 10/24/00 -0600, Jim Sermersheim wrote:
> >>I have a few issues with this document that I'd like to see resolved.
> >> 
> >>1) References to RFC 1738. Can we update these to 2396 and make the appropriate
> section changes?
> >
> >I believe it's general practice to update all references to the
> >latest incarnation of the technical specification.

Definitely something we should do.


> >
> >>1) Allow the use of <userinfo>@<host>:<port> (RFC 2396) rather than hostport. This provides a more consistent
> alternative to using !bindname=jimse
> >
> >Note that !bindname=jimse is invalid, value should be a DN.
>  
> Oh yeah, oops.
> 
> >It would be interesting to see there has been work to use
> >userinfo to specify SASL authentication (and TLS) information
> >in an URI-scheme independent manner.
>  
> Yes, we should look into that.

I hope someone else has done some work on this, because I think this is
a messy area.  That does not necessarily mean we shouldn't tackle it.


> 
> >>2) Missing search constraints: The following elements of a search request are missing. derefAliases, size/timeLimit,
> typesOnly. We need some of these to be available, specifically for referrals and search continuations.
> >
> >Is there a need for the continued search to operate under different values
> >of these elements?  That is, are there cases where reuse of the elements
> >in the request to be continued is not possible?
>  
> Well, the search continuation case might not be as strong. I suppose size/time limits
> could be specified back to the client due to those limits being partially exhausted.

I vote for keeping the mechanism as simple as possible.  Clients can
make reasonable choices for size and time limits, because these are
typically used only to keep resource consumption down.  I think it just
complicates things to allow servers to suggest limits in the referrals
or continuation references.


> >>3) BNF grammar. It would be nice if the document specified what flavor of BNF is being used in section 3.
> >
> >On a general BNF note, I'd like to see all LDAP Technical Specifications
> >use the same ABNF.  I suggest that we use the ABNF as described in RFC
> >2234 (which should be progressed to Draft Standard before we're ready
> >to progress anything to Draft Standard).
>  
> I agree.

Me too.

-Mark