Subject: Re: [Sipping] WGLC: draft-ietf-sipping-dialogusage-03.txt

From: Robert Sparks <[email-masked]>
Date: Sat, 21 Oct 2006 12:58:32 -0500

On Sep 15, 2006, at 5:37 PM, Paul Kyzivat wrote:

>
>
> Francois Audet wrote:
>> Thanks Paul. I guess I agree with pretty much everything you wrote in
>> there.
>> Except for the very last sentence:
>> 	The cases that are called out as horribly wrong really are. I
>> agree with the recommended 	treatments in that case. Almost all of  
>> those cases seem to not be as horribly wrong as stated.
>> For example:
>> 416: I send a re-invite with sips (on a dialog that was  
>> established with
>> sip). With the current
>>      wording, this would kill the "dialog and all of it's usage".  
>> I do
>> not think that this is
>>      warranted at all. To me, it should stay in the previous state
>> (i.e., sip).
>
> OK, I have to agree with you on that one.

I don't agree.

(Sorry for the long delay - I was going to just change it until I got  
into the text and looked at it closely).

The request URI on a mid-dialog request is not something an endpoint  
gets to pull out of the air,
sending what it wants on a whim. It's established by the contents of  
successful dialog creating or
dialog-refreshing requests. Essentially, what appears there is  
exactly what one side or the other
put into its contact.

The only way you'll get a 416 is if an endpoint is broken enough to  
say "send me foo:" and then say
"I don't support foo:", or if a proxy is broken enough to not forward  
a request with a scheme in the RURI
it doesn't understand even though there are Route header field values  
present, the topmost being one
that _it put there_.

The scenario you describe above is not a legal scenario to attempt -  
Route sets are immutable - once you've
set up a bunch of sip: hops through proxies, you're stuck with them  
until you tear down the dialog.

RjS

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 22 Oct 2006 13:00:25 -0500

I still don't agree...

Seems to me that upgrading from sip to sips IS something that
an endpoint does on a whim. There is no "send me sips" involved
in this case.

Say I establish a session with you, I should be able to
re-INVITE or UPDATE with sips, no? 

Furthermore, the 416 may come from either the other end, or
a proxy in the middle. Even if the other end did request a
re-INVITE/UPDATE mid-dialog to sips instead of SIP, there is 
a very real possibility that a proxy in the middle doesn't
support sips (even if it is supposed to be mandatory, reality is
that the vast majority of proxies do not support sips).

In either case, terminating the dialog seems like a disastrous
idea, at least for sips.

Even if we considered other schemes than sips, terminating the dialog
seems harsh an unusual punishment to me. The logic of "this is such 
a bizarre error that it must be so horrible that I should clear the
dialog" seems like a bad idea to me. 

Can you explain why not just considering it an error affecting only
that transaction is not a better alternative? Seems to me it will result
in a lot less unhappy customers.

I really think "when in doubt, just fail the transaction" is a much
better
model than "when in doubt, fail the whole dialog". Failing the dialog
should
be reserved to cases where it is crystal clear that keeping the existing
dialog is a problem.

And finally, I will reiterate my main point from my original email: the
set
of rules in this document is way too complicated for a simple 
endpoint to support. I understand where you are coming from, but to
me, it is a sign that we have unrealistic expectations.

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]] 
> Sent: Saturday, October 21, 2006 10:59 AM
> To: Paul Kyzivat
> Cc: Audet, Francois (SC100:3055); [email-masked]; 
> [email-masked]; Barnes, Mary (RICH2:AR00); 
> [email-masked]
> Subject: Re: [Sipping] WGLC: draft-ietf-sipping-dialogusage-03.txt
> 
> 
> established 
> >> with sip). With the current
> (Sorry for the long delay - I was going to just change it 
> until I got into the text and looked at it closely).
> 
> The request URI on a mid-dialog request is not something an 
> endpoint gets to pull out of the air, sending what it wants 
> on a whim. It's established by the contents of successful 
> dialog creating or dialog-refreshing requests. Essentially, 
> what appears there is exactly what one side or the other put 
> into its contact.
> 
> The only way you'll get a 416 is if an endpoint is broken 
> enough to say "send me foo:" and then say "I don't support 
> foo:", or if a proxy is broken enough to not forward a 
> request with a scheme in the RURI it doesn't understand even 
> though there are Route header field values present, the 
> topmost being one that _it put there_.
> 
> The scenario you describe above is not a legal scenario to 
> attempt - Route sets are immutable - once you've set up a 
> bunch of sip: hops through proxies, you're stuck with them

