Subject: NEW SECTION: BEEP Considerations

From: Doug Royer <[email-masked]>
Date: Sat, 16 Feb 2002 18:54:01 -0700

This is an outline of a new section.

After looking at the examples in CAP, it became apparent to me
that a casual implementer might not notice that BEEP can
split payloads.

-------------------------------------

x.x.x.1 BEEP considerations.

 NOTES:

    BEEP payloads are NOT guaranteed to be complete CAP
    commands or replies. The BEEP protocol may have to split
    the data according to the TCP record sizes.
    See RFC-3081 sections:

	   (3.) ...avoid starvation AND ...window...
           (3.1) SEQ frame
           (3.1.4) Use of flow control

    That means that the CUA and CS MAY have to re-assemble
    the BEEP packets. This is the purpose of the BEEP SEQNO 
    in the BEEP frame and BEEP SEQ frame packets in RFC-3081.

    Implementations MUST NOT assume that a BEEP MSG, RPY or ANS
    contains a complete CAP; command, reply, or error.

    If a command or reply can not fit inside of a payload
    because of the window size, then the CS and the CUA
    MUST BE prepared to reassable the packets.

---

From: Marshall Rose <[email-masked]>
Date: Sun, 17 Feb 2002 08:21:56 -0800

> ...

you're really making this much harder than it has to be. a beep implementation should either transparently handle segmentation/reassembly for you; or, provide an explicit api for dealing with it. eithe way, it's really not an issue to someone implementing cap...

/mtr

---

From: Doug Royer <[email-masked]>
Date: Sun, 17 Feb 2002 10:14:03 -0700

Marshall Rose wrote:
> you're really making this much harder than it has to be. a beep
> implementation should either transparently handle segmentation/reassembly
> for you; or, provide an explicit api for dealing with it. eithe way, it's
> really not an issue to someone implementing cap...

I am really glad to hear that. 

Are you saying that if I have a 100MB inline attachment
that I am guaranteed to get (and send) that in one MSG no matter
what window size ? Won't that clog the session?

If you are saying the a CAP implementation must worry about
the window size and the CAP protocol does not specify need to say
that. Then I think we agree. I was not proposing that we ADD to 
the CAP protocol. I was attempting to make a note to the
implements that they have to care and create that API.

---

From: Marshall Rose <[email-masked]>
Date: Sun, 17 Feb 2002 11:54:32 -0800

> what window size ? Won't that clog the session?

what i'm saying is that the fact that beep will segment/reassemble very large messages is immaterial to CAP the protocol.

whatever BEEP implementation that someone uses to implement CAP will either hide this detail from the CAP implementor or will expose it. either way, it is an implementation detail not a protocol detail...

> implements that they have to care and create that API.

okay, i guess.

/mtr

---

From: Marshall Rose <[email-masked]>
Date: Sun, 17 Feb 2002 16:15:01 -0800

> > what i'm saying is that the fact that beep will segment/reassemble very
> > large messages is immaterial to CAP the protocol.
> 
> Yes -  However if you look at the CAP document itself, it HAD
> statements like 'each iCalendar object reply will be in a separate
> ANS' packet. Which is bogus because CAP can not specify that all
> BEEP payloads will be split exactly at iCalendar boundaries.
> Correct?

then i wouldn't use the term "packet". if the term "message" is used, there is no problem.

/mtr

---

From: Doug Royer <[email-masked]>
Date: Sun, 17 Feb 2002 17:48:17 -0700

> then i wouldn't use the term "packet". if the term "message" is used,

I don't follow. Are you saying "I am right - no problem",
or are you saying "cap is right - no problem" ?

---

From: Marshall Rose <[email-masked]>
Date: Mon, 18 Feb 2002 09:24:01 -0800

> or are you saying "cap is right - no problem" ?

what i'm saying is that the text you proposed makes things less clear rather than more clear. if your concern is that the use of the terms "packet" or "frame" in the cap spec is confusing to people who know beep, then use the term "message" instead.

/mtr

---

From: Doug Royer <[email-masked]>
Date: Mon, 18 Feb 2002 10:34:32 -0700

Marshall Rose wrote:
> what i'm saying is that the text you proposed makes things less clear
> rather than more clear. if your concern is that the use of the terms
> "packet" or "frame" in the cap spec is confusing to people who know beep,
> then use the term "message" instead.

Okay. But I am still confused. So let me ask the question
directly.

If as part of a CAP reply, the CS calls a BEEP API to send a
100MB message. BEEP can split and send it into multiple ANS
messages? Correct?

So we should not mandate that 100% of all CAP objects
fit into exactly one MSG, RPY, or ANS message. Correct?

BTW - I ordered you O'Reilly BEEP book from Amazon - I am 
anxiously awaiting its release. I hope it helps all CALSCH
implementers understand BEEP.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 18 Feb 2002 15:01:38 -0500

> > BEEP payloads will be split exactly at iCalendar boundaries.

[ Curiously, I didn't get Doug's reply on the mailing list!? ]

> then i wouldn't use the term "packet". if the term "message" is used, there is no problem.

I've looked in the draft, and I couldn't find the word "packet"
anywhere in the text.  Maybe Doug could tell us which part of
the draft he's making reference to.

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Mon, 18 Feb 2002 13:57:44 -0700

> the draft he's making reference to.

Hmm - I wonder what I meant?

---

From: Marshall Rose <[email-masked]>
Date: Mon, 18 Feb 2002 16:15:54 -0800

> 100MB message. BEEP can split and send it into multiple ANS

yes, and it will do it without any change required to CAP.

> fit into exactly one MSG, RPY, or ANS message. Correct?

perhaps we should also talk about TCP, IP, and 802.3/.11 framing while we're at it.

what's the point?

the only thing that gets achieved by stating the very obvious in a standards document is to force the reader to ask "why did the writer feel compelled to state this very obvious thing here? what am i missing?"

once again, less is better...

/mtr