Re: [Speechsc] Query in the general message header ABNF

Hi ,

This is a quote from the section 6.2 of mrcpv2-draft-11

 message-header = field-name ":" [ field-value ]

 field-name = token

 field-value = *LWS field-content *( CRLF 1*LWS field-content)

 field-content = <the OCTETs making up the field-value
 and consisting of either *TEXT or combinations
 of token, separators, and quoted-string>

We have missed one point in the above grammar for generic headers.There can be an empty line in the field value..

Pls consider the example for the Active-Request-Id-List header...

Active-Request-Id-List: 123, CRLF LWS 125 CRLF

The definition of LWS is  LWS    =    [*WSP CRLF] 1*WSP ; linear whitespace

Now if the LWS again contains CRLF followed by WSP, then it becomes

Active-Request-Id-List: 123, CRLF CRLF WSP 125 CRLF

which as per the ABNF is the beginning of the message body..

I suggest to change the generic grammar to 

 field-value = *LWS field-content *( *LWS field-content)

since any parser implemention MUST be robust enough to receive messages with or without the LWS..

Pls clarify on this..

Regards,
Sreekanth

----- Original Message ----- 
From: "Pete Cordell" <pete@tech-know-ware.com>
To: "sreekanth" <sreekanthm@huawei.com>
Cc: <speechsc@ietf.org>
Sent: Wednesday, December 06, 2006 2:58 PM
Subject: Re: [Speechsc] Query in the general message header ABNF

> It's *LMS and 1*LWS.  Therefore, the following is also legal (although not 
> recommended):
> 
> header:                                      // CRLF and WSP CRLF -> LWS
>                                                  // WSP CRLF -> LWS
>                                                  // WSP CRLF -> LWS
>  foo                                            // WSP CRLF -> LWS
>                                                  // WSP CRLF -> LWS
>                                                  // WSP CRLF -> LWS
>  bar                                            // WSP CRLF -> LWS
>  =                                               // WSP CRLF -> LWS
>  18
> 
> 
> I will have to let others address the other issues you raised.
> 
> 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: "sreekanth" <sreekanthm@huawei.com>
> To: "Pete Cordell" <pete@tech-know-ware.com>
> Cc: <speechsc@ietf.org>; "Saravanan Shanmugham (sarvi)" <sarvi@cisco.com>; 
> "Dan Burnett" <dan_burnett2000@yahoo.com>
> Sent: Monday, December 04, 2006 9:24 AM
> Subject: Re: [Speechsc] Query in the general message header ABNF
> 
> 
>> Hi Pete,
>>
>> Thanks for replying..
>>
>> 1) I still have one more query on the section 6.2 defning the header 
>> grammar..
>>
>> message-header = field-name ":" [ field-value ]
>> field-name = token
>> field-value = *LWS field-content *( CRLF 1*LWS field-content)
>> field-content = <the OCTETs making up the field-value
>>  and consisting of either *TEXT or combinations of token, separators, and 
>> quoted-string>
>>
>> As per the field value syntax, we can msg hdrs like
>>
>> header:                                      // CRLF and WSP CRLF -> LWS
>>                                                  // WSP CRLF -> LWS
>> foo                                            // WSP CRLF -> LWS
>>  bar                                            // WSP CRLF -> LWS
>>  =                                               // WSP CRLF -> LWS
>>  18CRLF
>>
>> Since the LWS([*WSP CRLF] 1*WSP) can again have WSP followed by CRLF.. 
>> There can be 2 lines after the header: in the above example..
>>
>>
>> 2) The draft does not explain the ABNF grammar for Extension header.
>>
>> 3) The ABNF grammar for voiceprint-identifier has some ambiguity .
>>
>>    "Voiceprint-Identifier" ":" 1*VCHAR "." 1*VCHAR *[";" 1*VCHAR "." 
>> 1*VCHAR] CRLF
>>
>>    The seperator '.'  is again part of VCHAR.. So there is a overlap 
>> between the Header Value and the seperator..
>>
>>
>>
>> Pls clarify on this.
>>
>>
>> Regards,
>> Sreekanth
>>

