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

[Francois Audet]

That would be the other alternative: no mention whatsoever. I'm ok with that too.

It could be a job for 2.0. 

> -----Original Message-----
> From: Hadriel Kaplan [mailto:HKaplan at acmepacket.com] 
> Sent: Tuesday, February 24, 2009 07:06
> To: Elwell, John; Audet, Francois (SC100:3055); Cullen Jennings
> Cc: techwg at sipforum.org
> Subject: RE: [SIPForum-techwg] FW: Conference Call 
> Confirmation Feb 24 10 AM
> 
> 
> Actually, why don't we get realistic/pragmatic and actually 
> not mention SIPS whatsoever.  It is so rare, and so confusing 
> to folks, that I don't know why we'd even want to cover it in 
> the spec.
> 
> -hadriel
> 
> > -----Original Message-----
> > From: techwg-bounces at sipforum.org 
> [mailto:techwg-bounces at sipforum.org] 
> > On Behalf Of Elwell, John
> > Sent: Tuesday, February 24, 2009 6:41 AM
> > To: Francois Audet; Cullen Jennings
> > Cc: techwg at sipforum.org
> > Subject: Re: [SIPForum-techwg] FW: Conference Call 
> Confirmation Feb 24 
> > 10 AM
> >
> > I agree with both Francois and Cullen that we should not 
> mandate SIPS, 
> > but my main point is that for all header fields where we 
> discuss URI 
> > forms (e.g, Request-URI, PAI, From, To, Route) we need to 
> specify what 
> > to do if you receive SIPS.
> >
> > John
> >
> > > -----Original Message-----
> > > From: Francois Audet [mailto:audet at nortel.com]
> > > Sent: 24 February 2009 00:53
> > > To: Cullen Jennings; Elwell, John
> > > Cc: techwg at sipforum.org
> > > Subject: RE: [SIPForum-techwg] FW: Conference Call 
> Confirmation Feb 
> > > 24 10 AM
> > >
> > > 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
> > > >
> > >
> >
> > _______________________________________________
> > techwg mailing list
> > Send mail to: techwg at sipforum.org
> > Unsubscribe or edit options at:
> > http://sipforum.org/mailman/listinfo/techwg
>