Subject: RE: [Speechsc] Message Framing

From: Adam Roach <[email-masked]>
Date: Thu, 24 Jul 2003 15:48:57 -0500

I don't know offhand how likely the case you describe is
for speechsc. I'll note that part of the conversations we
had around MSRP included the case in which the size of
messages are not necessarily known when the client first
starts sending them. After much discussion, we concluded
that it was something we could ignore rather safely (and
maybe address at some point in the future by dividing
messages up using the message/partial mime type).

In any case, if you determine that this is a useful case,
you might consider using a string of unique (or at least
unlikely) characters to mark the end of a message, in the
same way the MIME delimits multipart bodies.

I will point out that the "Content-Length" header suffers
from the same restriction that you indicate (you can't send
bodies of unknown size), so going to the framing scheme
that I propose doesn't make the protocol any worse than
what is currently written up in the internet-draft.

/a

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: Thursday, July 24, 2003 15:36
> To: Adam Roach
> Cc: [email-masked]
> Subject: RE: [Speechsc] Message Framing
> 
> 
> Would there ever be a situation where the client does not 
> know beforehand how long the message would be?  E.g., 
> arbitrary text-to-speech?  In this case, the burden of 
> reading and writing the message twice and buffering gets put 
> on the client, as opposed to the server reading the message twice.
> 
> If there is not a case for an unbounded request, or it is 
> very unlikely, I would put the burden on the client.
> 
> > -----Original Message-----
> > From: Sarvi Shanmugham [mailto:[email-masked]]
> > Sent: Thu, July 24, 2003 12:54 AM
> > To: Adam Roach
> > Cc: [email-masked]'
> > Subject: Re: [Speechsc] Message Framing
> > 
> > 
> > sounds reasonable.
> > I will make the necessary changes, if no has any objections.
> > 
> > Sarvi
> > 
> > Adam Roach wrote:
> > 
> > >At the meeting last week, I attempted to raise an issue
> > >of message framing. I believe that my explanation may
> > >have been somewhat unclear, so I will attempt to raise
> > >it here.
> > >
> > >As I do not subscribe to the speechsc mailing list,
> > >please try to keep my address in the recipients list for
> > >any follow-ups on this topic.
> > >
> > >To examine this issue, I will consider the following
> > >example messages from draft-shanmugham-speechsc-00:
> > >
> > >1) Message with a body
> > >
> > >   SPEAK 543257 SPEECHSC/1.0 
> > >   Channel-Identifier: 32AECB23433802 
> > >   Voice-gender: neutral 
> > >   Voice-category: teenager 
> > >   Prosody-volume: medium 
> > >   Content-Type: application/synthesis+ssml 
> > >   Content-Length: 104 
> > >     
> > >   <?xml version="1.0"?> 
> > >   <speak> 
> > >    <paragraph> 
> > >      <sentence>You have 4 new messages.</sentence> 
> > >      <sentence>The first is from <say-as  
> > >      type="name">Stephanie Williams</say-as> 
> > >      and arrived at <break/> 
> > >      <say-as type="time">3:45pm</say-as>.</sentence> 
> > >      <sentence>The subject is <prosody 
> > >      rate="-20%">ski trip</prosody></sentence> 
> > >    </paragraph> 
> > >   </speak> 
> > >
> > >2) Message without a body
> > >
> > >   SPEAK-COMPLETE 543257 COMPLETE SPEECHSC/1.0 
> > >   Channel-Identifier: 32AECB23433802 
> > >
> > >The first issue to note is the difference in handling between
> > >messages with and those without bodies. Messages with bodies
> > >are framed by finding a "Content-Length" header, and counting
> > >that many bytes after a blank line is encountered. Messages
> > >without bodies are simply terminated with a blank line. Note
> > >that even in protocols that use a header to specify body length
> > >(e.g. HTTP and SIP), this is not normal behavior. (SIP and
> > >HTTP take the absence of a "Content-Length" header to mean,
> > >"This message continues until the TCP connection is torn down".)
> > >
> > >The second, and larger, issue pertains to the use of a variable
> > >position header for framing purposes at all. Our experience with
> > >SIP has shown that this type of scheme makes a clean separation
> > >of parsing and framing to be difficult. Most implementations are
> > >forced to perform a rudimentary first pass of parsing to determine
> > >where a message ends, and then re-parsing of the message at a
> > >higher level once it has been read completely from the wire.
> > >This causes many implementations to be less efficient than they
> > >otherwise could be.
> > >
> > >Recognizing this situation, the next opportunity the SIP
> > >community had to design a protocol, we decided to use a
> > >more straightforward framing model. If you examine the
> > >way that MSRP works (see draft-ietf-simple-message-sessions-01),
> > >it encodes message size as part of the leader line.
> > >Specifically, implementations can always look for a number
> > >starting at the 6th character of an MSRP message to determine
> > >the length of the rest of the message. For example:
> > >
> > >    MSRP 57 SEND
> > >    TR-ID: 456
> > >    Content-Type: text/plain
> > >
> > >    Hi, Alice! I'm Bob!
> > >
> > >I encourage SPEECHSC to learn from the experiences of the SIP
> > >community and adopt a similar scheme.
> > >
> > >/a
> > >
> > >_______________________________________________
> > >Speechsc mailing list
> > >[email-masked]
> > >https://www1.ietf.org/mailman/listinfo/speechsc
> > >
> > >  
> > >
> > 
> > 
> > 
> > _______________________________________________
> > Speechsc mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speechsc
> > 
> > 
> 

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

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 25 Jul 2003 10:03:45 -0700

Whatever you do, don't require both the content length approach and search
for a terminating string - this brings you the worst of booth approaches.

---

From: Sarvi Shanmugham <[email-masked]>
Date: Fri, 25 Jul 2003 10:26:07 -0700

From the discussion it looks like any sort of content-length header, as 
it exists or at fixed point very early in the message can cause in 
efficiencies eihter at the client or the server side.

This leaves us with the option of a terminating string. We could either 
go for a fixed terminating string documented in the specification. OR I 
could add a mandatory header field very early in the message to contain 
the terminating string to look for when detecting  the end of the frame.

Sarvi