Subject: RE: [Sip] draft-audet-sip-sips-guidelines: sip and sips contacts inRegistrations

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 18 May 2006 14:44:51 -0400

Security is only one aspect of the behavior associated with SIP.  Remind
me again why this one behavior rose to the level of having a separate
URI designation?  

I think the idea of deprecating sips and addressing the behavior of this
feature like other mechanisms negotiated in SIP via headers or
parameters makes more sense.  The issue of what sip address gets
registered then is moot.

Then we could re-visit what it is we think we wanted to do wrt security
requests and validating that the request was in fact honored.

Security: header, options-tag: security  anyone???

Mike

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: Wednesday, May 17, 2006 5:16 PM
> To: IETF SIP List
> Subject: [Sip] draft-audet-sip-sips-guidelines: sip and sips 
> contacts inRegistrations
> 
> Jonathan made a proposal that Contacts in registrations be 
> automatically "upgradable/downgradable" between sip and sips. 
> 
> His exact wording:
> > I would propose that it is never
> > necessary to include separate contacts for sip and sips. If a 
> > registration is sent such that each hop was over TLS (done 
> by having 
> > the r-uri in the registration be a sips URI), then that 
> contact (and 
> > the associated secure path URI) can be used for requests 
> sent to sip 
> > or sips AOR. If a request is sent to a SIPS AOR, the proxy sets the 
> > r-uri to a sips version of the contact. If a request is 
> sent to a SIP 
> > AOR, the r-uri is a sip version of the contact.
> 
> The draft I wrote actually takes the opposite approach.
> 
> It proposes that the UA always explicitely registers sip and 
> sips contacts (in the same registration) in order to bind 
> each one to the AOR. The AOR itself however is 
> "upgradable/downgradable" the same way Jonathan is saying.
> 
> It has the advantage that a UA can then specifically request 
> to be reachable ONLY using a sips contact, ONLY using a sip 
> contact, or BOTH (and also specify q-value). It also allows 
> to explicitely say if it is reachable with UDP (again, with a 
> q-value). This could be very useful for a UA that has a 
> policy of "always TLS, never TLS, either (TLS prefered), or 
> either (non-TLS prefered). I don't think this is easily 
> achievable with Jonathan's proposal.
> 
> Other comments?
> 
> _______________________________________________
> Sip mailing list  https://www1.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://www1.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: Thu, 18 May 2006 16:00:51 -0500

> me again why this one behavior rose to the level of having a separate

Here's how I remember it: we didn't want to figure out how to use  
starttls, which means having two ports (one "secure"-- 5061, one not,  
5060), and having two ports means having two URI schemes with  
different default port numbers.

--
Dean