---

From: Robert Sparks <[email-masked]>
Date: Sun, 22 Oct 2006 13:21:21 -0500

> an endpoint does on a whim. There is no "send me sips" involved
Go re-read what's required of mid-dialog requests. The route-set
and remote targets are set. You may not upgrade the way you are  
describing.

> re-INVITE or UPDATE with sips, no?
If you started with sip: then no, you cannot. Think about this for a  
minute.
If a proxy recorded with a sip: URI, that hop going to be processed  
as sip:
for the rest of the dialog's existence. YOU CAN NOT CHANGE the route- 
set mid-dialog.

>
> Furthermore, the 416 may come from either the other end
In which case the endpoint that issued it is broken because the URI  
it receives
HAS TO BE the URI it signaled as its local target.
> , or
> a proxy in the middle.
In which case the proxy is broken - it's routing decisions at this  
point are based
on the topmost Route header. It should not care about the scheme in  
the RURI.

> Even if the other end did request a
The scenario you describe is not legal to attempt. To get this response,
someone is violating protocol to the point that the dialog state is  
completely damaged.

> dialog" seems like a bad idea to me.
This should seem less bizarre to you after you reread how mid-dialog  
requests have to be formed.

> be reserved to cases where it is crystal clear that keeping the  
That's the metric we used when we built these in the first place. The  
case
you are hanging on really is so broken that the dialog is gone.

> me, it is a sign that we have unrealistic expectations.

Its a far better world than they have without this document.

But you appear to have missed some of the list and in-meeting  
conversations about this document.
It's informational. It will inform documents that make normative  
changes.  This document has no rules -
it seeks to understand and capture consensus around what we believe  
things really should do. The
implementation base will benefit from having it available (I had  
several implementors at the most recent
SIPit tell me how much it helped them get this stuff straight), but  
we have a BUNCH more normative work
to do in SIP (as discussed in Montreal, and as I plan to discuss in  
San Diego)

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 22 Oct 2006 20:15:42 -0500

> Sent: Sunday, October 22, 2006 11:21 AM
> To: Audet, Francois (SC100:3055)
> Cc: Paul Kyzivat; [email-masked]; [email-masked]; Barnes, 
> Mary (RICH2:AR00); [email-masked]
> Go re-read what's required of mid-dialog requests. The 
> route-set and remote targets are set. You may not upgrade the 
> way you are describing.

Hi again,

I'm talking about a target refresh, not a changing the route set.

Couldn't what I describe happen if I send you an INVITE to sip:sparks
and then
you accept it with 200 OK with Contact sips:sparks? Then I would
re-INVITE
with sips (and maybe my proxy then rejects it with 416)?

In anycase, I'm probably missing something in this particular
example. I'll stop now.  :^)

See below.

> conversations about this document.

Well, yes it is quite possible that I missed lots of discussion on this.
It's also very likely that I'm missing some subtleties...

