[BXXPwg] Draft Minutes of last week's meeting

Steve Harris sharris@primus.com
06 Aug 2000 20:26:18 -0700

Keith McCloghrie <kzm@cisco.com> writes:


> 2. Default Character Set - should an XML-based profile be allowed to
> specify a default character set.


> However, if an XML-based profile needs to specify an alternative
> character set, it should use a Content-Type header to do so.

Was there any discussion around using the XML Declaration to specify
the encoding? I can see how a Content-Type header should _override_
any encoding specified in an XML Declaration (as suggested the the XML
spec.), but I can't see why a Content-Type header should be necessary
when the XML Declaration is accurate. The "Annotated XML Spec."
describes a scenario where a document's XML Declaration may specify
one encoding, but the document gets transcoded by a delivering Web
server. In that case, the payload should be annotated with a
Content-Type header specifying the actual encoding, and that
externally-specified encoding should be handed to the consuming
parser, thus overriding the encoding mentioned in the document's XML
Declaration. If the encoding isn't changed, though, no encoding need
be mentioned in the MIME header.


> 2. Piggybacks - an XML-based profile is allowed to include an encapsulated
> message as part of channel creation.  This piggybacking capability saves
> a round trip time, and that was thought to be a good thing for some
> transport mappings, e.g., T/TCP or UDP.  However, implementations should
> not send an "unreasonable" amount of data in the <start>.  The consensus
> of the meeting was to retain piggybacks, and to add text to the
> specification reminding profile designers that initialization elements
> should be reasonable in size.

Ouch! I had high hopes for seeing these "piggybacks" stricken from the

Again, I don't think that the *amount* of data is the issue. It's the
fact that the data is arbitrary XML. We've mentioned this difficulty
here, but it bears repeating. When you receive the <start> element as
part of your Channel 0 handler, you'd likely want to hand the content
of <start> over to some factoried handler for the requested
profile. That means that the newly-created handler must be able to
consume parsed XML content, and must therefore either consume a node
tree or parsing event call-backs. That infuses an understanding of XML
in every profile, whether or not that profile even uses any XML in its
message format.

More importantly, the channel creation side of an API is awkward. How
does the creating program pass this <start> content to a BXXP library? 
As a text stream? If so, then should the library parse the text to
verify that it's well-formed before sending it? Should the library
take a node tree as input that it writes out as XML? None of these
choices seem particularly elegant or natural. It all looks okay on the
wire, but we must also think about what it looks like from the
application programmer's perspective. This <start> content still looks
like a wart to me.

Efficiency is always hard to argue against. Let me ask this: Why would
the peer requesting creation of a channel send data that may or may
not even be used if channel creation fails?

A more valid idea is to provide "constructor arguments" to the
channel. That's what I took the <start> content to be since the first
time I read the BXXP spec. Constraining channel creation with the
presence of certain "arguments" seems like a useful idea. I just think
we need some other ideas of how to provide those arguments. I'm still
thinking of what to propose.

Steven E. Harris        :: sharris   @primus.com
Primus                  :: http://www.primus.com