[BXXPwg] issues list for pittsburgh meeting

Kurt D. Zeilenga Kurt@OpenLDAP.org
Mon, 24 Jul 2000 10:05:55 -0700


Marshall,

In my attempts to map LDAP onto BXXP, I found a number of issues
which may be appropriate to discuss at IETF#48.

1) Multiple response messages to one request
   LDAP allows one request to generate multiple responses.
   For example a search can generate any number of entry and
   continuation responses followed by a result response.

2) Request processing ordering
   LDAP allows responses to be processed independently of each
   other (with some "atomic" update restrictions).  Hence, results
   may be delivered in an order different from the requests.  And,
   in the face of 1, messages associated with different requests
   may be interleaved.

3) Requests which have no response
   LDAP has two requests, abandon and unbind, which solicit no
   server response.  This can be mapped on to BXXP (server
   send empty response, client ignores it).

4) Unsolicited Responses
   LDAP allows servers to send messages to clients without
   solicitation.  That is, no request is sent to request the
   response.  These may be mapped on to BXXP by having the
   LDAP server send a unsolicited response as a BXXP request
   and for the LDAP client to response with an empty
   BXXP response (which would be ignored by the server).

5) Start TLS
   It appears that the LDAP Start TLS operation cannot be mapped on
   BXXP as BXXP's Start TLS operation semantics call for
   channels to be dropped, which would cause authentication state
   changes incompatible with LDAP authentication model.

Regards, Kurt

At 11:42 PM 7/23/00 -0700, Marshall Rose wrote:

>in preparation for the working group meeting at the 48th IETF, i've compiled
>this list of issues that have been discussed on the mailing list and in
>other forums. if you feel an issue is missing or mis-represented, please
>reply to this message so we can correct that.
>
>
>I. framework issues:
>
>A. error codes:
>
>at present, the framework uses three digit error codes (e.g., 550) to convey
>error information for channel management. there are two other popular styles
>of conveying error identities, extended (e.g. 5.5.12) and symbolic (e.g.,
>syntaxError).
>
>note that nothing prevents other profiles from using a different style; of
>course, inertia suggests that new profiles are more likely than not to reuse
>what other profiles use.
>
>the question: should the channel management profile use a different style?
>
>
>B. closing channels
>
>at present, the framework does not contain any notion that a channel may be
>closed after it is created (all channels are closed automatically when a
>bxxp session is released).
>
>however, it would be useful for the underlying transport mappings to be told
>when there will be no more traffic on a channel (e.g., so buffers can be
>released).
>
>there are two ways to address this: the first is to add an explicit message
>to the channel management profile that allows for a negotiated close; the
>second is to add some text to the framework indicating that an API should
>provide a mechanism whereby an application can signal that it won't be using
>a particular channel anymore.
>
>the question: should channel closing being introduced to the framework?
>
>the second question: if so, should it be explicit or implicit?
>
>
>C. piggybacks during channel creation
>
>at present, the framework allows a message to be encapsulated during channel
>creation (providing that the profile being bound to the channel uses XML).
>
>this provides considerable implementation difficulty for various parties.
>
>the purpose of the piggyback is to avoid a second round-trip, and while a
>client-side implementation needed support piggybacks, all server-side
>implementations must.
>
>the question: should the framework be modified to remove the piggyback
>facility?
>
>
>D. invalid responses
>
>at present, the framework doesn't indicate what happens when a channel gets
>an invalid (malformed or inappropriate) response to a request.
>
>the question: should the framework be modified to explicitly require that
>each profile specify this behavior?
>
>
>E. DTD commentary for the profile element (c.f., I-C above)
>
>at present, the framework textually explains the situations in which the
>"profile" element may contain an embedded message (for piggybacking during
>channel creation).
>
>however, the DTD description of the profile element lacks this explanation.
>
>the question: if piggybacking remains in the framework, should the DTD be
>modified to reflect the textual description which occurs earlier in the
>specification?
>
>
>F. default charset
>
>at present, the framework is silent with respect to the default character
>set used for profiles that are defined using XML.
>
>the default character set value for an XML document is UTF-8.
>
>the question: should the framework be modified to explicitly permit each
>XML-based profile to specify a default character set?
>
>
>G. serial numbers and sequence numbers
>
>at present, the framework document uses serial and sequence numbers as
>integral parts
>of the framing mechanism.
>
>serial numbers are used to distinguish between different requests made
>(regardless of channel),
>sequence numbers are used for consistency checking, and possibly by the
>underlying transport
>mapping.
>
>the question: should the framework be simplified to minimize its use of
>serial and sequence numbers?
>
>
>II. tcp mapping issues:
>
>A. silly window
>
>at present, the tcpmapping document is minimal with respect to some of the
>strategies used in managing window-based flow control (e.g., silly window
>syndrome isn't discussed).
>
>the lack of explicit information assumes a level of familiarity that is
>perhaps inappropriate for many implementors.
>
>the question: should the specification include wording similar to that in
>the relevant sections of RFC 1122 that more fully dicusses window
>management techniques?
>
>
>B. shrinking window
>
>at present, the tcpmapping document is silent with respect to shrinking a
>window after it has been advertised.
>
>it has been argued that this behavior is inconsistent with window-based flow
>control (the window's edge should never be moved to the left). however,
>because the specification is silent, there is confusion as to what should
>happen if this behavior occurs
>
>the question: should the specification include wording similar to that in
>the relevant sections of RFC 1122 that makes it clear that the window may
>be advanced only to the right?
>
>
>/mtr
>
>
>
>
>
>
>
>_______________________________________________
>BXXPwg mailing list
>BXXPwg@lists.invisible.net
>http://lists.invisible.net/mailman/listinfo/bxxpwg