> to do in SIP (as discussed in Montreal, and as I plan to discuss in  

Outch...

Assuming that you are right (which is most probably the case), I'd much
rather
have Section 5 of your draft NORMATIVE than informational. It seems to
me that 
it does define lots of rules about how to process different responses.

As much as my personal belief is that we are too harsh in the way
responses are
treated in section 5, I don't think we would be providing a great
service to the 
developper community if we are ambiguous here. We should really make
Section 5 
normative if the procedures it describes reflect the consensus of
sipping.

Cheers.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Oct 2006 10:43:16 -0400

A lot of exchanges went on here since last I looked.

I think you may be talking past one another. In the case Francois 
originally called up (switching from sip to sips mid-dialog), I now 
think that Francois was talking about the sender doing a target refresh 
by changing his contact from sip to sips, while I think Robert is 
assuming that the sender is upgrading the contact of the target from sip 
to sips in the request-URI of the request being sent.

If the sender just does a target refresh from sip to sips, and the 
recipient doesn't support sips, then what response is it supposed to 
send? If 416 is a valid response in this case, then I think this only 
fails the transaction. But this doesn't seem to be a proper use for the 
416 response. (I don't know what error is appropriate if contact in a 
target refresh is of an unsupported type.)

If the sender preemptively changes the scheme from sip to sips in the 
contact for the other end, that shows a more serious problem. That 
contact is not part of the route set, and it can be changed. But it must 
be changed by a target refresh request from the other end, not by this 
end. Because that contact address is part of dialog state, it seems 
plausible that if it has changed it from sip to sips for this 
transaction, it probably plans to do so for all future transactions. So 
it *might* make sense to assume the dialog to be gone. But I could swing 
the other way on this one too.

	Paul

---

From: Robert Sparks <[email-masked]>
Date: Mon, 23 Oct 2006 10:25:19 -0500

So, I just talked this though with Adam looking for my blind-spot and  
didn't uncover one yet - still looking.

 From that conversation though - it might help to point some things  
out in close proximity.

1) When you change your contact, you're telling the other end what to  
put in its future Request-URIs in this dialog.
2) When the other end puts sips: in its request URI, it's saying - 
 >the message has to traverse the whole network as sips<- (minus the  
last hop weaseling).
3) The route-set cannot change - if proxies record-routed with sip:  
URIs, the remote UA cannot even emit the new request without
      violating protocol.

Now, for the case Paul points out below, when the sender and  
recipient are one-hop from each other (no proxies).
If the recipient gets a target refresh request to a URI it doesn't  
support, it should fail that target refresh request (with a 400). In  
that case,
the transaction is the only thing that fails. The usage and dialog  
stay the same.

Extending this to where there are proxies that Record-Routed w/ sip:,  
the recipient of that target refresh request should STILL fail the  
request with a 400, because it can tell at that time that accepting  
the request will put it into a state that will not work.

I don't know if there's any text in the spec that says don't try to  
target-refresh your way from sip to sips, but there needs to be.
(More stuff to clean up with sips when we get there)

A 416 can only happen mid-dialog if some implementation in the path  
is so broken the dialog's not going to continue to work (see
my previous messages for those cases).

All of this applies if someone puts an http: URI into the contact of  
a target refresh request as well.

RjS

On Oct 23, 2006, at 9:43 AM, Paul Kyzivat wrote:

> think that Francois was talking about the sender doing a target  
> refresh by changing his contact from sip to sips, while I think  
> Robert is assuming that the sender is upgrading the contact of the  
> target from sip to sips in the request-URI of the request being sent.
>
> recipient doesn't support sips, then what response is it supposed  
> to send? If 416 is a valid response in this case, then I think this  
> only fails the transaction. But this doesn't seem to be a proper  
> use for the 416 response. (I don't know what error is appropriate  
> if contact in a target refresh is of an unsupported type.)
>
> If the sender preemptively changes the scheme from sip to sips in  
> the contact for the other end, that shows a more serious problem.  
> That contact is not part of the route set, and it can be changed.  
> But it must be changed by a target refresh request from the other  
> end, not by this end. Because that contact address is part of  
> dialog state, it seems plausible that if it has changed it from sip  
> to sips for this transaction, it probably plans to do so for all  
> future transactions. So it *might* make sense to assume the dialog  
> to be gone. But I could swing the other way on this one too.
>
> 	Paul
>
> Francois Audet wrote:
>>> From: Robert Sparks [mailto:[email-masked]] Sent: Sunday,  
>>> October 22, 2006 11:21 AM
>>> it seeks to understand and capture consensus around what we  
>>> believe  things really should do. The
>>> SIPit tell me how much it helped them get this stuff straight),  
>>> but  we have a BUNCH more normative work
>>> to do in SIP (as discussed in Montreal, and as I plan to discuss  
>>> in  San Diego)
>> Outch...
>> me that it does define lots of rules about how to process  
>> different responses.
>> service to the developper community if we are ambiguous here. We  
>> should really make
>> Section 5 normative if the procedures it describes reflect the  
>> consensus of
>> sipping.
>> Cheers.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Oct 2006 11:32:39 -0400

