Subject: [sipcore] Caller prefs / callee caps for INFO Event

From: Jeroen van Bemmel <[email-masked]>
Date: Wed, 11 Nov 2009 14:58:10 +0100

Has it been considered to extend RFC3840/RFC3841 with a parameter for 
INFO Packages?

Regards,
Jeroen

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Nov 2009 09:19:25 -0500

Can anyone imagine a case where you would choose one potential UAS over 
another based on support for Info Packages?

	Thanks,
	Paul

Jeroen van Bemmel wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 11 Nov 2009 15:27:33 +0100

I assume you mean the extension in general, rather than specific Info packages. 

I could imagine that one might define a feature tag in parallel with a specific Info package.

That of course is outside the scope of draft-ietf-sipcore-info-event, but it is a reason why we don't need to put Recv-Info into the REGISTER method. 

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Wednesday, November 11, 2009 2:19 PM
> To: Jeroen van Bemmel
> Cc: [email-masked]
> Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event
> 
> Can anyone imagine a case where you would choose one 
> potential UAS over another based on support for Info Packages?
> 
> 	Thanks,
> 	Paul
> 
> Jeroen van Bemmel wrote:

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 12 Nov 2009 04:29:13 +0100

Hi,

We discussed that a while ago, when we dicussed the meaning of Recv-Info
in REGISTER. Adam suggested that we do that in a separate draft (since
we are in WGLC).

Regards,

Chritser 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jeroen van Bemmel
Sent: 11. marraskuuta 2009 16:58
To: [email-masked]
Subject: [sipcore] Caller prefs / callee caps for INFO Event

Regards,
Jeroen

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 12 Nov 2009 04:32:56 +0100

Hi Keith,

There was not much discussion on this, since we should concentrate on
getting the core spec done, but one idea was that specific Info Packages
COULD define values. The details (whether we would use a namespace etc)
would of course  have to be discussed.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of DRAGE, Keith (Keith)
Sent: 11. marraskuuta 2009 17:28
To: Paul Kyzivat; Jeroen van Bemmel
Cc: [email-masked]
Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event

I assume you mean the extension in general, rather than specific Info
packages. 

I could imagine that one might define a feature tag in parallel with a
specific Info package.

That of course is outside the scope of draft-ietf-sipcore-info-event,
but it is a reason why we don't need to put Recv-Info into the REGISTER
method. 

regards

Keith

> Can anyone imagine a case where you would choose one potential UAS 
> over another based on support for Info Packages?
> 
> 	Thanks,
> 	Paul
> 
> Jeroen van Bemmel wrote:

---

From: Jeroen van Bemmel <[email-masked]>
Date: Thu, 12 Nov 2009 13:56:12 +0100

I mean something similar to

events="!presence,message-summary" (RFC3840)

so maybe 

+sip.info-packages="foo,!bar"

The point would be to standardize the tag name that is used. This will enable a UA to announce the Info packages it supports in REGISTER, and enables routing based on that information.
The use case for this is the same as for event packages, it's mostly for sake of completeness / consistency

I don't see why it would hurt to add this item to the draft, seems overkill to write a separate RFC just for this

Regards,
Jeroen

DRAGE, Keith (Keith) wrote:
>>> Has it been considered to extend RFC3840/RFC3841 with a 
>>>       
>> parameter for 
>>     
>>> INFO Packages?
>>>
>>> Regards,
>>> Jeroen

---

From: Eric Burger <[email-masked]>
Date: Fri, 13 Nov 2009 07:21:36 +0900

How about, "We have been working on this for two years."  We are  
getting beyond perfection.  Look, if you do not want a standard,  
interoperable version of INFO, let us just say so and kill it off now.

On Nov 12, 2009, at 9:56 PM, Jeroen van Bemmel wrote:

> The point would be to standardize the tag name that is used. This  
> will enable a UA to announce the Info packages it supports in  
> REGISTER, and enables routing based on that information.
> I don't see why it would hurt to add this item to the draft, seems  
> overkill to write a separate RFC just for this
>
> Regards,
> Jeroen
>
>
>
>> That of course is outside the scope of draft-ietf-sipcore-info- 
>> event, but it is a reason why we don't need to put Recv-Info into  
>> the REGISTER method.
>> regards
>>
>> Keith
>>
>>
>>> From: [email-masked] [mailto:[email-masked]]  
>>> On Behalf Of Paul Kyzivat

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 13 Nov 2009 00:23:19 +0100

We should not add this new functionality following WGLC. Let's just finish what we have.

John 

> [mailto:[email-masked]] On Behalf Of Jeroen van Bemmel
> Sent: 12 November 2009 12:56
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> The point would be to standardize the tag name that is used. 
> This will enable a UA to announce the Info packages it 
> supports in REGISTER, and enables routing based on that information.
> The use case for this is the same as for event packages, it's 
> mostly for sake of completeness / consistency
> 
> I don't see why it would hurt to add this item to the draft, 
> seems overkill to write a separate RFC just for this
> 
> Regards,
> Jeroen
> 
> 
> 
> > That of course is outside the scope of 
> draft-ietf-sipcore-info-event, but it is a reason why we 
> don't need to put Recv-Info into the REGISTER method. 
> >
> > regards
> >
> > Keith
> >
> >

---

From: George Foti <[email-masked]>
Date: Thu, 12 Nov 2009 18:59:38 -0500

Well said.
We need this out NOW. No value added anymore with all this tinkering

Thanks
George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Thursday, November 12, 2009 5:22 PM
To: Jeroen van Bemmel
Cc: SIPCORE
Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event

How about, "We have been working on this for two years."  We are getting beyond perfection.  Look, if you do not want a standard, interoperable version of INFO, let us just say so and kill it off now.

On Nov 12, 2009, at 9:56 PM, Jeroen van Bemmel wrote:

> The point would be to standardize the tag name that is used. This will 
> enable a UA to announce the Info packages it supports in REGISTER, and 
> enables routing based on that information.
>> event, but it is a reason why we don't need to put Recv-Info into the 
>> REGISTER method.
>> regards
>>
>> Keith
>>
>>
>>> Behalf Of Paul Kyzivat

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 13 Nov 2009 08:15:15 +0100

To add to this, there could well be many solutions that use an info-package as only part of the solution. We would want the feature tag on the whole solution, not just on the info-package.

Therefore I don't see much point in having a standardised format of media feature tags.

regards

Keith

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Thursday, November 12, 2009 11:23 PM
> To: Jeroen van Bemmel; DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: RE: [sipcore] Caller prefs / callee caps for INFO Event
> 
> > This will enable a UA to announce the Info packages it supports in 
> > The use case for this is the same as for event packages, 
> it's mostly 
> > for sake of completeness / consistency
> > 
> potential UAS

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 13 Nov 2009 16:26:09 +0100

Hi, 

>To add to this, there could well be many solutions that use an
info-package as only part of the solution. We would want 
>the feature tag on the whole solution, not just on the info-package.

A service identifier, you mean? ;)

>Therefore I don't see much point in having a standardised format of
media feature tags.

One does not preclude the other. 

We have standardized feature tags which can be used to indicate
individual SIP methods, individual SIP exensions etc, so I see no reason
why we couldn't have to possibility to indicate individual Info
Packages.

And, if a specific application requires an Info Package, the feature tag
could identify the who application. 

Regards,

Christer