Loading ...
Sorry, an error occurred while loading the content.

Resolution (was: Re: [soapbuilders] Frontier -> iLab matrix in a table)

Expand Messages
  • Glen Daniels
    Folks: I spoke to Andrew and Henrik about this yesterday at the WSWS, and we all agreed that in fact this test is incorrect. As per Andrew s message about the
    Message 1 of 39 , Apr 12, 2001
    • 0 Attachment
      Folks:

      I spoke to Andrew and Henrik about this yesterday at the WSWS, and we all
      agreed that in fact this test is incorrect. As per Andrew's message about the
      "stack of envelopes", the actor attribute should be considered to work as
      follows: if you don't see an actor value of "next", blank (if you're the
      ultimate destination), or a particular URI you recognize, you should completely
      ignore the header (and NOT fault). This is true regardless of the
      mustUnderstand value.

      --Glen

      ----- Original Message -----
      From: "Paul Kulchenko" <paulclinger@...>
      To: <soapbuilders@yahoogroups.com>
      Sent: Wednesday, April 11, 2001 10:21 AM
      Subject: RE: [soapbuilders] Frontier -> iLab matrix in a table


      > Hi, Andrew!
      >
      > Later I posted message asking what could be the proper handling
      > without implementing full support for intermediaries. IMHO it should
      > be "fail message if header has mustUnderstand attribute 'true' and
      > (no actor attribute or actor with .../next value)". Will it be
      > sufficient?
      >
      > I do not agree to fail the message if header does NOT have
      > mustUnderstand but has some Actor attribute that is different from
      > .../next. Why should current test endpoint fail this request? THAT
      > was the question about Jake's test. I don't see from spec I should do
      > it. If you explain it to me, I'll definitely implement it this way.
      >
      > I'd love to do it as easy as possible for the users and do NOT force
      > them to add any code in addition to their application code to make
      > their endpoints SOAP 1.1. compliant.
      >
      > Thank you for your attention to this matter, Andrew. I have the same
      > feeling that it should NOT be pushed down on application and should
      > be resolved on SOAP processor level (with some help from
      > application).
      >
      > Best wishes, Paul.
      >
      > --- Andrew Layman <andrewl@...> wrote:
      > > My apologies for not being more clear. I was not commenting on the
      > > exact tests that a SOAP processor should make but reacting to
      > > Paul's
      > > comment that "SOAP::Lite doesn't have any specific support for
      > > actor or
      > > intermediaries, but nothing stops you from implementing it in your
      > > own
      > > methods."
      > >
      > > I interpreted this to say that SOAP:Lite does not take
      > > responsibility
      > > for proper handling of some header attributes. That is a fair
      > > decision.
      > > However, a sender does not send messages to SOAP:Lite, it sends
      > > messages
      > > to a service comprising SOAP:Lite plus additional application code.
      > > That combination of SOAP:Lite plus additional application code is
      > > responsible for proper handling of all header attributes. An
      > > application that does not handle them properly is a broken SOAP
      > > app.
      > >
      > > Evidently, SOAP:Lite requires that applications add specific
      > > support for
      > > actor etc. in order to avoid being broken SOAP apps. This is worth
      > > knowing.
      > >
      > > Naturally, we might wish that SOAP:Lite (and other support
      > > libraries)
      > > makes it as easy as possible to handle headers correctly.
      > >
      > >
      > >
      > > -----Original Message-----
      > > From: Glen Daniels [mailto:gdaniels@...]
      > > Sent: Tuesday, April 10, 2001 8:07 AM
      > > To: soapbuilders@yahoogroups.com
      > > Subject: Re: [soapbuilders] Frontier -> iLab matrix in a table
      > >
      > >
      > > Hmm...
      > >
      > > This seems pretty opposed to what you said in [1], Andrew....?
      > >
      > > --Glen
      > >
      > > [1] http://groups.yahoo.com/group/soapbuilders/message/1304
      > >
      > > ----- Original Message -----
      > > From: "Andrew Layman" <andrewl@...>
      > > To: <soapbuilders@yahoogroups.com>
      > > Sent: Tuesday, April 10, 2001 12:21 AM
      > > Subject: RE: [soapbuilders] Frontier -> iLab matrix in a table
      > >
      > >
      > > > These tests are not just testing SOAP support libraries but the
      > > entire
      > > > behavior of the SOAP endpoint. If the SOAP endpoint receives a
      > > message
      > > > with an actor value that it does not understand (as described in
      > > Jake's
      > > > message below) then the application should fault the message.
      > > The
      > > mere
      > > > fact that the SOAP endpoint uses a support library such as
      > > SOAP:Lite
      > > > does not exempt it from this responsibility.
      > > >
      > > > -----Original Message-----
      > > > From: Paul Kulchenko [mailto:paulclinger@...]
      > > > Sent: Monday, April 09, 2001 8:25 PM
      > > > To: soapbuilders@yahoogroups.com
      > > > Subject: Re: [soapbuilders] Frontier -> iLab matrix in a table
      > > >
      > > >
      > > > Hi, Jake!
      > > >
      > > > While that is true, I don't think that this is teh right test.
      > > > SOAP::Lite doesn't have any specific support for actor or
      > > > intermediaries, but nothing stops you from implementing it in
      > > your
      > > > own methods. Before full support for Header and intermediary
      > > > processing will be implemented I have no knowledge that you
      > > > imlemented it yourself and this check will fail requests that
      > > > otherwise could be properly executed. Just IMHO (yes, I may
      > > include
      > > > global flag that will enable/disable this check, but truly I'd
      > > rather
      > > > not to).
      > > >
      > > > Best wishes, Paul.
      > > >
      > > > --- Jake Savin <jake@...> wrote:
      > > > > If it's anything except the "special URI" meaning that this
      > > > > endpoint is the
      > > > > intended recipient, it's an error, since I know I'm not an
      > > > > intermediary:
      > > > >
      > > > > http://schemas.xmlsoap.org/soap/actor/next
      > > > >
      > > > > See the 3rd paragraph of Section 4.2.2:
      > > > >
      > > > > http://www.w3.org/TR/SOAP/#_Toc478383499
      > > > >
      > > > > Cheers,
      > > > > -Jake
      > > > >
      > > > > on 4/9/01 8:02 PM, Paul Kulchenko at paulclinger@...
      > > wrote:
      > > > >
      > > > > > Hi, Jake!
      > > > > >
      > > > > > --- Jake Savin <jake@...> wrote:
      > > > > >> I posted the results of Frontier calling the implementations
      > > on
      > > > > the
      > > > > >> iLab matrix as a table:
      > > > > >>
      > > > > >> http://jake.soapware.org/currentXmethodsResults
      > > > > > Out of curiocity, what is "not valid URI"? It could be
      > > virtually
      > > > > > anything. What did you check it for?
      > > > > >
      > > > > > Best wishes, Paul.
      > > > > >
      > > > > > __________________________________________________
      > > > > > Do You Yahoo!?
      > > > > > Get email at your own domain with Yahoo! Mail.
      > > > > > http://personal.mail.yahoo.com/
      > > > > >
      > > > > >
      > > > > > To unsubscribe from this group, send an email to:
      > > > > > soapbuilders-unsubscribe@yahoogroups.com
      > > > > >
      > > > > >
      > > > > >
      > > > > > Your use of Yahoo! Groups is subject to
      > > > > http://docs.yahoo.com/info/terms/
      > > > > >
      > > > > >
      > > > >
      > > > >
      > > > > ------------------------ Yahoo! Groups Sponsor
      > > > >
      > > > > To unsubscribe from this group, send an email to:
      > > > > soapbuilders-unsubscribe@yahoogroups.com
      > > > >
      > > > >
      > > > >
      > > > > Your use of Yahoo! Groups is subject to
      > > > > http://docs.yahoo.com/info/terms/
      > > > >
      > > > >
      > > >
      > > >
      > > > __________________________________________________
      > > > Do You Yahoo!?
      > > > Get email at your own domain with Yahoo! Mail.
      > > > http://personal.mail.yahoo.com/
      > > >
      > > >
      > > > To unsubscribe from this group, send an email to:
      > > > soapbuilders-unsubscribe@yahoogroups.com
      > > >
      > > >
      > > >
      > > > Your use of Yahoo! Groups is subject to
      > > > http://docs.yahoo.com/info/terms/
      > > >
      > > >
      > > >
      > > >
      > > > To unsubscribe from this group, send an email to:
      > > > soapbuilders-unsubscribe@yahoogroups.com
      > > >
      > > >
      > > >
      > > > Your use of Yahoo! Groups is subject to
      > > http://docs.yahoo.com/info/terms/
      > > >
      > > >
      > >
      > >
      > >
      > > To unsubscribe from this group, send an email to:
      > > soapbuilders-unsubscribe@yahoogroups.com
      > >
      > >
      > >
      > > Your use of Yahoo! Groups is subject to
      > > http://docs.yahoo.com/info/terms/
      > >
      > >
      > >
      > > ------------------------ Yahoo! Groups Sponsor
      > >
      > >
      > === message truncated ===
      >
      >
      > __________________________________________________
      > Do You Yahoo!?
      > Get email at your own domain with Yahoo! Mail.
      > http://personal.mail.yahoo.com/
      >
      >
      > To unsubscribe from this group, send an email to:
      > soapbuilders-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
    • Andrew Layman
      I have not thought through whether a mustHappen attribute such as Noah suggests is a good idea or not (though, given Noah s track record, I suspect he is
      Message 39 of 39 , Apr 14, 2001
      • 0 Attachment
        I have not thought through whether a "mustHappen" attribute such as Noah
        suggests is a good idea or not (though, given Noah's track record, I
        suspect he is onto something useful).

        If such a thing were found to be needed, the existing SOAP design is
        sufficient to enable its integration without revision to the SOAP 1.1
        specification. We could define a new header element in a new namespace.
        It would be like the following, whose presence in a message is
        sufficient to obligate each actor to understand the meaning of the new
        mustHappen attribute or fail the message:

        <noah:mustHappen
        SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next"
        SOAP-ENV:mustUnderstand='1'/>

        -----Original Message-----
        From: Noah_Mendelsohn@... [mailto:Noah_Mendelsohn@...]
        Sent: Thursday, April 12, 2001 1:54 PM
        To: soapbuilders@yahoogroups.com
        Subject: Re: Resolution (was: Re: [soapbuilders] Frontier -> iLab matrix
        in a table)


        Doug Davis writes:

        >> One of the problems I have with this solution is
        >> that not only does a "mustUnderstand" flag get
        >> ignored (which means the contract that the client
        >> asked for will never get accepted) but the client
        >> is never told that it wasn't accepted

        I agree with the Andrew/Glen/Henrik as to how the current SOAP spec
        should
        be interpreted. On the other hand, I think that features could be added

        to future versions (XMLP?) to solve the problem you raise. For example,
        I
        have chatted with Glen and Henrik about an idea I've had for introducing
        a
        "mustHappen" attribute, which like mustUnderstand would be a boolean:
        if
        a message reaches an endpoint and any mustHappen headers survive
        unprocessed, the endpoint faults the message. Indeed, many
        mustUnderstand headers would also be muHappen.

        (This idea also extends to a possible future world in which a more
        complete notion of message path is known, in which case mustHappen could

        be inferred to mean: this must happen before the message proceeds past
        the intended point on the path. For the moment, only the final point in

        the path is well architected in SOAP...you can't tell the order in which

        any other actors are to occur.

        ------------------------------------------------------------------------
        Noah Mendelsohn Voice: 1-617-693-4036
        Lotus Development Corp. Fax: 1-617-693-8676
        One Rogers Street
        Cambridge, MA 02142
        ------------------------------------------------------------------------





        To unsubscribe from this group, send an email to:
        soapbuilders-unsubscribe@yahoogroups.com



        Your use of Yahoo! Groups is subject to
        http://docs.yahoo.com/info/terms/
      Your message has been successfully submitted and would be delivered to recipients shortly.