Subject: RE: [Simple] Review of draft-ietf-simple-message-sessions-08 - Chunking

From: [email-masked]
Date: Mon, 27 Sep 2004 13:42:00 +0300

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Paul Kyzivat
> Sent: 24.September.2004 19:20
> To: [email-masked]'
> Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 -
> Chunking
> 
> 
> Out approach to chunking has evolved thru the versions, and 
> the document
> doesn't seem wholely clear and consistent about what we have 
> arrived at.
> In fact, I am not entirely certain I know fully what we have decided,
> and I can't figure it out for certain from the document. I 
> would propose
> specific wording changes, but first I want to get clarification about
> how we think it should now work.
> 
> Based on scattered information in the doc, and reading between the
> lines, and factoring in stuff from conversations along the way, I
> *think* the following is intended:
> 
> - only SEND messages are chunkable
> 
> - there are two kinds of chunks: interrruptible and uninterrupible.
> 
> - a chunk is uninterruptible if it has a Byte-Range header with a
>     numeric range-end.
> 
> - other chunks are interruptible. (No Byte-Range, or a Byte-Range
>     with a range-end of "*".)
> 
> - uninterruptible chunks MUST NOT have a range-end greater than 2048.
> 
> - chunks other than the last SHOULD (or MUST?) have a body ('data'
>     in the syntax) of length exactly 2048. If SHOULD, what is a
>     valid reason to violate?
> 
> - responses never have bodies at all. Requests other than SEND
>     may have a body but are unchunkable. The presence of a Byte-Range
>     in a request other than SEND says nothing about the body of that
>     request. (In REPORT it refers to the SEND being reported on.
>     See separate thread on Byte-Range.) This at best seems irregular
>     and weird.
> 
> Section 6.3.1 says: "it is possible the body is shorter than the
> range-end field indicates. This can occur if the sender interrupted a
> SEND request unexpectedly." Based on what I have interpretted above,
> this is no longer possible. (To be interrupted it must have had a
> range-end of "*".)

I think it is still possible, but it means that it was an abnormal behaviour. Perhaps we should include some text discussing a recovery mechanism for this case.

/Hisham

> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Sep 2004 10:04:05 -0400

> I think it is still possible, but it means that it was an abnormal behaviour. Perhaps we should include some text discussing a recovery mechanism for this case.

It is abnormal in the sense that it can only arise if there is a 
violation of the specification. Normally we don't specify corrective 
action in those cases.

If there is reason we can recommend a recovery action (it is pretty 
obvious), but should at least note that this is recovery from incorrect 
sender behavior.

	Paul