[SIPForum-techwg] FW: Conference Call Confirmation Feb 24 10 AM

[Francois Audet]

The first statement is just saying that IF SIPS is used,
then it must be as per draft-ietf-sip-sips. This is a valid
and useful requirement, as otherwise, people may want to 
use SIPS as per RFC 3261, which we all know had lots of
problems.

I do agree that we don't want to mandate SIPS in this spec.

My take is that we should keep the original statement, but we
should also add some warning describing that when you support SIPS,
it means that if the call can not be completed using TLS on each
and every hop on the path, the call will fail (by design). So, before
using SIPS, you have to make sure that is really the behavior you want. 
I believe that there is very few cases initially where that would be
the desired behavior.


> -----Original Message-----
> From: techwg-bounces at sipforum.org 
> [mailto:techwg-bounces at sipforum.org] On Behalf Of Cullen Jennings
> Sent: Monday, February 23, 2009 15:27
> To: Elwell, John
> Cc: techwg at sipforum.org
> Subject: Re: [SIPForum-techwg] FW: Conference Call 
> Confirmation Feb 24 10 AM
> 
> 
> On Feb 23, 2009, at 2:56 PM, Elwell, John wrote:
> 
> > 3. SIPS. There is a normative statement in 6.2: "If SIPS URIs are 
> > used, usage MUST be as specified in [draft-ietf-sip-sips]". This is 
> > the only normative statement. , I find it not very helpful for 
> > interoperability. It does not state whether a SIP-PBX or an SP-SSE 
> > MUST or MAY support SIPS. In fact, looking at the rest of the 
> > document, I find SIPS mentioned only in 10.1.5 (PAI for incoming
> > calls) and nowhere else. For example, an enterprise public identity 
> > cannot be a SIPS URI. I think we agreed at an early stage not to 
> > mandate SIPS, but I think we need further discussion on the 
> > implications (e.g., an entity not supporting SIPS but 
> receiving a SIPS 
> > URI in From, PAI, Request-URI, To etc. )
> 
> I don't think that mandating support for SIPS solves many 
> real world problem so unless someone has a good reason why to 
> mandate it, I'd rather not.
> 
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:  
> http://sipforum.org/mailman/listinfo/techwg
>