[BXXPwg] issues list for pittsburgh meeting

Marshall Rose mrose+mtr.netnews@dbc.mtview.ca.us
Tue, 25 Jul 2000 11:58:32 -0700


good point. i'll add it.

/mtr

----- Original Message -----
From: Jacques Belissent <jac@eng.sun.com>
To: Marshall Rose <mrose+mtr.netnews@dbc.mtview.ca.us>
Cc: Kurt D. Zeilenga <Kurt@OpenLDAP.org>; <bxxpwg@invisible.net>;
<mrose@dbc.mtview.ca.us>
Sent: Monday, July 24, 2000 17:56
Subject: Re: [BXXPwg] issues list for pittsburgh meeting


>
> Hi,
>
> Provided adequate reliability mechanisms, items 1, 3, and 4 could be
> solved more efficiently if bxxp supported one-way messages (requests
> that do not require responses).  This is what I suggested in:
>
>     http://lists.invisible.net/pipermail/blocks/2000-June/000043.html
>
> and subsequent messages.  Perhaps this should be added to the issues
> list.
>
> jacques
>
> Marshall Rose wrote:
> >
> > hi. i think it would be useful for you to make a presentation on these
> > issues in pittsburgh. just two things to think about for now:
> >
> > 1. the ldap-style of interaction appears to be more and more like an
> > rpc-based style, which isn't where beep is targeted (the design document
> > discusses some of the distinctions between rpc and loosely-coupled
styles).
> > this may explain why you're not having much luck in getting a match.
> >
> > 2. the reason why successfully neogitating a security profile results in
> > closing down all channels is to avoid man-in-the-middle meddling. if i
> > authenticate prior to encrypting, then an interloper may be able to
subtly
> > interfere with the traffic without detection.; if i start encrypting
first,
> > then anything the man-in-the-middle does is detectable. if you look at
the
> > use of STARTTLS for SMTP, STLS for POP, etc., you'll see that they all
> > behave in a similar fashion.
> >
> > /mtr
> >
> > ----- Original Message -----
> > From: Kurt D. Zeilenga <Kurt@OpenLDAP.org>
> > To: Marshall Rose <mrose+mtr.netnews@dbc.mtview.ca.us>
> > Cc: <bxxpwg@invisible.net>; <mrose@dbc.mtview.ca.us>
> > Sent: Monday, July 24, 2000 10:05
> > Subject: Re: [BXXPwg] issues list for pittsburgh meeting
> >
> > > 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
> > >
> > >
> >
> > _______________________________________________
> > BXXPwg mailing list
> > BXXPwg@lists.invisible.net
> > http://lists.invisible.net/mailman/listinfo/bxxpwg
>
> --
> Jacques Belissent, iPlanet
> (408)276-4219
>