RE: Application Headers

["Burdett, David" <david.burdett@commerceone.com>]

Chris said ...

> 2. Remove the mustUnderstand on the ApplicationHeaders
Maybe it is a different attribute name...

... or perhaps we just need to make it information available to the
application when they get the ApplicationHeaders which they can use or
ignore as they decide.

David

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Friday, January 05, 2001 9:14 AM
To: Burdett, David
Cc: ebXML Transport (E-mail)
Subject: Re: Application Headers


David,

Please see below.

Cheers,

Chris

"Burdett, David" wrote:
> 
> Chris
> 
> Actually, I think there are two cases here:
> 1. Additional data that needs to be understood by the MSH, and
> 2. Additional data that needs to be understood by the application.
> 
> I guess the former is covered by the wildcard element within the header
> element, and the latter is the responsibility of the application.
> 
> Does this mean that we need to:
> 1. Include a mustUnderstand on the wildcard element?

Yes, I think that Robert's recent comments cover that. Certainly,
we have discussed it and it should be the case...

> 2. Remove the mustUnderstand on the ApplicationHeaders

Maybe it is a different attribute name...

> 
> There are also issues around saying a MSH mustUnderstand the extensions in
> that which MSH mustUnderstand it when a message is going through several
> hops.

Good point...

> 
> So perhaps we should an optional mustUnderstand to the header element with
a
> semantic that the To Party MSH is the MSH that must understand it, and to
> the Routing Header which is that the receiving MSH (which may be an
> intermediate MSH) must understand it.
> 
> For applicationHeaders, I think we should perhaps remove the
mustUnderstand
> and just require the MSH to make the data available to an application that
> wants it. If the receiving application does not ask for it or cannot
> understand it, then it is an application not a message service problem.

That might be an option...

> 
> Thoughts?
> 
> David
> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
> Sent: Friday, January 05, 2001 7:20 AM
> To: Burdett, David
> Cc: ebXML Transport (E-mail)
> Subject: Re: Application Headers
> 
> David,
> 
> Well, there are two aspects to this...
> 1) the receiving "application" MUST be capable of processing the
> namespace qualified application headers that are qualified with
> a mustUnderstand=true
> 2) the receiving MSH MUST be capable of forwarding/providing
> the namespace qualified application headers that are qualified with
> a mustUnderstand=true to the receiving application
> 
> In either case there needs to be an exception/error reported.
> 
> However, since these are "application" headers, the "application"
> needs to be notified... Hmmm... we may have a layering issue
> to deal with here...
> 
> Chris
> 
> "Burdett, David" wrote:
> >
> > Lines 841-845 say ...
> >
> > >>>An ApplicationHeaders element that has a mustUnderstand set to a
value
> of
> > true means that a receiving MSH MUST be capable of understanding the
> meaning
> > of the namespace-qualified element content. If the content is not
> > understood, the receiving MSH MUST respond with a message that includes
an
> > errorCode of NotSupported in an Error element as defined in section
> 8.8.<<<
> >
> > I don't think that the MSH must understand the elements. It only needs
to
> > recognize the namespace qualified elements and know that it has an
> > application that can handle them.
> >
> > Thoughts?
> >
> > David
> >
> > Solution Strategy, Commerce One
> > 4400 Rosewood Drive, Pleasanton, CA 94588, USA
> > Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599
> > mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com