>>
>>
>> ----- Original Message ----- 
>> From: "Pete Cordell" <pete@tech-know-ware.com>
>> To: "sreekanth" <sreekanthm@huawei.com>
>> Cc: <speechsc@ietf.org>
>> Sent: Thursday, November 23, 2006 5:01 PM
>> Subject: Re: [Speechsc] Query in the general message header ABNF
>>
>>
>>> Hi Sreekanth,
>>>
>>> This is the general format of all headers, and the concept is consistent
>>> across many protocols including SMTP, HTTP and SIP.  This general rule
>>> allows you to readily find the beginning of headers without having to do
>>> detailed parsing of each header (e.g. just look for non-white space after 
>>> CR
>>> LF).  It also allows you to skip over, possibly ignorable, headers that 
>>> may
>>> not be defined yet.
>>>
>>> BTW - this isn't just for list type headers.  It can be used for any 
>>> header
>>> that benefits from being spread across multiple lines. e.g.:
>>>
>>> MyHeader: foo
>>>    bar
>>>    do
>>>    da
>>>    =
>>>    18
>>>
>>>
>>> To the doc authors:
>>> --------------------
>>> I note that section 6.2 says: "The value MAY be preceded by any amount of
>>> LWS, though a single SP is preferred."  However, most of the examples 
>>> don't
>>> include a space.  Maybe no space is preferred for MRCP?
>>>
>>> Also, I can't find anywhere that says whether the EBNF grammar is 
>>> explicit
>>> about where white space can be included or not.  Some rules suggest that 
>>> it
>>> is and some rules imply that it is not (i.e. no mention of optional WS).
>>> Sorry if this has been raised before.
>>>
>>> And, just in case it's not been raised before, should the EBNF for the
>>> method name and message-header be made extensible? e.g. something like:
>>>
>>> method-name      =    generic-method
>>>                 /    synthesizer-method
>>>                 /    recorder-method
>>>                 /    recognizer-method
>>>                 /    verifier-method
>>>                 /    token   ; <------
>>>
>>> message-header   =    1*(generic-header / resource-header /
>>> extension-header)
>>>
>>> extension-header = field-name ":" [ field-value ]
>>>
>>> If appropriate, perhaps these issues can be discussed at the start of the
>>> EBNF section (15).
>>>
>>>
>>> HTH,
>>>
>>> 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: "sreekanth" <sreekanthm@huawei.com>
>>> To: "Saravanan Shanmugham (sarvi)" <sarvi@cisco.com>; "Dan Burnett"
>>> <dan_burnett2000@yahoo.com>
>>> Cc: <speechsc@ietf.org>
>>> Sent: Wednesday, November 22, 2006 6:56 AM
>>> Subject: [Speechsc] Query in the general message header ABNF
>>>
>>>
>>>> This is a quote from the section 6.2 of mrcpv2-draft-11
>>>>
>>>> message-header = field-name ":" [ field-value ]
>>>>
>>>> field-name = token
>>>>
>>>> field-value = *LWS field-content *( CRLF 1*LWS field-content)
>>>>
>>>> field-content = <the OCTETs making up the field-value
>>>>
>>>> and consisting of either *TEXT or combinations
>>>>
>>>> of token, separators, and quoted-string>
>>>>
>>>>
>>>>
>>>> As per the above rule if the header if of list type,  is it  mandatory
>>>> that the multiple header values MUST have atleast one LWS???
>>>>
>>>> In the header ABNF already seperator for the multiple values is 
>>>> defined..
>>>> So Why do we need this LWS??
>>>>
>>>> Pls clarify on this.
>>>>
>>>> Sreekanth
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --------------------------------------------------------------------------------
>>>
>>>
>>>> _______________________________________________
>>>> Speechsc mailing list
>>>> Speechsc@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/speechsc
>>>>
>>>
>>>
>>>
>> 
> 
> 
>