Subject: [Sip] info-event: syntax simplification

From: Jeroen van Bemmel <[email-masked]>
Date: Sat, 25 Oct 2008 13:50:54 +0200

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Eric Burger <[email-masked]>
Date: Thu, 30 Oct 2008 13:09:46 -0400

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:

> 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.
>
> 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
>
>