[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: missing(?) header element
Yep, I agree with Marty -- define an optional application headers MIME part for the payload and led the app (BP?) folk decide what goes in there. (OK, that's a bit more than what Marty said :-) Don't get MS headers munged (good OED word?) by sticking application stuff in them!!!! Best regards, Henry -------------------- At 02:55 PM 11/16/2000 -0500, Martin W Sachs/Watson/IBM wrote: > >Why would not application headers be simply part of the application payload >as far as the messaging service is concerned? One answer might be that the >messaging service (or some plug-in in the application services layer) might >have to look at information in these headers before the payload is passed >to the application. > >Regards, >Marty > >**************************************************************************** >********* > >Martin W. Sachs >IBM T. J. Watson Research Center >P. O. B. 704 >Yorktown Hts, NY 10598 >914-784-7287; IBM tie line 863-7287 >Notes address: Martin W Sachs/Watson/IBM >Internet address: mwsachs @ us.ibm.com >**************************************************************************** >********* > > > >Christopher Ferris - XTC Advanced Development <chris.ferris@east.sun.com> >@xtacy.East.Sun.COM on 11/16/2000 02:03:09 PM > >Please respond to ebxml transport <ebxml-transport@lists.ebxml.org> > >Sent by: cferris@xtacy.East.Sun.COM > > >To: ebxml transport <ebxml-transport@lists.ebxml.org> >cc: >Subject: Re: missing(?) header element > > > >As a follow-up to today's discussion on this topic >the following issues were raised: > >- we need to determine from the other verticals > (e.g. RosettaNet, OTA, EDI/INT, Ariba, others) > whether this feature is used extensively, and > to what end (e.g. does it trickle down to the > application layer? via what mechanism is this > ensured?)? >AI: anyone with specific knowledge or experience > in this regard should speak up! ;-) It would > also be useful if we could have specific feedback > from members participating in other verticals > (such as RosettaNet or OTA) as to whether they > see this feature as important/critical to > acceptance/adoption of ebXML should that question > be on the table. > >- we would need to provide specific language which > outlines its purpose and intent. Does it apply > exclusively to the MSH or does it apply to the > application? Is it used only by convention between > two parties engaged in establishing a production > exchange, each agreeing to well defined ground-rules > for its use? Is its purpose exclusively limited to > "testing" the MSH configuration/handling of a > given message (e.g. it SHALL NOT be forwarded > to application-level routing...) > >- John Ibbotson and others suggested that a specific > MSH Service/Action of MSH/PING might satisfy the > requirements better. This would fall into the > work (TBD) of defining an MSH "Service Interface" > with specific Service/Action pairs which have > specific behavior (e.g. expected response, exceptions, > etc.) defined. > >- Scott H and others suggested that without a > clearly defined architecture for incorporating > "application-level" headers in the ebXML packaging > we are essentially left with placing this sort > of header element within the body of the ebXMLHeader. > >- Chris re-raised the issue of adding in an explicit > extension mechanism to the ebXML headers to allow for > "application-level" headers such as test/production flag, > security/session context information, transaction context > information (ie. XAML) and others. > > e.g. > > <!ELEMENT ebXMLHeader (Manifest, Header, > RoutingHeader, ANY)> > > or > > <element name="ebXMLHeader" type="ebXMLHeader"/> > <complexType name='ebXMLHeader'> > <element ref='Manifest' minOccurs='1'/> > <element ref='Header' minOccurs='1'/> > <element ref='RoutingHeader' minOccurs='0' maxOccurs="1"/> > <any minOccurs='0' maxOccurs='*'/> > ... > </complexType> > > with the addition of something along the lines of > mustUnderstand and actor attributes defined. > >- Maryann raised the issue of security implications > for a test/production indicator as well as possible > concerns for XML Signature handling of ebXML headers > if an arbitrary extension mechanism were defined. > >clearly, the issue is still not resolved and there >is not yet consensus beyond the fact that the proposed >functionality seems to have some potential merit >but that the means of conveying this feature needs >more work and more thought. > >Have I captured the highlights of the discussion >and issues thus far? > >Cheers, > >Chris > >-- > Christopher Ferris > _/_/_/_/ _/ _/ _/ _/ Sr Staff Engineer - XTC Advanced Development > _/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063 > _/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM > _/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop: UBUR03-313 >_/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA 01803-0903 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC