[BXXPwg] issues list for pittsburgh meeting

Marshall Rose mrose+mtr.netnews@dbc.mtview.ca.us
Sun, 23 Jul 2000 23:42:50 -0700


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