Robert,

OK. I think I am with you now. Still not sure what Francois intended.

	Paul

Robert Sparks wrote:
>  From that conversation though - it might help to point some things out 
> in close proximity.
> 
> 2) When the other end puts sips: in its request URI, it's saying ->the 
> message has to traverse the whole network as sips<- (minus the last hop 
> weaseling).
> Now, for the case Paul points out below, when the sender and recipient 
> are one-hop from each other (no proxies).
> the transaction is the only thing that fails. The usage and dialog stay 
> the same.
> 
> request with a 400, because it can tell at that time that accepting the 
> request will put it into a state that will not work.
> 
> A 416 can only happen mid-dialog if some implementation in the path is 
> so broken the dialog's not going to continue to work (see
> All of this applies if someone puts an http: URI into the contact of a 
> target refresh request as well.
> 
> RjS
> 
> 
>> refresh by changing his contact from sip to sips, while I think Robert 
>> is assuming that the sender is upgrading the contact of the target 
>> from sip to sips in the request-URI of the request being sent.
>>
>> fails the transaction. But this doesn't seem to be a proper use for 
>> the 416 response. (I don't know what error is appropriate if contact 
>> in a target refresh is of an unsupported type.)
>>
>> contact is not part of the route set, and it can be changed. But it 
>> must be changed by a target refresh request from the other end, not by 
>> this end. Because that contact address is part of dialog state, it 
>> seems plausible that if it has changed it from sip to sips for this 
>> transaction, it probably plans to do so for all future transactions. 
>> So it *might* make sense to assume the dialog to be gone. But I could 
>> swing the other way on this one too.
>>
>>     Paul
>>
>> Francois Audet wrote:
>>>> Cc: Paul Kyzivat; [email-masked]; [email-masked]; Barnes, Mary 
>>>> (RICH2:AR00); [email-masked]
>>>> Go re-read what's required of mid-dialog requests. The route-set and 
>>>> remote targets are set. You may not upgrade the way you are describing.
>>> Hi again,
>>> me that it does define lots of rules about how to process different 
>>> responses.

---

From: Adam Roach <[email-masked]>
Date: Mon, 23 Oct 2006 10:33:42 -0500

I think I might see a few different points of confusion here. I'll see 
if I can't clarify things a bit to the best of my understanding:

   1. I'm a user agent. If I send a target refresh request in a dialog,
      I can change MY OWN CONTACT (the near end of the route set), but
      NOT the contact of the user agent I'm talking to (the far end of
      the route set). The request URI that I use in a dialog must be the
      URI that I got from the remote user agent. If I change it, I have
      done something vigorously wrong, and the dialog should be blown
      away. (The far end may well be storing state information in that
      URI; if I munge it, the show cannot go on).

   2. SIPS is a guarantee that the entire chain of proxies is using TLS.
      Either EVERY connection between me and the far end is SIPS, or
      NONE are.

   3. Once a dialog is established, there is nothing that ANY network
      element (user agent or proxy) can do to change the route set other
      than the URIs at the very end.

   4. There are several related normative statements that are logical
      corollaries to these properties; for example: RFC 3261, Section
      8.1.8: "If the Request-URI or top Route header field value
      contains a SIPS URI, the Contact header field MUST contain a SIPS
      URI as well."

   5. Because SIPS at one end implies SIPS in the middle and SIPS at the
      other end:

          * An attempt to change my own contact URI mid-dialog without
            changing the far end URI would violate #2 and #4 above.

          * An attempt to change my own contact URI mid-dialog *and* the
            far end URI (but not the path in the middle) would violate
            #1 and #2 above.

          * An attempt to change my own contact URI mid-dialog *and* the
            far end URI *and* all the URIs on the path would violate #1,
            #3, and #4 above.

Bottom line: there's just no way a dialog can be upgraded (or 
downgraded, for that matter) after it has been established.

/a

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 23 Oct 2006 10:34:13 -0500

