I would offer the syntax looks simpler, but the parser gets more complicated. The parser now needs to track state and set tables with direction, instead of simple set tables.

Moreover, once one lists media types in the negotiation (a subject of a coming thread), we are talking about potentially adding hundreds of mandatory bytes to the message, whereas the simplification proposed below saves at most 30 bytes.

Therefore, I would offer we keep the ABNF as it is.


On Oct 25, 2008, at 7:50 AM, Jeroen van Bemmel wrote:

Current draft (with Recv fix):

Info-Package        =  "Info-Package" HCOLON Info-package-type
 Send-Info           =  "Send-Info" HCOLON Info-package-type
                        *( COMMA Info-package-type )
 Recv-Info           =  "Recv-Info" HCOLON Info-package-type
                        *( COMMA Info-package-type )
 Info-package-type   =  Info-package-name *( "." Info-package-param)
 Info-package-name   =  token-nodot
 token-nodot         =  1*( alphanum / "-"  / "!" / "%" / "*"
                            / "_" / "+" / "`" / "'" / "~" ) ;rfc3265
 Info-package-param  =  generic-param  ;this doesn't work due to dot!


From an implementation perspective, this is unnecessarily complex and verbose: if a UA can both send and receive the same INFO package, it must list it twice.

As an alternative, I would propose something similar to SDP media streams:

Supported-Info = "Supported-Info" HCOLON Info-package-type *(COMMA Info-package-type)
Info-package-type   = token *( SEMI Info-package-param )
Info-package-param = "sendonly" / "recvonly" / generic-param ; only one of "sendonly" or "recvonly" may be present

Usage would be to include 1 "Supported-Info" header in requests/ responses, instead of 2 separate "Send-Info" / "Recv-Info". By default a package is "sendrecv" (i.e. UA may send it, and can receive it), unless overridden by "sendonly" or "recvonly" flags

Regards,
Jeroen


_______________________________________________
Sip mailing list  https://www.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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Sip mailing list  https://www.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

Reply via email to