RE: I think we should relook at John's "Proposal for message head er" dated march 9

[Christopher Ferris <chris.ferris@east.sun.com>]

David/All,

Here are my comments on the list of headers.

2 - why isn't message type in the manifest? I am assuming
that the list corresponds to the payload parts. Maybe I'm
missing something?

3 - what is the distinction between service type and
message set choreography? Also, would we want these
to be URNs?

5c - why isn't this merely optional? If absent, then there
is no referenced message. Much more net-friendly
than including excess baggage.

7 & 8 - are logical address and logical address id the
same as a URN? Should we explicitly state that it is
expected to be a URN? Would it be necessary to have
both if it is a URN (assuming that we can leverage
THTTP to resolve N2L or N2whatever) within the transport.

9 - wouldn't QoS be held in the functional equivalent of the tpa
held in a repository somewhere? It would seem unnecessary
in the header of each message if this is indeed the case because
it has been established as part of the e-agreement.

10 - I would think that we might want to consider the manifest
to be a required element. However, we may also want to consider
that the header is in fact a manifest with a self contained set of
header elements. Either that or it is separate from the header.

Document Reference would be a CID? Could it also refer
to an external resource (eg. URI/URL)?

Please help me understand why all of the MIME info is
contained within the manifest when it is also going to be expressed
as MIME headers in the appropriate MIME part.

What purpose do service type and intent serve in the manifest?

13 & 14 - as with QoS, wouldn't this information be available
in the functional equivalent of the tpa? Seems unnecessarily
redundant to include them in each message.

Cheers,

Chris