> I don't know if there's any text in the spec that says don't 
> try to target-refresh your way from sip to sips, but there 
> needs to be.

I don't beleive there is any text of that nature. Maybe it should
be in my sips-guidelines draft.

I know RFC 3261 implies that it is legal to send a request
to a sip Request-URI, with a sips Contact.

> A 416 can only happen mid-dialog if some implementation in 
> the path is so broken the dialog's not going to continue to 
> work (see my previous messages for those cases).
> 
> All of this applies if someone puts an http: URI into the 
> contact of a target refresh request as well.

Let's try to have a face-to-face in San Diego.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Oct 2006 12:30:30 -0400

Yeah, your logic seems to be right.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 23 Oct 2006 12:43:07 -0500

See below. 

> From: Adam Roach [mailto:[email-masked]] 
> Sent: Monday, October 23, 2006 8:34 AM
> To: Paul Kyzivat
> I think I might see a few different points of confusion here. 
> I'll see if I can't clarify things a bit to the best of my 
> understanding:
> 

That's the leap of faith that I'm having trouble with. Why "blow away
the
dialog" as opposed to treat it as a rejected request (and keep existing
dialog)? I don't understand what good it does, except more devices that
hang up unexpectedly.

>       Either EVERY connection between me and the far end is SIPS, or

Yes.

>       than the URIs at the very end.

Correct.

>       contains a SIPS URI, the Contact header field MUST 

Right: but it doesn't say the reverse, i.e., it seems to imply that
it is legal to have a sips Contact and a sip URI.

>             changing the far end URI would violate #2 and #4 above.

I don't think so.

I can make a request with a Request-URI of sip AND send it over TLS. It
is
possible that it will go end-to-end over TLS even without using sips. In
fact,
this is done today with and without the transport=tls parameter.

> downgraded, for that matter) after it has been established.

Examples:

                                    Proxy
INVITE sip:adam  (over TLS, or not)
Contact: sips:audet 
------------------------------------>------------------------------>

200 OK
<-----------------------------------<-------------------------------

                                        re-INVITE sips:audet (over TLS)
                                    <------------------------------

                                      416 (Proxy doesn't support SIPS)
                                    ------------------------------->

Also,

                                    Proxy
INVITE sip:adam  (over TLS, or not)
------------------------------------>------------------------------>

200 OK
Contact: sips:adam
<-----------------------------------<-------------------------------

re-INVITE sips:adam (over TLS)
------------------------------------>

416 (proxy doesn't support sips)
<------------------------------------

In both cases it seems to me that tearing down the dialog is unwaranted.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 23 Oct 2006 13:20:33 -0500

inline (some stripping of content for brevity)

> dialog)? I don't understand what good it does, except more devices  

Turn the question on its head. In the case of the particular error  
(416) you
are worried about, how can the dialog go forward? Because of the rules
around route sets, there is no "fail back to sip". If you've gone so  
far that
the RURI has changed to something that gets rejected with a 416,  
there is no
coming back. (Be sure to read my note from earlier today talking  
about how the
request that might have eventually caused that RURI to change should  
have been
rejected in the first place).

Your concern about devices hanging up unexpectedly in general is  
good, but in this case,
they've already done things to themselves (violating the protocol) so  
that they won't be able
to do anything else.

> it is legal to have a sips Contact and a sip URI.

I don't see that implication.

> this is done today with and without the transport=tls parameter.

I don't see your point. That's all fine and good, but it's still not  
sips:.
I can see that we could add new constraints to the protocol to make  
it _possible_ to
make that transition if the preconditions you describe are present,  
but right now, that's
not what the spec allows.

> INVITE sip:adam  (over TLS, or not)
This is broken, but I'll let it slide for the purpose of the example
So, show me the recover path you're proposing. If the dialog doesn't  
go away,
what would you have the thing on the right send next?

> INVITE sip:adam  (over TLS, or not)
So, this again is broken in the same way as your first example.
I know there's intent in the spec (I didn't find the explicit  
prevention on a fast skim) to disallow this.
Once again, it gets into what sips: means.

> re-INVITE sips:adam (over TLS)
Show me a recovery path that doesn't violate the spec (some more).

