Re: Thoughts about path and intermediaries

On Mon, Feb 12, 2001 at 10:33:18AM -0000, Williams, Stuart wrote:
> > I agree that the line here between functionality invoked at the "XP
> > layer" and the "service layer" above it is fuzzy; however, I think
> > it's fuzzy for the same reasons that it is in XMLP as a whole; the
> > protocol is being designed to give applications hooks (through the
> > headers) into the transport layer, by defining a processing model for
> > messages. Targeting gives this another dimension.
> 
> It is my hope that users of XMLP (developers, applications...)
> ideally have no knowledge whatsoever of the protocols operating
> beneath XP. Whilst, I would not prevent them from 'finding' out
> about features of the underlying protocols, it seems to fly in the
> face of any notion of abstraction and layering to perculate all the
> fine-grain detail and rich variety of underlying protocols upward
> and expose them to the application. IP runs over X.25, 802.x, ATM,
> SONET, Satelite Links, phone wires and carrier pidgeon (there is an
> Avian Carrier binding in the RFC collection [1,1a]). I know of very
> few circumstances in which the user of IP needs to be exposed to
> the details of the underlying link protocols. In the same way, I
> would hope that we can shield the user of XP from *having* to know
> the details of HTTP, SMTP, BXXP... and whatever other underlying
> protocol we might create bindings for.
> 
> I think this is some of what Noah was talking about in [2,3].

I don't disagree with what you're saying, except to add that there
will be uses of XMLP where the choice of transport binding is
critical, does need to be known, and may need to be interacted with.
We shouldn't force this on users, but it will be neccessary for some.

However, the separation between the transport layer and the
XMLP layer wasn't what I was writing about; I was speaking to
the fuzziness between the XMLP layer and the applications that
utilize it. Although we can conceptualize XMLP as a layer underneath
the application, it is really a standardized suite of application
services; parts of the application are embedded into the protocol
when we use headers. 

This is an artifact of introducing a processing model into a
protocol. It's not a bad thing, but we shouldn't pretend there is a
rigid separation between the layers; applications should and will
need to interact with the XP Layer.


> Enough determinism so that either... someone can look at a
> given installation from outside and figure out what its going
> to do in a given circumstance. Anything less is just complete
> chaos. A next level of determinism is where the sender of a
> message (an application or the developer of an application)
> rather than the all seing eye, can predetermine what will
> become of a message they choose to send.

Everything that I've described is common practice on the Web, and
frankly will happen whether or not we accommodate it. If we do, we'll
have the opportunity to explicity support new capabilities in the
applications, through intermediary processing. If we don't, people
will run into the same problems that they encounter when trying to
introduce a processing model into the HTTP.

 
> > XMLP shouldn't be build to fit a particular application's
> > requirements; rather, our it should be a generic toolset that can
> > be used for many different purposes. It's not just for RPC,
> > distributed objects, etc; hopefully, it will be the first choice
> > of anyone who needs to shove XML across a wire in some fashion,
> > whether they're developing an application or a protocol. That's
> > how I've been thinking, at least.
> 
> For XMLP to be "...the first choice of anyone who needs to shovel
> XML across a wire in some fashion..." XMLP needs to present them
> with a mental model that is easy to grasp and it needs to be
> independent of particular bindings. It needs to have some firmness
> about the heart of what it does. If it can be all things to all
> people, we will have a hard time defining what it is in particular.

Our first deliverable is

  An envelope for encapsulating XML data to be transferred in an
  interoperable manner that allows for distributed extensibility and
  evolvability as well as intermediaries.

while the first general requirement introduced by the charter is

  The envelope and the serialization mechanisms developed by the
  Working Group may not preclude any programming model nor assume any
  particular mode of communication between peers.

I agree that the RPC deliverable should have 'firmness about the
heart', but I don't see the need to have it restrict the capabilities
of the other, more general and potentially more valuable
deliverables. 


-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)

Received on Monday, 12 February 2001 13:24:33 UTC