Subject: [Sip] INFO Discussion

From: Eric Burger <[email-masked]>
Date: Sun, 16 Nov 2008 20:23:40 -0600

This is what I've gleaned from the list:

•SIP Option Tags? E.g., sip.extension

•Wording clarifications from Arun Arunachalam, John Elwell, Adam Roach

•What to do with subsequent requests with no send/recv-info?
–Use existing set? Saves bytes; session timer code can be INFO-ignorant
–Cancel existing set? Burns bytes, but always works (i.e., 3pcc)

•Allow Contact: in INFO? Probably not.

•send/recv-info headers in INFO? Probably not.

•Case sensitivity in INFO Package names?

Anything else?

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Mon, 17 Nov 2008 00:00:00 -0600

> •SIP Option Tags? E.g., sip.extension

There seems to be some confusion between media feature tags, as used  
in RFV 3840/3841, and SIP option tags.

Option tags are used in Supported and Require, with a common  
application being in Supported header fields sent in response to  
OPTIONS messages. They describe which extensions are supported by the  
UA. I think we need one for INFO packages, because INFO package  
negotiation is clearly an extension to base INFO.

Feature tags, on the other hand, support selective retargeting in  
proxies where the potential targets are discovered via REGISTER  
operations. We may need this too.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Mon, 17 Nov 2008 17:15:29 -0600

> •Case sensitivity in INFO Package names?

What would be the motivation for making it case insensitive? That way 
lies insanity. If you start down the path of case insensitivity, you'll 
eventually find yourself sliding towards an i18n madhouse, calling out 
stringprep profiles and arguing about expressing info package names in 
Navajo.

/a

---

From: Eric Burger <[email-masked]>
Date: Mon, 17 Nov 2008 17:53:07 -0600

Agreed. The text is even stricter. It says octet-by-octet. Who needs  
to care about stinkin' charset encoding!

On Nov 17, 2008, at 5:15 PM, Adam Roach wrote:

> What would be the motivation for making it case insensitive? That  
> way lies insanity. If you start down the path of case insensitivity,  
> you'll eventually find yourself sliding towards an i18n madhouse,  
> calling out stringprep profiles and arguing about expressing info  
> package names in Navajo.
>
> /a

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 20 Nov 2008 14:21:44 +0100

I agree with Dean that feature tags and option tags are two separate
things.

But, in the sip.extensin feature tag you will actually list option tags
:)

sip.extension="100rel, info-packages, almighty-199" etc.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dean Willis
Sent: Monday, November 17, 2008 8:00 AM
To: Eric Burger
Cc: SIP IETF
Subject: Re: [Sip] INFO Discussion

On Nov 16, 2008, at 8:23 PM, Eric Burger wrote:

> *SIP Option Tags? E.g., sip.extension

There seems to be some confusion between media feature tags, as used in
RFV 3840/3841, and SIP option tags.

Option tags are used in Supported and Require, with a common application
being in Supported header fields sent in response to OPTIONS messages.
They describe which extensions are supported by the UA. I think we need
one for INFO packages, because INFO package negotiation is clearly an
extension to base INFO.

--
Dean

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