Subject: [Speechsc] MRCPv2 Status

From: Eric Burger <[email-masked]>
Date: Sun, 25 Feb 2007 19:45:24 -0800

You may be wondering why we've gone silent for a few months.  In preparation
of the IESG Shepherding write-up, quite a few typographical errors, many of
which had protocol implications, were found.  There were enough to the point
where it was clear that the document would never pass IESG muster.

In addition, many, many, many protocol elements were listed as SHOULD's.
Upon close examination, many are really MUST's, and a bunch are MAY's.  This
is a very important distinction in that interoperability of protocols tend
to be directly proportional to the ratio of MUST:SHOULD.  That is, the fewer
SHOULDs, the more interoperable the protocol is.

The litmus test is that every SHOULD clause has to have an UNLESS clause
that explains why the clause is a SHOUD and not a MUST (or MAY).  A
construction that ends up "A MRCPv2 server SHOULD do foo unless it does not
fell like it" really means that foo is a MAY.  Likewise, "A MRCPv2 client
SHOULD do bar," where there is no clear reason bar should ever not be done,
really means that bar is a MUST.

The editors are going through a final scrubbing of the document and will be
producing a new draft before the Prague draft deadline.  We will do another
Work Group Last Call (WGLC) on that document before redoing the IESG
Shepherd document and passing it to the IESG.

As before, we will NOT entertain WGLC comments that will extend the
protocol.  We will save that for work group re-chartering, if that is what
the IESG and work group wishes to do at that time.

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

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

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 27 Feb 2007 21:00:40 -0000

I must admit I've only scanned SPEECHSC, but one thing I noticed with the 
ABNF is that some times the white space seems implicit, and some times it 
seems explicit.

For example:

portlist        =       portnum *("," *LWS portnum)

seems explicit about mentioning where whitespace is allowed, whereas:

cookie2         =       attribute "=" value *(";" cookie-av2)

(in the same section) presumably allows implied whitespace.

Also,

content-encoding =    "Content-Encoding" ":"
                      *WSP content-coding
                      *(*WSP "," *WSP content-coding *WSP )
                      CRLF
and:

cache-control    =    "Cache-Control" ":"
                      [*WSP cache-directive
                      *( *WSP "," *WSP cache-directive *WSP )]
                      CRLF

seem quite explicit about whitespace (btw - should the WSPs be LWSs?), but:

active-request-id-list = "Active-Request-Id-List" ":"
                         request-id *("," request-id) CRLF

seems implicit.

If you're polishing up the text, would it be worth doing the same to the 
ABNF?

Also, while I found text that said leading and trailing whitespace in field 
content could be removed, and intervening whitespace collapsed, I didn't 
find anything that said LWS can go between any token (although I might have 
missed it).

Regards,

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx
(or http://www.xml2cpp.com)
=============================================