RjS

---

From: Dean Willis <[email-masked]>
Date: Mon, 23 Oct 2006 23:55:16 -0500

>      Either EVERY connection between me and the far end is SIPS, or

This is simply incorrect (as per RFC 3261), and insisting on it going  
forward will only preclude the use of sips: in environments offering  
equally strong hop-by-hop protections such as SIP/UDP over IPSEC,  
which could of course be keyed using the same certs and the same  
cipher-suite as TLS might use. And if you've got the same crypto, do  
you really care which encapsulation is used? The "s" at the end of  
"sips" means "secured", not "specified by RFC 2246".

To misquote your favorite movie line: "It is conceivable that this  
word does not mean what you think it means".

Of course, this is all the subject of Francois' draft, not dialogusage.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Tue, 24 Oct 2006 09:28:03 -0500

Dean Willis wrote:
> equally strong hop-by-hop protections such as SIP/UDP over IPSEC...

Yes, mea culpa. I misspoke on a point that is only very barely 
tangentially related to the topic at hand. Thanks for the correction -- 
but did you _actually_ miss the larger point, or simply choose to find 
the inconsequential gaffe?

/a

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 24 Oct 2006 13:19:59 -0500

> "sips" means "secured", not "specified by RFC 2246".

Actually, you are more incorrect. SIPS specifically means TLS for all 
the hops up until you reach the target domain. In is only inside the
target domain that alternative to TLS can be used. That's the infamous
"last hop exception" rule.

See RFC 3261 (see section 26.2.2):

   When used as the Request-URI of a
   request, the SIPS scheme signifies that each hop over which the
   request is forwarded, until the request reaches the SIP entity
   responsible for the domain portion of the Request-URI, must be
   secured with TLS; once it reaches the domain in question it is
   handled in accordance with local security and routing policy, quite
   possibly using TLS for any last hop to a UAS.

This is discussed at length in draft-audet-sip-sips-guidelines-04. SIPS
actually DOES mean TLS for all but the last hop. If you want to use
something
else than TLS, then you can't use sips. It donsn't mean it's not
secured: it
just means it's not TLS.

---

From: Dean Willis <[email-masked]>
Date: Tue, 24 Oct 2006 13:44:22 -0500

On Oct 24, 2006, at 9:28 AM, Adam Roach wrote:

>> This is simply incorrect (as per RFC 3261), and insisting on it  
>> going forward will only preclude the use of sips: in environments  
>> offering equally strong hop-by-hop protections such as SIP/UDP  
>> over IPSEC...
>
> tangentially related to the topic at hand. Thanks for the  
> correction -- but did you _actually_ miss the larger point, or  
> simply choose to find the inconsequential gaffe?
>

I chose to respond to the inconsequential gaffe because I agreed  
completely with everything else you said (and of course, because it's  
a sore point). My apologies, I should have included that endorsement  
in the original response :-/.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 24 Oct 2006 13:54:34 -0500

Ok, I'm capitulating...

While I don't agree with the idea of having certain response code
used mid-dialog causing dialog to be terminated (and certainly not for
things
like 416), I don't see anybody on the list that share my concerns. So
I'll back
down.

Therefore, if we must have special processing for specific response code

(creating dialog termination), let's make sure we are clear.

I see the following steps as necessary:

- The treatment of response codes as per section 5 of dialogusage should
not
  be "informational" as is the case with the current draft. I believe
that the
  draft should be Standards Track. If we  are serious about this, we can
not 
  weasel our way through it with an Informational RFC. (The other parts
of 
  the draft may be merely informational, but that section 5 is not).

- There are multiple statements in RFC 3261 that lets the reader believe
that
  using a SIPS contact and a SIP Request-URI in the same message is
legal. This
  would result in the problem I was describing (using a SIPS contact in
a response
  to a request with a SIP Request-URI would also result in the same
problem). There
  are also some statement in there thay may lead people to believe that
they can
  "upgrade" from sip to sips mid-dialog. If would suggest that we
clarify in 
  the sips-guidelines draft that in fact, doing this is in fact not
allowed. 
  People need to understand that you can't upgrade from sip to sips by
