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

From: Ben Campbell <[email-masked]>
Date: Fri, 1 Oct 2004 17:22:49 -0500

On Sep 24, 2004, at 11:19 AM, Paul Kyzivat wrote:

> 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

Agreed.

>
> - there are two kinds of chunks: interrruptible and uninterrupible.
>

Agreed.

> - a chunk is uninterruptible if it has a Byte-Range header with a
>    numeric range-end.
>

Agreed.

> - other chunks are interruptible. (No Byte-Range, or a Byte-Range
>    with a range-end of "*".)
>

Agreed.

> - uninterruptible chunks MUST NOT have a range-end greater than 2048.
>

Agreed--which implies that range-end can never be >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?
>

Disagree. I could have sent considerably more than 2k of an 
interruptible chunk prior to actually interrupting it.

> - 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.

I would further be willing to say that byte-range MUST NOT exist in 
anything but SEND and REPORT. And if the overloading in report really 
bothers people, I am willing to change the name of the header in the 
context of REPORT.

>
> 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 "*".)

This is a leftover from before we defined the rules for putting "*" in 
byte-range. We could remove it, although there might be some benefit in 
doing this for resiliency sake. Perhaps dropping it to a MAY?

Since Orit made the same complaint, I guess I am willing to cut it 
completely.

>
>
>
> _______________________________________________
> 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: Sun, 03 Oct 2004 11:37:22 -0400

> interruptible chunk prior to actually interrupting it.

Oops - I didn't say exactly what I meant. Yes I agree an *interruptible* 
chunk can be larger. My comment was intended to apply only to 
*uninterruptible* chunks.

So the question is whether it is permissible for a noninterruptible, 
non-final, chunk to be less than 2048 bytes long. (We have already 
settled that it can't be more than 2048.)

> bothers people, I am willing to change the name of the header in the 

Either of these would be ok with me. (But doesn't it also have to be in 
a response?)

Another question is whether we think there may ever be additional 
messages that might need to use Byte-Range to chunk a large body. My 
general philosophy would be to leave that as a possibility, but I have 
no particular reason to think that is important.

> doing this for resiliency sake. Perhaps dropping it to a MAY?

I would prefer to see this ruled an error. (MUST NOT) It just eliminates 
an unnecessary implementation decision.

> Since Orit made the same complaint, I guess I am willing to cut it 

	Paul