Ordering of Processing [was: Regrets / Issue 71]

[this was there because I composed the original message as a Regrets,
while reading the agenda for the call... oops. Moving over to
dist-app]

This makes sense. However, from the outside world (or at least to me,
before I got the context), it looks like we're being a bit obtuse by
not specifying what to do when you get a message with blockA, blockB,
and no hints about ordering. I imagine that some implementations will
do default lexical ordering, but then again no one is prevented from
doing reverse lexical ordering by default. My concern is that a de
facto standard will evolve, and people will assume that lexical
ordering is the default, leading to unpredictable or unintended
behaviour.

Regarding node-imposed ordering: With what's been said here in mind,
consider our approach to order of processing as compared to that we
take with processing invocation. Senders can specify what processing
receivers should perform, by using a a designated mechanism, the
Header. In addition, nodes might perform other processing that is
arranged by out-of-bound contract, or that is instigated by a
correlated message. We don't talk about the out-of-bound ways to
instigate processing, but we assume it will happen. Instead, we have
a well-crafted in-message means of specifying what to process.

Contrast this approach with that we're taking on order of processing;
here, we're saying nothing about in-envelope order of processing,
because we anticipate people overriding it sometimes. Here, it seems
like we're not trying because we don't believe there are any cases
where default in-envelope ordering is useful.

Of course there are a number of very complex situations where
Modules, Nodes and other factors will influence order of processing.
However, it seems remiss to leave out a default ordering for simple
cases.

Regarding significance, I would imagine that flexible ordering is
significant to a great (even significant) number of Modules. E.g.;
caching, encryption, signing, policy evaluation, etc. In the current
model, if more than one of these modules is in use at any time, the
existence and presence of an ordering module will be compulsory.

Nevertheless, it looks like there was consensus against a default
ordering, and I promised I'd stop ;)  

If anyone's interested in talking about a simple lexical ordering
Module, please speak up. I have a feeling that such an effort would
be valuable not only for its product, but also for the feedback it
gives to the WG regarding how Modules specify an ordering in their
relationships, etc.



