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 presentUsage 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" flagsRegards, 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
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
