Re: [martini] draft-roach-martini-up-00

["Elwell, John" <[e-mail]>]

 

> -----Original Message-----
> From: Adam Roach [mailto:[e-mail]] 
> Sent: 07 January 2010 14:48
> To: Elwell, John
> Cc: [e-mail]
> Subject: Re: [martini] draft-roach-martini-up-00
> 
> John:
> 
> The problem with the approach you espouse below is that it is a point 
> solution for a very specific architecture. The general approach that 
> we've taken with SIP in the past is to standardize general tools that 
> can be combined to accommodate varying services and varying 
> architectures.
> 
> This is, for example, why we selected draft-ietf-sip-refer over 
> draft-dean-handoff 
> (http://tools.ietf.org/id/draft-dean-handoff-00.txt) 
> -- we recognized that defining a service-enabling tool was infinitely 
> more flexible than defining a service.
> 
> In terms of "perceived benefits," I'll point out that the PUBLISH 
> proposal eliminates the vast majority of the problems 
> described in the 
> martini-mixing-problems draft not by solving them, but by 
> sidestepping 
> them altogether.
> 
> Do I care about that? Not very much. It's not why I'm here.
> 
> What's important to me is that my proposal also doesn't materially 
> change the semantics of a core SIP method -- because such changes can 
> result in potential policy violations, like the one I describe in my 
> message below. My horse in this race is "don't screw up the core SIP 
> protocol." I understand that you have a very specific problem you're 
> trying to solve, and that the least-effort approach would be 
> to define a 
> laser-focused point solution that addresses precisely one 
> architectural 
> model, with little regard for how it interacts with other 
> architectures 
> or other parts of the protocol.
> 
> I'm here to make sure there's no collateral damage.
[JRE] I understand that, but it is not clear to me why we can't come up with a REGISTER-based proposal that is not fundamentally broken. I believe the PUBLISH proposal is even more broken, if intermediaries have to be aware of the specific event package and take special action to do with Path, for example.

John