On Mon, Sep 03, 2001 at 09:57:00AM -0400, Glen Daniels wrote:
> +1, Stuart.  (incidentally, why is this conversation here and not
> on dist-app?)
> 
> >From an implementor's point of view, the Axis team has decided that 
> (2) below is very important.  In some situations involving
> security-related extensions, for instance, the deployment engineer
> may want to ensure that no matter what, the security Handler (Axis
> terminology) runs first, and therefore deals with security-related
> header blocks.  This would allow the security extension to complain
> immediately in the face of problems, and not expose even fault
> messages (which might still contain information useful for breaking
> into the site in question) from other modules.  If there is an
> ordering extension that would change this and give the client more
> control, then the result depends on the deployment at the site
> (e.g. perhaps a fault or perhaps a behavior change).
> 
> I agree that simple lexical order is usually a fine default, but
> don't think we gain a whole lot by explaining that and then also
> indicating that software is more than welcome to ignore it at will
> except in the presence of specific extensions which add ordering.
> 
> --Glen
> 
> ----- Original Message -----
> From: "Williams, Stuart" <skw@hplb.hpl.hp.com>
> To: "'Mark Nottingham'" <mnot@akamai.com>
> Cc: <w3c-xml-protocol-wg@w3.org>
> Sent: Monday, September 03, 2001 4:56 AM
> Subject: RE: Regrets / Issue 71
> 
> 
> > Hi Mark,
> >
> > Personally I've got to the point of having no strongly held views
> > on this one. Previously I might have felt that by agreeing that
> > the lexical/document order by default was insignificant we
> > potentially squandered a natural ordering mechanism.
> >
> > However, I have become more relaxed on this for two reasons:
> >
> > 1) If block order is (by default) insignificant then if it is
> > convenient to me I can always (in the absense of anything that
> > changes the dafault) choose to process blocks in the natural
> > document/lexical ordering anyway.
> >
> > 2) I am aware of a reasonably strong point-of-view that: the
> > order in which a given node processes a bunch of headers is its
> > business and not the business of the sender. In particular I
> > think that there are concerns about the potential for a malicious
> > sender to exploit 'worm-like' behaviour if it can directly effect
> > block evaluation ordering.
> >
> > Of course this 'default' is the natural choice if extensions are
> > mostly orthogonal.
> >
> > Also I think that the important thing is whether block order is
> > significant to what a message means - not whether it explicitly
> > proscribes evaluation order. eg (2*3)+(4*5) does not proscribe
> > which of the multiplications need be evaluated first, indeed I
> > guess one could come up with a bunch of bizarre evaluation
> > strategies all of which would yield 26.
> >
> > Regards
> >
> > Stuart
> >
> > > -----Original Message-----
> > > From: Mark Nottingham [mailto:mnot@akamai.com]
> > > Sent: 31 August 2001 01:23
> > > To: Noah_Mendelsohn@lotus.com
> > > Cc: fallside@us.ibm.com; w3c-xml-protocol-wg@w3.org
> > > Subject: Re: Regrets / Issue 71
> > >
> > >
> > >
> > > Yes, that's a good way to put it. IMHO it seems like the
> > > discussion at Dinard was centered more around the processing
> > > model from mU's perspective, driving the ordering solution.
> > >
> > > I only wonder whether it would be possible to specify that if
> > > no header defines a processing model, then, by default, a
> > > lexical ordering is assumed, so that an ordering header would
> > > not have to be explicitly inserted.
> > >
> > > This would involve crafting a clear definition of what a module
> > > that affects processing order is, so that the processor would
> > > know to 'turn off' lexical ordering before it started (this
> > > would avoid the undesirable interactions, I think). I'm not
> > > sure if this would have to be reflected in the envelope; my
> > > instinct is that it wouldn't.
> > >
> > > I'd vote to have a default lexical order, but I can see the
> > > issues. If many other people feel strongly that we should have
> > > a default ordering, minding the issues highlighted, perhaps we
> > > could reconsider it. Otherwise, perhaps someone would be
> > > interested in working on a lexical ordering Module?
> > >
> > >
> > >
> > > On Wed, Aug 29, 2001 at 03:37:32PM -0400,
> > > Noah_Mendelsohn@lotus.com wrote:
> > > > Mark Nottingham writes:
> > > >
> > > > >> I think that a default processing order (e.g., lexical
> > > > >> order) should be specified, in the absence of other
> > > > >> information; this will improve interoperability in the
> > > > >> common case. However, if consensus has been reached on
> > > > >> this point (I don't recall exactly where we left it), I'll
> > > > >> concede. If not, I'll be happy to take an action item to
> > > > >> start a thread, as above.
> > > >
> > > > I think we effectively reached consensus on not specifying a
> > > > default order at Dinard, where the text you quote was drafted
> > > > and reviewed.  I agree that specifying an order might promote
> > > > interop, BUT I am somewhat concerned that it is difficult to
> > > > do.  If I have lots of intermixed header entries, some of
> > > > which do affect the order of processing (and it's very
> > > > important that they be able to), I think we have to very
> > > > carefully specify exactly to which header entries the
> > > > defaults apply.  Is it only to those not somehow mentioned in
> > > > the specification for some other header entry that does
> > > > occur?  Seems tricky.
> > > >
> > > > I think we decided that, if you want lexical order, you can
> > > > add a header which has that as its semantic (my recollection
> > > > on this last point is a bit vague); the specification for
> > > > that header would have to deal with the edge cases,
> > > > interactions with conflicting headers, etc.
> > > >
> > > > On balance, I think I'd vote for the status quo, but I can
> > > > see it either way.
> > >
> > > --
> > > Mark Nottingham, Research Scientist
> > > Akamai Technologies (San Mateo, CA USA)
> > >
> >
> 

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

Received on Monday, 3 September 2001 14:21:07 UTC