Re: Proposed resolution of issue 101: relationship between header and body blocks

The two issues are "nearly" orthogonal, except that if the answers to 1) and
2) are "yes" and "no" (resp.), then you have no way of carrying two stock
quotes in the same message. All the other alternatives (yes, yes), (no, yes),
(no, no) would support carrying two stock quotes in the same message. Hence I
don't think they can be quite dealt with independently.

Jean-Jacques.



Noah_Mendelsohn@lotus.com wrote:

> [...]
> 1) are body block(s) in any way philosophically distinct from header
> blocks?
> 2) either way, is more than one body block allowed, and if so what are the
> processing rules?
>
> On the conference call a little over a week ago, there seemed to be a
> fairly clear consensus on indicating that in some way or other, headers
> are for extension functions, and body block(s) are somehow distinct.  This
> represented a change in my own thinking, but we had strong input that in
> practice, implementations need to treat the two very differently.  If
> they're going to be treated differently, then it seems to me that we must
> indeed signal in the specification what those differences are intended to
> be.  I was asked to draft text representing that point of view.
>
> Like Doug, I believe this is nearly orthogonal to the question of whether
> there can be more than one such body entry.  So, it is possible to
> consider a body that carries, for example, two requests for stock quotes,
> each of which is considered to be a "main purpose of the message";
> contrast these with a potential header entry indicating "results of
> requests may be cached".
>
> ------------------------------------------------------------------------
> Noah Mendelsohn                                    Voice: 1-617-693-4036
> Lotus Development Corp.                            Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------------

Received on Thursday, 22 November 2001 11:30:48 UTC