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

["Pete Cordell" <[e-mail]>]

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" <[e-mail]>
To: "Pete Cordell" <[e-mail]>
Cc: <[e-mail]>; "Saravanan Shanmugham (sarvi)" <[e-mail]>; 
"Dan Burnett" <[e-mail]>
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
>
>
>
>
> This e-mail and attachments contain confidential information from HUAWEI, 
> which is intended only for the person or entity whose address is listed 
> above. Any use of the information contained herein in any way (including, 
> but not limited to, total or partial disclosure, reproduction, or 
> dissemination) by persons other than the intended recipient's) is 
> prohibited. If you receive this e-mail in error, please notify the sender 
> by phone or email immediately and delete it!
>
>
> ----- Original Message ----- 
> From: "Pete Cordell" <[e-mail]>
> To: "sreekanth" <[e-mail]>
> Cc: <[e-mail]>
> 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" <[e-mail]>
>> To: "Saravanan Shanmugham (sarvi)" <[e-mail]>; "Dan Burnett"
>> <[e-mail]>
>> Cc: <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/speechsc
>>>
>>
>>
>>
> 



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