RE: Comments on issue 101

Dug Davis writes:

>>then that to me would very loudly 
>> imply boxcarring in 2+ body block case.

Not necessarily.  What if part one of the body tells you what to do (get 
stock quote) and part two tells you how to do it better (hints on where to 
look for the data).  We don't say anything about what the semantics of 
each body (or header) entry is, or what they might mean together.  If 
_you_ want to try to use it for boxcarring, that's your business.

I believe I have suggested before that we should say something like:  "For 
a node to understand a header or body entry, it must understand the 
entry'sforspecification not just in isolation, but in conjunction with the 
specification for all other header and body entries targeted to that node. 
 The specifications for such header and body entries MUST describe or 
provide sufficient information to describe their proper use in 
combination;  in cases where the specifications do not provide such 
information, the node MUST NOT "understand" any such entries."

Therefore, if there was more than one body entry, or a body entry in 
combination with one or more header entries for the anonymous actor, the 
above rule will determine whether the endpoint node can indeed process the 
message.  If the specifications call for box carring, that's your 
business.  If, as above, they explain how the second entry will help you 
get stock quotes more effectively, that's fine too.

In practice, I expect that suites of features will be developed for use 
together.  So, for example, we can decide whether a digital signature is 
to be applied before or after a message is encrypted, presuming that both 
functions are requested in separate header entries.  The specification for 
each feature would refer to the other.  In other cases, very broad 
approaches could apply.  So, if I develope the specification for a header 
entry with semantics "caching allowed", I might say "this header entry 
provides declaritive information, and therefore can be "understood" and 
acted upon in conjunction with any other header entry that does not 
specifically disallow caching functions."  Or some such.

Underneath this all is indeed a deeper question that Jacek brought up on 
today's call.   Everyone seems to believe that the body is actually 
different in practice, that it somehow conveys "the main point" of the 
message.  As he says, most existing implementations provide special 
handling for it.  If we really mean it to be special, then we should give 
some guidance as to how it is special, and how it is to be used.  As I 
read the specification today, it implies that you might just as well do 
all your working header entries (except that for mysterious reasons the 
body happens to be required).

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------

Received on Wednesday, 31 October 2001 16:48:51 UTC