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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
http://www.jdrosen.net PHONE: (408) 902-3084
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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
