Subject: RE: [Speechsc] Whitespace in ABNF

From: "Daniel C. Burnett" <[email-masked]>
Date: Mon, 5 Mar 2007 09:48:40 -0500

Pete,

There is no implicit whitespace, or at least there shouldn't be.  Where
no whitespace is listed as being permitted, it's not permitted.

However, I agree with you that the permitted use of whitespace is
inconsistent across headers.

At this point I would prefer to leave them as-is unless we get
complaints from the IESG or unless they cause insurmountable
implementation issues.

Thanks,

Dan Burnett

-----Original Message-----
From: Pete Cordell [mailto:[email-masked]] 
Sent: Tuesday, February 27, 2007 4:01 PM
To: [email-masked]
Subject: [Speechsc] Whitespace in ABNF

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

----- Original Message ----- 
From: "Eric Burger" <[email-masked]>
To: <[email-masked]>
Sent: Monday, February 26, 2007 3:45 AM
Subject: [Speechsc] MRCPv2 Status

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

_______________________________________________
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: Magnus Westerlund <[email-masked]>
Date: Mon, 19 Mar 2007 19:05:36 +0100

> complaints from the IESG or unless they cause insurmountable

Talking from the RTSP experience. If you are inconsistent what will 
happens is that people will not follow the ABNF and instead trying to be 
consistent resulting in that everyone needs to try to have parsers 
beyond the syntax specification. Thus resulting in serious issues with 
extensibility. I would recommend that you actually clean this up. 
Despite it being a dam boring work both for editor and reviewers.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------