Re: COMMENTS/CORRECTIONS to V0.98

[Scott Hinkelman <srh@us.ibm.com>]

Hmmmm.
My view is that TRP is a "TRP-SWAProfile". Meaning, a specific way to
conform and use SWA. Hopefully there will not be more SWAProfiles, like
some RNIF-SWAProfile or something.

That said,
>True, but I might want to divert different messages to
different processors based on other arbitrary aspects
of the messages received, such as my different Service(s)
to which they pertain.

Assuming those messages will be SWA-based, the question then becomes are
those Services you speak of TRP-SWAProfile aware? If they are, some first
order of detection is needed to switch to the correct SWAProfile aware
Service handlers, and are we defining that to be SOAP Action? No wonder you
question if the use of SOAP Action is not throught through -are we setting
precedence for SWAProfile detection?

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Christopher Ferris <chris.ferris@east.sun.com> on 03/27/2001 04:32:46 PM

To:   Ebxml <ebxml-transport@lists.ebxml.org>
cc:
Subject:  Re: COMMENTS/CORRECTIONS to V0.98



True, but I might want to divert different messages to
different processors based on other arbitrary aspects
of the messages received, such as my different Service(s)
to which they pertain.

Constraining the value of SOAPAction to a single required
value (implied by MUST) would prevent my doing so.

If we can agree to tone down the REQUIRED use of a URI
that means ebXML and suggest that implementations MAY use
a value such as "uri:ebxml.org/messageService" then I would
be comfortable.

It isn't at all clear to me that SOAPAction has been necessarily
clearly thought through. Yes, it may be a valuable mechanism
for diverting traffic to appropriate processors, but so is
the namespace qualified element content of the SOAP-Env:Header
and SOAP-Env:Body.

My $0.02,

Chris

Scott Hinkelman wrote:
>
> I tend to agree with Krishna if indeed SOAP Action is the first
detectable
> processing indicator (meaning we can't switch to an ebXML handler purely
> from SWA mime).
>
> Scott Hinkelman, Senior Software Engineer
> XML Industry Enablement
> IBM e-business Standards Strategy
> 512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
> srh@us.ibm.com, Fax: 512-838-1074
>
> Krishna Sankar <ksankar@cisco.com> on 03/27/2001 10:57:54 AM
>
> To:   christopher ferris <chris.ferris@east.sun.com>, dick@8760.com
> cc:   Ebxml <ebxml-transport@lists.ebxml.org>
> Subject:  RE: COMMENTS/CORRECTIONS to V0.98
>
> Hi all,
>
>      IMHO, we do need an ebXML URI for SOAP action. This will make it
> easier for
> software to send ebXML blocks to an ebXML handler. I am not an expert at
> URIs but we should have something equivalent of ebXML:.... If we leave it
> to
> the services, we would lose this top level redirector ability.
>
> cheers
>
> |-----Original Message-----
> |From: christopher ferris [mailto:chris.ferris@east.sun.com]
> |Sent: Tuesday, March 27, 2001 8:34 AM
> |To: dick@8760.com
> |Cc: Ebxml
> |Subject: Re: COMMENTS/CORRECTIONS to V0.98
> |
> |
> |Actually, there are two issues here. One is, that I had thought
> |that we agreed that there would NOT be a SOAPAction defined for
> |ebXML. Secondly, the value of SOAPAction is supposed to be an URI
> |as defined in RFC 2396. ebXML is NOT an URI by any stretch of one's
> |imagination whether encapsulated in quotes or otherwise.
> |
> |SOAPAction is mandatory, but a null or empty value
> |is also valid. IMHO, SOAPAction should be allowed to
> |be determined by the owner of the deployed service.
> |
> |I would prefer:
> |
> |    The mandatory SOAPAction HTTP header field must be included
> |    in the HTTP header. The value of the SOAPAction header is
> |    unspecified by this specification.
> |
> |Cheers,
> |
> |Chris
> |
> |Dick Brooks wrote:
> |>
> |> Please note the requirement to encapsulate SOAPAction values
> |within "", e.g.
> |> SOAPAction: "ebXML".
> |>
> |> Dick Brooks
> |> Group 8760
> |> 110 12th Street North
> |> Birmingham, AL 35203
> |> dick@8760.com
> |> 205-250-8053
> |> Fax: 205-250-8057
> |> http://www.8760.com/
> |>
> |> InsideAgent - Empowering e-commerce solutions
> |>
> |> > -----Original Message-----
> |> > From: Henrik Frystyk Nielsen [mailto:frystyk@microsoft.com]
> |> > Sent: Tuesday, March 27, 2001 10:00 AM
> |> > To: Dick Brooks; XP-PUBLIC
> |> > Subject: RE: ebXML Messaging Service Specification available for 2nd
> |> > review
> |> >
> |> >
> |> >
> |> > Dick,
> |> >
> |> > Just a quick comment on the use of SOAPAction - it says in line 2339
> |> > that
> |> >
> |> >       The mandatory SOAPAction HTTP header field must also be
included
> |> >       in the HTTP header and must have a value of ebXML.
> |> >
> |> >               SOAPAction: ebXML
> |> >
> |> > And it is mentioned again in line 2339 for the SMTP binding. For the
> |> > HTTP binding at least, the format of the SOAPAction field is a URI,
as
> |> > per SOAP/1.1 [1]
> |> >
> |> >       soapaction    = "SOAPAction" ":" [ <"> URI-reference <"> ]
> |> >       URI-reference = <as defined in RFC 2396 [4]>
> |> >
> |> > Including quotes so for compliance with SOAP I propose that this is
> the
> |> > format that ebXML uses as well.
> |> >
> |> > Hope this helps,
> |> >
> |> > Henrik
> |> >
> |> > [1] http://www.w3.org/TR/SOAP/#_Toc478383528
> |> >
> |> > >The latest draft of ebXML's Message Service Specification,
> |> > >which utilizes SOAP V1.1 and SOAP with Attachments, is now
> |> > >available for review at:
> |> >
> |>|http://www.ebxml.org/specdrafts/ebXML_Message_Service_Specificatio
> |n_v0.
> |> > 98b.pdf
> |>
> |> ------------------------------------------------------------------
> |> To unsubscribe from this elist send a message with the single word
> |> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org
> |
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org