SOAP intermediary - issue 70 (cont'd)

[Switching over to dist-app.]

I meant that a SOAP node that merely adds a block (to the message) _with no further processing (of the
message)_ qualifies as a SOAP intermediary. That node will have processed _zero_ block (from the
message), which I think is what is intended by the definition.

Jean-Jacques.

Mark Nottingham wrote:

> How so? Noah's message didn't say anything about how the modification
> was triggered, which is central to the argument that I was making.
>
> I think this is orthogonal.
>
> On Wed, Oct 10, 2001 at 11:48:28AM +0200, Jean-Jacques Moreau wrote:
> > Mark, I think this is another argument in favour of the "processes zero or
> > more blocks".
> >
> > Noah, I agree we do not explicitely call this out in the definition, and I
> > think we should. Is there any text you would like to suggest?
> >
> > Jean-Jacques.
> >
> > Noah_Mendelsohn@lotus.com wrote:
> >
> > > I'm not sure it's all that broken to begin with, but we should keep in
> > > mind that intermediaries can modify the message.  For example, you could
> > > have an encrypting intermediary.  I wonder whether any of the formulations
> > > give an adequate signal of this possibility?
> > >
> > > ------------------------------------------------------------------------
> > > Noah Mendelsohn                                    Voice: 1-617-693-4036
> > > Lotus Development Corp.                            Fax: 1-617-693-8676
> > > One Rogers Street
> > > Cambridge, MA 02142
> > > ------------------------------------------------------------------------
> >
>
> --
> Mark Nottingham, Research Scientist
> Akamai Technologies (San Mateo, CA USA)

Mark Nottingham wrote:

> If it doesn't process a SOAP block, I don't think it's a SOAP
> Intermediary; it might be an HTTP intermediary, for example.
>
> An argument could be made that going through the motions of looking
> for a SOAP block to process might qualify it as such, but I'm
> inclined to say that doesn't make it; it isn't imposing any of SOAP
> mechanisms upon the message.
>
> Cheers,
>
> On Tue, Oct 09, 2001 at 09:05:54AM +0200, Jean-Jacques Moreau wrote:
> > Hum... what about building instead on the definition for a SOAP sender[1]  : 'It transmits the
> > SOAP message further along the SOAP message path.' ?
> >
> > I also have an issue with the previous sentence in that definition,
> > in that some intermediaries will not process any block.
> >
> > So what about this revised definition :
> >
> >      'A SOAP intermediary is both a SOAP receiver and a SOAP
> >      sender, target-able from within a SOAP message. It processes
> >      zero or more blocks from the SOAP message targeted at the
> >      intermediary, and transmits the message further along the SOAP
> >      message path.'
> >
> > Jean-Jacques.
> >
> > [1] A SOAP sender is a SOAP node that transmits a SOAP message.
> >
> >
> > Doug Davis wrote:
> >
> > > Definitely better - leaves it more open.
> > > What do the editors think?
> > > -Dug
> > >
> > > Mark Nottingham <mnot@akamai.com>@w3.org on 10/03/2001 12:25:04 PM
> > >
> > > Sent by:  w3c-xml-protocol-wg-request@w3.org
> > >
> > > To:   Doug Davis/Raleigh/IBM@IBMUS
> > > cc:   w3c-xml-protocol-wg@w3.org
> > > Subject:  Re: Extra agenda item (short) for Oct 3 XMLP telcon -- issue 70
> > >
> > > I think this might be centered around the phrase 'it acts to
> > > forward'?
> > >
> > > How about the less direct 'Messages are forwarded from it...'?
> > >
> > > On Wed, Oct 03, 2001 at 07:07:27AM -0400, Doug Davis wrote:
> > > > I don't mind if we say that the final definition we come up with
> > > > will close issue 70 - however, I have some concern about
> > > > the current text  - as I noted in a note to the WG a while ago
> > > > (I've attached the issue below).
> > > > -Dug
> > > >
> > > >
> > > > David Fallside/Santa Teresa/IBM@IBMUS@w3.org on 10/03/2001 01:15:05 AM
> > > >
> > > > Sent by:  w3c-xml-protocol-wg-request@w3.org
> > > >
> > > >
> > > > To:   w3c-xml-protocol-wg@w3.org
> > > > cc:
> > > > Subject:  Extra agenda item (short) for Oct 3 XMLP telcon -- issue 70
> > > >
> > > >
> > > >
> > > > It is proposed to close issue 70 (provide a defn of processing
> > > > intermediaries) [1] with the resolution text provided at [2] (the
> > > glossary
> > > > includes a defn of a SOAP intermediary). Is this not acceptable to anyone
> > > > in the WG?
> > > >
> > > > [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x70
> > > > [2] http://lists.w3.org/Archives/Public/xmlp-comments/2001Oct/0000.html
> > > >
> > > >
> > > > ............................................
> > > > David C. Fallside, IBM
> > > > Ext Ph: 530.477.7169
> > > > Int  Ph: 544.9665
> > > > fallside@us.ibm.com
> > > >
> > > >
> > > ----------------------------------------------------------------------------------------------
> > >
> > > >
> > > > [issue]
> > > > Section 1.4.2: SOAP intermediary (et al)
> > > >   A SOAP intermediary is both a SOAP receiver and a SOAP
> > > >   sender, target-able from within a SOAP message. It processes
> > > >   a defined set of blocks in a SOAP message along a SOAP
> > > >   message path. It acts in order to forward the SOAP message
> > > >   towards the ultimate SOAP receiver.
> > > > This  last sentence seems to imply that intermediaries do
> > > > forwarding when in fact they might not do that at all. Do these
> > > > terms imply a certain implementation choice?  We typically think
> > > > of the processing model where messages are PUSHed to a SOAP node
> > > > and then that node will then PUSH it on to the next node.  I see
> > > > a mode of operation that might not fit all of the definitions as
> > > > stated above, for example:
> > > >   Each SOAP Node is invoked with the SOAP message thru a simple
> > > >   procedure call.  In this mode an intermediary doesn't forward
> > > >   on the message, it just returns (notice it might return "void"
> > > >   or it might return a SOAPEnvelope object depending on whether
> > > >   it is supposed to modify the message) it would then be up to
> > > >   the controller that is doing the call's to then determine which
> > > >   is the next SOAP node to "call".
> > > >
> > > >
> > > >
> > >
> > > --
> > > Mark Nottingham, Research Scientist
> > > Akamai Technologies (San Mateo, CA USA)
> >
>
> --
> Mark Nottingham, Research Scientist
> Akamai Technologies (San Mateo, CA USA)

Received on Friday, 12 October 2001 03:33:53 UTC