W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2000

Re: XML protocol comparisons

From: Marshall Rose <mrose+mtr.netnews@dbc.mtview.ca.us>
Date: Thu, 6 Apr 2000 09:56:16 -0700
Message-ID: <001101bf9fe9$093492e0$6d61fea9@dbc.mtview.ca.us>
To: "Justin Chapweske" <justin@cyrus.net>
Cc: <michaelm@netsol.com>, "Henrik Frystyk Nielsen" <frystyk@microsoft.com>, <xml-dist-app@w3.org>, "Marshall Rose" <mrose@dbc.mtview.ca.us>
> > 1. there is more to bxxp than framing, e.g., user authentication,
> > security, and channel management (though you could layer that extra
stuff on
> > top of smux if you wanted to define it all)
> Just curious, but why would you want to have all of this stuff crammed
> into one protocol?  I think the layering approach is superior to a
> kitchen-sink type protocol.

we don't have it all crammed into one protocol... it is all integrated into
one framework.

you need to integrate the transport security stuff in, because once you
negotiate it, you'll want the framing mechanism to sit on top of it.

you need to integrate the user authentication stuff in, because its
desirable to have one authentication identity bound to one transport
connection (e.g., to work with QoS/diffServ/intServ/etc...) -- or at least
that's what the network layer/security weenies tell me.

you need to integrate the channel management stuff in, because it impacts
the way you do framing.

having them integrated doesn't mean it's a big glop, it means you have to
carefully define interfaces and interactions. in the 5 different
implementations of bxxp that i'm aware of, a constant theme is the use of
several modules, reasonably clean apis, etc.

i'm sure someone can come up with a strict bottom-up layering approach to do
something similar, however there will be enough exceptions (e.g., framing v.
transport security) that the resulting spec/code will have a lot of

Received on Thursday, 6 April 2000 12:56:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:09 UTC