Re: [Sip] SIPit21: BNF future-proofing problem?

[Jonathan Rosenberg <[e-mail]>]

This strikes me as a problem in theory and not in practice. AFAICT, the 
only characters you can't use are ascii 0x00-0x19 (0x20 is space and is 
possible through the LWS construct as Christer pointed out). Is there a 
practical use case for any of these? They are:

   Decimal   Octal   Hex    Binary     Value
        -------   -----   ---    ------     -----
          000      000    000   00000000      NUL    (Null char.)
          001      001    001   00000001      SOH    (Start of Header)
          002      002    002   00000010      STX    (Start of Text)
          003      003    003   00000011      ETX    (End of Text)
          004      004    004   00000100      EOT    (End of Transmission)
          005      005    005   00000101      ENQ    (Enquiry)
          006      006    006   00000110      ACK    (Acknowledgment)
          007      007    007   00000111      BEL    (Bell)
          008      010    008   00001000       BS    (Backspace)
          009      011    009   00001001       HT    (Horizontal Tab)
          010      012    00A   00001010       LF    (Line Feed)
          011      013    00B   00001011       VT    (Vertical Tab)
          012      014    00C   00001100       FF    (Form Feed)
          013      015    00D   00001101       CR    (Carriage Return)
          014      016    00E   00001110       SO    (Shift Out)
          015      017    00F   00001111       SI    (Shift In)
          016      020    010   00010000      DLE    (Data Link Escape)
          017      021    011   00010001      DC1 (XON) (Device Control 1)
          018      022    012   00010010      DC2       (Device Control 2)
          019      023    013   00010011      DC3 (XOFF)(Device Control 3)
          020      024    014   00010100      DC4       (Device Control 4)
          021      025    015   00010101      NAK    (Negative 
Acknowledgement)
          022      026    016   00010110      SYN    (Synchronous Idle)
          023      027    017   00010111      ETB    (End of Trans. Block)
          024      030    018   00011000      CAN    (Cancel)
          025      031    019   00011001       EM    (End of Medium)
          026      032    01A   00011010      SUB    (Substitute)
          027      033    01B   00011011      ESC    (Escape)
          028      034    01C   00011100       FS    (File Separator)
          029      035    01D   00011101       GS    (Group Separator)
          030      036    01E   00011110       RS    (Request to 
Send)(Record Separator)
          031      037    01F   00011111       US    (Unit Separator)


I don't think this is a real problem.

-Jonathan R.

Robert Sparks wrote:
> The BNF in 3261 says the following:
> 
> extension-header  =  header-name HCOLON header-value
> header-value      =  *(TEXT-UTF8char / UTF8-CONT / LWS)
> 
> This is intended to be the catch-all field for all future extensions - 
> older parsers working against this BNF shouldn't barf
> when we introduce a new header field.
> 
> Now, we may have new fields in the future that look like:
> 
> NewHeader = new-header-name HCOLON quoted-string
> 
> And down inside quoted-string, we get:
> 
>       quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
>       qdtext         =  LWS / %x21 / %x23-5B / %x5D-7E
>                         / UTF8-NONASCII
>       quoted-pair  =  "\" (%x00-09 / %x0B-0C
>                        / %x0E-7F)
> 
> So, for instance, we could have inside a quoted string the 2 byte 
> sequence \ NULL
> 
> This does not parse against header-value above...
> 
> Is this a problem? Some of the SIPit21 participants argued that it is.
> 
> The projects I've been involved in don't parse unknown headers and the 
> stacks will just hand up an unparsed bucket of bits (the only rules
> used are those necessary to identify the next header-field starting).
> 
> Would it be worth the effort to make the BNF reflect that rather than 
> continuing with the incongruity that we currently specify?
> 
> RjS
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[e-mail]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip