RE: [DR008] - passing arbitrary content

>   [DR6xx] Arbitrary content (to include binary data) outside the
>   XP message shall be accommodated by the protocol binding or in
>   a manner completely independent of that XP message.

Um, I'm still trying to make out why 'Arbitrary content' is different
from 'application specific content' - they are both arbitrary and
scope free to my mind. If you agree, then then let me remind you
of the text of R700a:

"The XP specification must define a mechanism or mechanisms that
allow applications to submit application-specific content or information
 for delivery by XP. In forming the standard for the mechanisms, the XP
 specification may consider support for:
 - carrying application specific payloads inside the XP envelope,
 - referring to application specific  payloads outside the XP envelope,
 - carrying nested XP envelopes as application specific data within the
   XP envelope,
 - referring to XP envelopes as application specific data outside the XP
   envelope"

especially I'd like to draw your attention to bullet point number two.

Also, I'm not sure I agree with tying the extension mechanism to the
protocol,
that doesn't feel right at all. Maybe you mean that there should be a way
to map the extension mechanism to different wire representations, depending
on the transport protocol - that I could go for. Example, an XP message
might travel via HTTP and include an ftp hyperlink to the extension data
(this is a valid use case). If this XP message then goes through an
intermediary
that decides to change the protocol to SMTP, then the extension data could
be fetched and mapped to a MIME attachment. I'm saying the extension
mechanism
that we standardize is the same in both cases, just the mapping to the
transport protocols is different. The intermediary will have to understand
that
it must get the extension data to pass it on, but because it implicitly
supports
the HTTP mapping then it should know how to do so.

In summary, I think that the solution to this requirement requires more
thought
rather than the requirement itself.

 cheers
   --oh

--
ohurley at iona dot com
+353 1 637 2639

Received on Wednesday, 6 December 2000 14:59:02 UTC