RE: Thoughts about path and intermediaries

Hi Mark,

> From: Mark Nottingham [mailto:mnot@akamai.com]
> Sent: 12 February 2001 18:25
> To: Williams, Stuart
> Cc: Martin Gudgin; xml-dist-app@w3.org
> Subject: 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.

Sure... that was the stress on "*having*" above.

> 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. 

I think that the AMG is managing to reduce the level of fuzziness here - at
least in the abstract model, bearing in mind that it is primarily intended
as an aid to description, not a constraint on implementation - I hope to
post some revised work from the group in the next couple of days - I would
very much welcome your comments.

> "...its really a suite of standardized application services;" 

From an extensibility point-of-view I can see where you're coming from. Can
you identify those "standardized application services" and which of them the
XML Protocol WG is chartered to standardize? The way I see it is that there
is a core to XMLP which is the root of an extensible framework. Our work of
the moment is to specify that core and ensure it does indeed have the hooks
to be extensible. It then comes down to the definition of that
core/framework, which really should be as unfuzzy as possible... if we are
talking of standarizing anything.
 
> 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.

So I don't have a problem with a processing model, if by processing model
you mean the rules that a protocol entity applies to control its operation.
To a large extent I don't have a problem with whether from an implementation
point-of-view the protocol implementation is buried in a monolithic
application or neatly partitioned into systems services with extensibility
framework and APIs. For the descriptive purposes of writing a specification,
I think we do have to pick on a model, an abstract model, and then animate
it with our description.

There are (at least) five essential elements to the definition of a
protocol:

a) A service definition - a statement of what the protocol does, a model of
the operations it provides to the things that use it.

b) A set of messages that the protocol exchanges between peer protocol
entities (the things that *provide* the services of the protocol.

c) The rules of procedure for the protocol - which govern the exchange of
protocol messages - I think this is the processing model you mention.

d) Encoding rules for the message set at b)... seem that that's XML
constrained by a schema.

e) Assumptions about the environment in which the protocol operates - lossy,
misorderded and duplicated delivery or whatever. I would tend to
characterise the environment with the properties of the underlying
protocols.

The AMG is working principally on a) and edging a bit into c). b,c,d are all
about design. e is hard, the different underlying protocols we can bind to
provide us different environmental assumptions. That means we either have to
go for lowest common denominator, or, we introduce mechanisms into bindings
that bring us upto some common level, or we end up having to expose the gory
details upward to the users of XMLP... in which case I would think that
we've done very little for them.

> > 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.

I think I've got a pretty good grasp of the model that you're working with
and I can see the XMLP framework as a means for 'glueing' these extensible
pieces together. I can also see that we want an environment where 'anyone'
who wants to can create and 'XMLP Module'. However, at some stage we flip
from a definition of what XMLP is to some notion of arbitrary extensibility
where of course nothing is fixed and oh by the way, we won't be defining
that, that's a module that sombody else can add...

> > > 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.

An envelope really only gives us at most 1/5 of what we need - item d above.
I might be generous and say 2/5 because for XMLP the abstract syntax of the
messages (b above) and the concrete syntax (d) are both XML.
> 
> 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. 

Ok... I would like a framework that we can hang lots of things (XMLP
Modules). I'd also like that framework to be strong so that it doesn't
buckle under the weight of what people what to hang on it, and simple so
that creating new things to hang on it is easy. I think that does require
some firmness, or we just end up with a tangled mass of wreckage.

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

Stuart Williams
HP Labs, Bristol, UK.

Received on Tuesday, 13 February 2001 04:25:09 UTC