- From: Marshall Rose <mrose+mtr.netnews@dbc.mtview.ca.us>
- Date: Thu, 6 Apr 2000 09:56:16 -0700
- 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, transport > > 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 epicycles... /mtr
Received on Thursday, 6 April 2000 12:56:49 UTC