Subject: [Speechsc] Message Framing

From: Adam Roach <[email-masked]>
Date: Wed, 23 Jul 2003 19:24:19 -0500

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

---

From: Sarvi Shanmugham <[email-masked]>
Date: Wed, 23 Jul 2003 21:54:00 -0700

sounds reasonable.
I will make the necessary changes, if no has any objections.

Sarvi