mucking
  around with the Contacts or the Request-URI mid-dialog.

Hopefully we can put this thread to rest...

> From: Robert Sparks [mailto:[email-masked]] 
> Sent: Monday, October 23, 2006 11:21 AM
> Cc: Adam Roach; Paul Kyzivat; [email-masked]; 
> inline (some stripping of content for brevity) On Oct 23, 
> 2006, at 12:43 PM, Francois Audet wrote:
> 
> > See below.
> >
> >>       NOT the contact of the user agent I'm talking to 
> (the far end 
> >> of
> >>       the route set). The request URI that I use in a 
> dialog must be 
> >> the
> > the dialog" as opposed to treat it as a rejected request (and keep 
> > existing dialog)? I don't understand what good it does, except more 
> > devices that hang up unexpectedly.
> 
> are worried about, how can the dialog go forward? Because of 
> the rules around route sets, there is no "fail back to sip". 
> If you've gone so far that the RURI has changed to something 
> that gets rejected with a 416, there is no coming back. (Be 
> sure to read my note from earlier today talking about how the 
> request that might have eventually caused that RURI to change 
> should have been rejected in the first place).
> 
> Your concern about devices hanging up unexpectedly in general 
> is good, but in this case, they've already done things to 
> themselves (violating the protocol) so that they won't be 
> able to do anything else.
> 
> >
> >>    2. SIPS is a guarantee that the entire chain of proxies 
> is using 
> >> TLS.
> > Right: but it doesn't say the reverse, i.e., it seems to 
> imply that it 
> > is legal to have a sips Contact and a sip URI.
> 
> >>    5. Because SIPS at one end implies SIPS in the middle 
> and SIPS at 
> >> the
> >>       other end:
> >>
> > I can make a request with a Request-URI of sip AND send it 
> over TLS. 
> > It is possible that it will go end-to-end over TLS even 
> without using 
> > sips. In fact, this is done today with and without the 
> transport=tls 
> > parameter.
> 
> I don't see your point. That's all fine and good, but it's 
> still not sips:.
> I can see that we could add new constraints to the protocol 
> to make it _possible_ to make that transition if the 
> preconditions you describe are present, but right now, that's 
> >>           * An attempt to change my own contact URI 
> mid-dialog *and* 
> >> the
> >>           * An attempt to change my own contact URI 
> mid-dialog *and* 
> >> the
> >>             far end URI *and* all the URIs on the path 
> would violate 
> >> #1,
> >>             #3, and #4 above.
> >>
> >                                     Proxy INVITE sip:adam  
> (over TLS, 
> > or not)
> So, show me the recover path you're proposing. If the dialog 
> doesn't go away, what would you have the thing on the right send next?
> 
> >
> > Also,
> >
> >                                     Proxy

---

From: Robert Sparks <[email-masked]>
Date: Tue, 24 Oct 2006 14:03:00 -0500

I totally agree with your second step.

I agree with the spirit of the first - normative changes are  
absolutely necessary, but as we've discussed
on list and at previous meetings before, thats one or more other  
documents that this document will inform.
It may be that we can crack that nut with one document, but I'm  
betting it gets to be a pilot for the update
process the SIP chairs and ADs have been discussing.

RjS

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Oct 2006 15:05:57 -0400

> around with the Contacts or the Request-URI mid-dialog.

There *is* a way, just not *this* way. A legal way would be to send an 
out-of-dialog INVITE/Replaces referencing the existing dialog.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 24 Oct 2006 16:02:50 -0500

> > they can "upgrade" from sip to sips mid-dialog. If would 
> suggest that 
> > we clarify in the sips-guidelines draft that in fact, doing 
> this is in 
> > fact not allowed.
> > mucking around with the Contacts or the Request-URI mid-dialog.
> 
> There *is* a way, just not *this* way. A legal way would be 
> to send an out-of-dialog INVITE/Replaces referencing the 
> existing dialog.

Agreed 100%.

In fact, I had started to write exactly this in an email that I decided
not to 
send because I felt I had fueled the fire on this thread enough
already...

I would say that the proper thing to do would be to describe this in the

sips-guidelines.