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

From: [email-masked]
Date: Mon, 27 Sep 2004 17:33:45 +0300

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 27.September.2004 17:04
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] Review of 
> draft-ietf-simple-message-sessions-08 -
> Chunking
> 
> 
> 
> 
> [email-masked] wrote:
> > 
> >>-----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.
> 
> 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.

No, I meant device or user behaviour that causes the sending to be immediately aborted. Nothing to do with protocol violation. (eg: abnorla termination of the application).

/Hisham

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Sep 2004 11:40:53 -0400

> No, I meant device or user behaviour that causes the sending to be immediately aborted. Nothing to do with protocol violation. (eg: abnorla termination of the application).

As best I can tell, we are saying that you must decide, when beginning 
to send, whether to use an interruptible chunk, or an uninterruptible 
chunk. If you use an uninterruptible chunk you specify the range-end as 
a number and include that many bytes of body. If you choose an 
interruptible chunk, you use "*" for range-end and then you put as much 
body as you like.

An application that chooses to use an uninterruptible chunk, and then 
fails to include the full number of bytes for it has violated the protocol.

Effectively, an application should only use an uninterruptible chunk if 
it already has all the bytes in hand and ready to send.

	Paul