Re: [sipcore] Draft new version:draft-holmberg-sipcore-proxy-feature

[Paul Kyzivat <[e-mail]>]

On 1/27/2011 10:35 AM, Andrew Allen wrote:
> Paul,
>
> I expressed already that I think that solving this problem is also
> useful for non IMS environments such as IP PBXs in enterprises. More
> generally it could be useful in an internet environment whenever a SIP
> proxy wishes to advertise its support for some feature or capability.

I still think there *might* be something of general interest and value 
here.

When I look at it as an abstraction, it seems like a plausible one, and 
I like going for general capabilities rather than very specialized ones.

BUT, we have often gotten ourselves caught up in problems from 
over-generality. It is really good to have some important use cases. And 
having ones that many people can relate to is especially helpful.

I have a suspicion that there are use cases that much of the community 
can understand and relate to. They just haven't been discovered yet.

> I also would like to point out that some of the features developed in
> SIP over the past decade that were initially seen as IMS only or IMS
> requirements initiated features have later been seen to be useful to the
> wider community and included as part of the solutions for other later
> SIP work and made it into the Hitchikers guide. Some examples include:
>
> P-Asserted-Identity header field,
> UPDATE method,
> Path header field,
> Registration Events Package

I'm not sure that UPDATE is really form IMS. (It was called something 
else before UPDATE, but that is *way* back.) And IIRC the registration 
event package had broader support than IMS right from the beginning. But 
I take your point.

> I also would like to indicate that I am willing to contribute and review
> this work if it is adopted.

Thanks for that.

	Thanks,
	Paul

> Andrew
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Paul Kyzivat
> Sent: Thursday, January 27, 2011 8:08 AM
> To: Christer Holmberg
> Cc: [e-mail]
> Subject: Re: [sipcore] Draft new
> version:draft-holmberg-sipcore-proxy-feature
>
> Christer,
>
> The reason for including something for non-IMS usage is to motivate
> those not involved in IMS to be interested in the work. I guess that a
> sufficient mass of IMS participants would work, but its harder to get
> consensus without some of the others.
>
> 	Thanks,
> 	Paul
>
> On 1/27/2011 8:55 AM, Christer Holmberg wrote:
>>
>> Hi,
>>
>> Eventhough I would be happy to see usage outside of IMS for the
> mechanism, I don't see why 3GPP people should have to try to invent such
> use-cases "by force".
>>
>> I think there could be usages for SIP-PBXs, but I don't have any
> specific requirement/use-case to put on the table.
>>
>> Regarding the WG and IESG, we have specified mechanisms for 3GPP
> before, e.g based on RFC 4083, and my understanding is that there is
> some kind of agreement between 3GPP and IETF. I do realize that we are
> not talking about a P- header in this case, but that should not change
> the fundamental agreement.
>>
>> But, if you now are saying that, unless there is a non-IMS use-case,
> IETF (or, at least SIPCORE) is no more going to accept doing any work
> for 3GPP, I really think 3GPP should be informed about that.
>>
>> BTW, there is an *I* in IMS also :)
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>> -----Original Message-----
>>> From: Adam Roach [mailto:[e-mail]]
>>> Sent: 25. tammikuuta 2011 21:24
>>> To: Christer Holmberg
>>> Cc: Paul Kyzivat; [e-mail]
>>> Subject: Re: [sipcore] Draft new version:
>>> draft-holmberg-sipcore-proxy-feature
>>>
>>> [as individual]
>>>
>>> On 1/25/11 10:33, Jan 25, Christer Holmberg wrote:
>>>> I'll try to put something together.
>>>> But, just for my understanding: what happens if there are
>>> no non-IMS use cases?
>>>
>>> Then we need to try to figure out whether the inapplicability
>>> of the problem is due to the fact that it is being stated in
>>> overly-narrow terms (i.e., is there a more general problem
>>> here that does have applicability to the Internet?), or
>>> whether it is due to the fact that it only arises because of
>>> a specific architecture.
>>>
>>> If it's the first case, we'll probably need to generalize the
>>> problem to include the Internet (you know, the "I" in
>>> "IETF"). Then, you'll have a much easier time getting the WG
>>> to adopt it and the IESG to approve it.
>>>
>>> If the problem only exists because of certain walled-garden
>>> architectures, then things get trickier -- both in the WG and
>>> in the IESG.
>>>
>>> /a
>>>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>