Subject: [Sip] WGLC for draft-ietf-sip-199-02

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 4 Nov 2008 22:20:40 +0100

(As WG chair)

This mail is to initiate a WGLC on 

http://www.ietf.org/internet-drafts/draft-ietf-sip-199-02.txt

Response Code for Indication of Terminated Dialog

Intended Status: Proposed standard

This is a two week working group last call so please send your comments
to the list and direct to the editor by the 18th November 2008. As this
date is just after the start of IETF#73, please put this high up your
reading list.

Normal rules apply - for each please indicate the type of comment you
are making to give us some idea of the sort of severity, and if possible
please indicate what sort of fix would be required, or even better,
supply revised text.

regards

Keith

_______________________________________________
Sip mailing list  https://www.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: Robert Sparks <[email-masked]>
Date: Tue, 11 Nov 2008 11:08:57 -0600

I've had several people comment that their reading list is driven  
exclusively by what appears on agendas at meetings.

This draft does not appear on any such agenda.

Its probably worth poking people repeatedly to stimulate comments if  
you want any.

That said, I am assuming that this WGLC is intended to stimulate  
discussion on the draft instead of meaning "we think this is ready to  
publish - everybody take a last look at it" kind of LC, since it still  
contains things like:

> 12.  Security Considerations
>
>    TBD

I'll send my comments in a separate message.

RjS

---

From: Robert Sparks <[email-masked]>
Date: Tue, 11 Nov 2008 13:39:22 -0600

Comments (in major, minor, nit order)

Major:
maj-1) Do we have a constituency willing to finish this work? It has a  
ways to go and the number of commenters has been pretty small. Does  
anyone know of any attempts to implement this yet?

maj-2) -02 is an improvement over -00, but the basic architectural  
intent is still not clear (as evidenced by the remaining open issue in  
section 5 - in fact I think this is the _REAL_ open issue that the  
thing in section 5 is pointing to). An implementer would probably  
benefit from a short overview section that outlined the mechanics.

maj-3) The document defines an option tag but doesn't say what it  
means if it shows up in a Require: header.

maj-4) The Security Considerations section is empty. I've pointed  
already (in my comments to -00) of at least one situation we need to  
discuss here (It said "For instance, I can spoof 199s to affect how a  
call is ultimately answered in ways that are different (from the  
endpoints visibility into what happened point-of-view) from cancels/ 
byes or even other response manipulation.) We need some focused  
discussion to uncover any other issues this new behavior is bringing  
to the system.

maj-5) (I waffled on putting this into minor, but I've made this  
comment before and it hasn't been sufficiently addressed). The  
document needs to be more explicit in explaining how it might be that  
a single 3-6xx response showing up at a proxy might cause it to send  
more than one 199. Something like http://www.nostrum.com/~rjsparks/example.png 
  perhaps.

maj-6) The document should discuss what a proxy should do if a 199  
shows up for an early dialog it's already generated its own 199 about.
(This might happen, for instance, if a 3-6xx and a 199 crossed on the  
wire or were reordered by previous elements on the way to this proxy).

maj-7) Section 7 on backwards compatibility is really confusing and  
doesn't stand up against some edge situations. In particular, it  
doesn't act right when a request comes in that's a retransmission or a  
merge. It could also be misinterpreted (a stretch, but I've seen this  
stretch) to constrain UASes to send a 481 to an ACK. I suggest we get  
together in the hall at IETF73 and collaboratively wordsmith a  
replacement for this section.

maj-8) What is the purpose of section 8? I suspect it should just be  
deleted.

maj-9) Section 9 allows a 199 to contain SDP. Why? This document  
should either forbid that practice or explicitly document why it is  
allowed.

Minor:
min-1) (I waffled on putting this into major): This entire mechanism  
is an optimization, but the word optimization is never used. This is  
(as discussed so far) ONLY an optimization and should be explicitly  
described as such (including documenting the limitations of the  
optimization).

min-2) The document uses "upstream" and "downstream" throughout its  
text. We can probably find a way to replace those terms with something  
less likely to induce confusion especially when translating to other  
languages.

min-3) The abstract shows the architectural confusion I call out in  
maj-2. Its not clear what elements use the 199 in this description.  
The most likely interpretation of the given text is just the UAC.

min-4) The last sentence of the 5th paragraph of the Introduction  
(which starts "When SIP entities upstream receive") says SIP entities  
but talk about things that only UACs can do, specifically terminating  
the session startup.

min-5) Paragraph 1 of section 4 (Client Behavior) can be read to say a  
UAC MUST always insert a Supported:199. It should start with a  
conditional clause such as "If the client wants to receive 199  
responses, then".

min-6) Item 5 in section 4.1 talks about dialogs being "inactive"  
which doesn't have meaning - I think it meant to say "the sessions  
associated with some early dialogs may be set to inactive".

min-7) Section 5 should be titled "User-Agent Server" behavior to  
avoid confusion with Proxies.

min-8) (This will be major later in the review process if it's still  
there when we get there). Section 6 uses 2119 capitalized words to  
restate requirements from other, already published and referenced,  
documents. This is a practice we should work hard to avoid. I suggest  
replacing the first two sentences with "A proxy will forward a  
received 199 response as it is required to forward all other non-100  
provisional responses by RFC 3261." Similarly, the last paragraph of  
section 7 should not use 2119 capitalized words.

min-9) The part of section 6 that talks about the proxy generating  
199s on its own would be clearer if it were structured around the  
generation of multiple 199s for a given 3-6xx with the case of only  
one 199 being generated falling out as a special case. (currently it  
documents the 1 final response makes 1 provisional response and calls  
out the multiple-199 case as an exception/extension later in the  
section).

Nit:
nit-1) "resrouces" occurs several times in section 4.1

nit-2) The document still contains [ref needed] when talking about ICE  
in section 4.1

nit-3) The Note in section 4.1 has a reference to RFC3261 ostensibly  
about SRTP. Did it mean to point to an SRTP document instead?

nit-4) "intial" appears in section 5

nit-5) Suggest replacing "triggers a 199 response" in section 10 with  
"generates a 199 response"

On Nov 11, 2008, at 11:08 AM, Robert Sparks wrote:

> discussion on the draft instead of meaning "we think this is ready  
> to publish - everybody take a last look at it" kind of LC, since it  
> still contains things like:
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 11 Nov 2008 22:18:43 -0600

> This draft does not appear on any such agenda.

see:

http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_73

---

From: Robert Sparks <[email-masked]>
Date: Wed, 12 Nov 2008 09:00:43 -0600

Great! Thanks!

(I was going off what I pulled from the IETF website on Monday when I  
commented below).

RjS

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 22 Nov 2008 01:36:20 +0100

Hi Robert, 

(I will comment the minors in a separate reply)

------

>maj-1) Do we have a constituency willing to finish this work? It has a
ways to go and the number of commenters has been 
>pretty small. Does anyone know of any attempts to implement this yet?

I am aware of plans to implement it.

------

>maj-2) -02 is an improvement over -00, but the basic architectural
intent is still not clear (as evidenced by the 
>remaining open issue in section 5 - in fact I think this is the _REAL_
open issue that the thing in section 5 is 
>pointing to). An implementer would probably benefit from a short
overview section that outlined the mechanics.

I agree that it currently is THE open issue. One proposal, based on
input from Bret (see separate thread) would be to say the following:

"A UAS must send 199 if it establishes more than one early dialog, and a
UAS may send 199 if it establishes a single dialog."

That way I don't think we need to distinguish between endpoint UASs and
B2BUAs. 

I've also mailed to other alternatives to the list, which I intended to
present at the meeting.

------

>maj-3) The document defines an option tag but doesn't say what it means
if it shows up in a Require: header.

I think we could say that it means that the UAS must support 199.
Whether it then actually sends 199 depends on whether it fulfils the UAS
criteria for sending 199 (see maj-2).

------

>maj-4) The Security Considerations section is empty. I've pointed
already (in my comments to -00) of at least one 
>situation we need to discuss here (It said "For instance, I can spoof
199s to affect how a call is ultimately answered 
>in ways that are different (from the endpoints visibility into what
happened point-of-view) from cancels/ byes or even 
>other response manipulation.) We need some focused discussion to
uncover any other issues this new behavior is bringing 
>to the system.

I will initiate a separate thread for this.

------

>maj-5) (I waffled on putting this into minor, but I've made this
comment before and it hasn't been sufficiently 
>addressed). The document needs to be more explicit in explaining how it
might be that a single 3-6xx response showing up 
>at a proxy might cause it to send more than one 199. Something like
http://www.nostrum.com/~rjsparks/example.png
>perhaps.

I will take a second look at that.

------

>maj-6) The document should discuss what a proxy should do if a 199
shows up for an early dialog it's already generated 
>its own 199 about.
wire or were reordered by previous elements on the 
>way to this proxy).

If the 199 is sent reliably I guess the proxy could forward it, in order
to the UAC to PRACK it.

If the 199 is sent unreliably I guess the proxy could discard it, or
forward it.

But, I need to think about this a little more.

-----

>maj-7) Section 7 on backwards compatibility is really confusing and
doesn't stand up against some edge situations. In 
>particular, it doesn't act right when a request comes in that's a
retransmission or a merge. It could also be 
>misinterpreted (a stretch, but I've seen this
together in the hall at IETF73 and collaboratively 
>wordsmith a replacement for this section.

I guess we never got a chance to discuss this, but I think I understand
your point. I guess I could modify the text, and simply say that a UAS
which receives a request after it has sent 199 shall act in the same way
as if it had received the request after sending the final non-2xx
response to the INVITE, as specified in RFC3216.

"If such request is received by a UA, it MUST reply to such requests
with a 481 final response."

...is replaced with:

"If such request is received by a UA, it shall act in the same way as if
it had received the request after sending the final non-2xx response to
the INVITE, as specified in RFC3261."

-----

deleted.

I took it from another draft (don't remember which) that defines a new
response code.

-----

>maj-9) Section 9 allows a 199 to contain SDP. Why? This document should
either forbid that practice or explicitly 
>document why it is allowed.

I am fine with disallowing it completely.

-----

in section 4.1
>nit-3) The Note in section 4.1 has a reference to RFC3261 ostensibly
about SRTP. Did it mean to point to an SRTP 
>document instead?

I'll do the fixes in the next version of the draft.

-----

Thank you very much for your comments!

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 22 Nov 2008 00:26:03 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christer Holmberg
>

I think that is bad mojo.  You don't want calls failing just because a b2bua or the far-end UAS doesn't support 199.  What recourse would there be for the UAC?  What would the UAC do if it got a 420 response because of it?  It would make the call again without the 199 option tag in Require, or worse it would fail the call and the user will call tech support - because nothing is going to change when they make another call attempt with that option tag in Require.  And that is basically the definition of when NOT to put something in Require, but rather in Supported.

IMHO the draft should say a UAC MUST NOT put the option tag in the Require header.  If there's some reason some UAC has to do it, they'll ignore the MUST NOT anyway.  But they should think long and hard before making that mistake, and someone who buys their product should be able to complain to them that they don't comply with the RFC.

I'm almost tempted to say we shouldn't even have an option-tag at all (the Supported lists are getting quite big), but I'm guessing we'll have interop issues without it because some UAC's will barf on receiving a 199, so the UAS needs to know if it can send it. :(

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 22 Nov 2008 13:54:56 +0100

Hi, 

>>>maj-3) The document defines an option tag but doesn't say what it
means
>>Whether it then actually sends 199 depends on whether it fulfils the 
>>UAS criteria for sending 199 (see maj-2).
>
>I think that is bad mojo.  You don't want calls failing just because a
b2bua or the far-end UAS doesn't support 199. 
>
>What recourse would there be for the UAC?  What would the UAC do if it
got a 420 response because of it?  It would make 
>the call again without the 199 option tag in Require, or worse it would
fail the call and the user will call tech 
>support - because nothing is going to change when they make another
call attempt with that option tag in Require.  And 
>that is basically the definition of when NOT to put something in
Require, but rather in Supported.

...which is a good reason to say that the UAC should not use Require:
199. But, we still need to say what it means IF it does so, and I think
that was what Robert was thinking about.

>IMHO the draft should say a UAC MUST NOT put the option tag in the
Require header.  If there's some reason some UAC has 
>to do it, they'll ignore the MUST NOT anyway.  But they should think
long and hard before making that mistake, and 
>someone who buys their product should be able to complain to them that
they don't comply with the RFC.

I don't like must-nots if it doesn't break the protocol. But, I agree we
should strongly recommend against it.

>I'm almost tempted to say we shouldn't even have an option-tag at all
(the Supported lists are getting quite big), but 
>I'm guessing we'll have interop issues without it because some UAC's
will barf on receiving a 199, so the UAS needs to 
>know if it can send it. :(

Yes. And, the solution to long Supported lists is not to stop defining
option tags, at least when there are good reasons to define them.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 22 Nov 2008 12:34:31 -0500

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Saturday, November 22, 2008 7:55 AM
>

Developers and product managers read SHOULD NOT as basically optional, and customers have a hard time forcing vendors to follow SHOULDs compared with MUSTs.  We've seen this time and time again.  The _protocol_ may not "break", but user expectations and experience "breaks", and at the end of the day that hurts all of us.  Well, it doesn't hurt me right now - it's created a market opportunity for SBCs to go and fix it; but having middleboxes fix bad implementations is not good in the long term for SIP.

IMO interoperability isn't just about _protocol_ behavior, it's the resultant user experience too.  Legitimate call attempts must succeed.  The spice must flow. ;)

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Sun, 23 Nov 2008 22:16:32 -0600

Hadriel Kaplan wrote:
>> -----Original Message----- From: Christer Holmberg
>> [mailto:[email-masked]] Sent: Saturday, November
>> 22, 2008 7:55 AM
>> 
>> I don't like must-nots if it doesn't break the protocol. But, I
>> agree we should strongly recommend against it.
> 
> Developers and product managers read SHOULD NOT as basically
> optional, and customers have a hard time forcing vendors to follow
> SHOULDs compared with MUSTs.  We've seen this time and time again.
> The _protocol_ may not "break", but user expectations and experience
> "breaks", and at the end of the day that hurts all of us.  Well, it
> doesn't hurt me right now - it's created a market opportunity for
> SBCs to go and fix it; but having middleboxes fix bad implementations
> is not good in the long term for SIP.
> 
> IMO interoperability isn't just about _protocol_ behavior, it's the
> resultant user experience too.  Legitimate call attempts must
> succeed.  The spice must flow. ;)
> 

RFC 2119 section 6 says:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

I'm not at all sure we can justify MUST NOT here. It's not required for
interop, does not cause harm to the network, and there are presumably
legit use cases (such as diagnostics) for using it in a Require.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 24 Nov 2008 00:37:03 -0500

> From: Dean Willis [mailto:[email-masked]]
> Sent: Sunday, November 23, 2008 11:17 PM
>
> I'm not at all sure we can justify MUST NOT here.

And that in a nutshell is why middleboxes end up doing interop fixing stuff.

> It's not required for
> interop, does not cause harm to the network,

There are thousands of deployed SIP networks.  Not one of them currently supports this 199 mechanism, AFAIK.  Putting it in a Require will not interoperate with any of them, and has a potential for causing harm to the service SIP is supposed to provide: session establishment.  Obviously this interoperates in the sense that the far-end will fail it, and we have to be able to add option tags in Require for some new things; but this 199 mechanism isn't in the same vein as privacy or replaces option tags which need to be put in Require sometimes to make calls work.  Honestly we should have been more careful in the past about this, so we might as well start now.

You may think this is a no-brainer, and that no one would be so dumb as to put it in a Require, but history has already proven otherwise for other option tags.  Been there, done that, have the T-shirt.  It works in the closed environment they deploy in at first, and then breaks when the environment grows or is no longer closed.  I can already envision what will happen with 199: some other SDO will decide this 199 thing is a good idea and makes the user experience better, so it should be required in release X of their specs.

> and there are presumably

Then say MUST NOT except for diagnostic purposes.

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 24 Nov 2008 07:24:37 +0100

So, YOUR developers are the ones who are stupid? ;) 

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 22. marraskuuta 2008 19:35
> To: Christer Holmberg
> Cc: SIP IETF
> Subject: RE: [Sip] Sip-199-02: majors and nits from Robert 
> (was: RE: WGLC for draft-ietf-sip-199-02)
> 
> 
> > I don't like must-nots if it doesn't break the protocol. 
> But, I agree 
> > we should strongly recommend against it.
> 
> optional, and customers have a hard time forcing vendors to 
> follow SHOULDs compared with MUSTs.  We've seen this time and 
> time again.  The _protocol_ may not "break", but user 
> expectations and experience "breaks", and at the end of the 
> day that hurts all of us.  Well, it doesn't hurt me right now 
> - it's created a market opportunity for SBCs to go and fix 
> it; but having middleboxes fix bad implementations is not 
> good in the long term for SIP.
> 
> IMO interoperability isn't just about _protocol_ behavior, 
> it's the resultant user experience too.  Legitimate call 
> attempts must succeed.  The spice must flow. ;)
> 
> -hadriel
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 24 Nov 2008 12:25:58 +0100

Hi,

Comments on the minor feedback from Robert.
 
-----

>Minor:
>min-1) (I waffled on putting this into major): This entire 
>mechanism is an optimization, but the word optimization is 
>never used. This is (as discussed so far) ONLY an 
>optimization and should be explicitly described as such 
>(including documenting the limitations of the optimization).

I am not sure I disagree with you, but I am trying to figure out what
optimization really means in this context.

As far as the limitation is concerned, I guess that is because of the
fact that it is an optional feature, and that it cannot be assumed that
199 responses will be received for all terminated dialogs.

-----

>min-2) The document uses "upstream" and "downstream" 
>throughout its text. We can probably find a way to replace 
>those terms with something less likely to induce confusion 
>especially when translating to other languages.

I think that wording has been used elsewhere, but I can use something
else.

-----

>min-3) The abstract shows the architectural confusion I call 
>out in maj-2. Its not clear what elements use the 199 in this 
>description.  

Now, assuming that both forking proxies and UASs can send 199, how about
the following:

"This specification defines a new SIP response code, 199 Early Dialog
Terminated, which 
a SIP forking proxy and UAS can use to indicate upstream towards the UAC
that an
early dialog has been terminated, before a final response is sent
towards the UAC."

-----

>min-4) The last sentence of the 5th paragraph of the 
>Introduction (which starts "When SIP entities upstream 
>receive") says SIP entities but talk about things that only 
>UACs can do, specifically terminating the session startup.

When SIP entities upstream receive the non-2xx final response they will
automatically terminate the session setup
and all associated early dialogs.

I could replace the text with the following:

"When SIP entities upstream receive the non-2xx final response they will
release resources associated with the session, and the UAC will terminte
the session setup."

-----

>min-5) Paragraph 1 of section 4 (Client Behavior) can be read 
>to say a UAC MUST always insert a Supported:199. It should 
>start with a conditional clause such as "If the client wants 
>to receive 199 responses, then".

Correct. I'll fix that.

-----

>which doesn't have meaning - I think it meant to say "the 
>sessions associated with some early dialogs may be set to inactive".

I could replace the text with the following:

"5. Limited access resources - in case of forking and multiple stream it
may not be possible to allow early 
media on all dialogs, so media sessions associated with some dialogs may
e.g. be set to "inactive". When a 
dialog is terminated, media sessions associated with other dialogs can
be allowed."

-----
 
>min-7) Section 5 should be titled "User-Agent Server" 
>behavior to avoid confusion with Proxies.

Ok.

-----

>min-8) (This will be major later in the review process if 
>it's still there when we get there). Section 6 uses 2119 
>capitalized words to restate requirements from other, already 
>published and referenced, documents. This is a practice we 
>should work hard to avoid. I suggest replacing the first two 
>sentences with "A proxy will forward a received 199 response 
>as it is required to forward all other non-100 provisional 
>responses by RFC 3261." Similarly, the last paragraph of 

Ok.

-----

>min-9) The part of section 6 that talks about the proxy 
>generating 199s on its own would be clearer if it were 
>structured around the generation of multiple 199s for a given 
>3-6xx with the case of only one 199 being generated falling 
>out as a special case. (currently it documents the 1 final 
>response makes 1 provisional response and calls out the 
>multiple-199 case as an exception/extension later in the section).

How about replacing:

"When a forking proxy receives a non-2xx final response which
terminates an early dialog and the proxy does not intend to forward
the final response immediately (due to the rules for a forking
proxy), and the UAC has indicated support of the 199 response code,
the proxy MUST generate and send a 199 provisional response upstream
for that early dialog, unless the proxy prior has received and
forwarded a 199 response for that early dialog.  The 199 provisional
response MUST contain a To header tag parameter, which identifies the
early dialog that has been terminated."

...with:

"When a forking proxy receives a non-2xx final response which terminates
one or more (if forking has occured early dialogs, and the proxy does
not intend to forward the 
final response immedialetly (due to the rules for a forking proxy), and 
the UAC has indicated support of the 199 response code, the proxy must 
generate and send a 199 provisional response upstream for the early
dialog 
on which the non-2xx final response was received. If the forking proxy
is able 
to identify additional early dialogs which are terminated by the same
non-2xx 
final response, the proxy must also generate and send a 199 provional
response upstream for each of those early dialogs."

...and by removing the NOTE.

I think that would make the text more clear.

-----

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 24 Nov 2008 12:32:37 +0100

Hi Hadriel,

I don't disagree with you.

However, there are examples where we do this kind of restrictions (e.g.
you-must-not-use-header-x-in-message-y) when we write our specs, and
later use-cases come up where those restrictions cause problems. 

Backward compability is important, but forward compability is also
important :)

As far as other SDOs are concerned, at least 3GPP doesn't specify that a
UA inserts 199 in Require.

Regards,

Christer

> Sent: 24. marraskuuta 2008 7:37
> To: Dean Willis
> Cc: Christer Holmberg; SIP IETF
> There are thousands of deployed SIP networks.  Not one of 
> them currently supports this 199 mechanism, AFAIK.  Putting 
> it in a Require will not interoperate with any of them, and 
> has a potential for causing harm to the service SIP is 
> supposed to provide: session establishment.  Obviously this 
> interoperates in the sense that the far-end will fail it, and 
> we have to be able to add option tags in Require for some new 
> things; but this 199 mechanism isn't in the same vein as 
> privacy or replaces option tags which need to be put in 
> Require sometimes to make calls work.  Honestly we should 
> have been more careful in the past about this, so we might as 
> well start now.
> 
> You may think this is a no-brainer, and that no one would be 
> so dumb as to put it in a Require, but history has already 
> proven otherwise for other option tags.  Been there, done 
> that, have the T-shirt.  It works in the closed environment 
> they deploy in at first, and then breaks when the environment 
> grows or is no longer closed.  I can already envision what 
> will happen with 199: some other SDO will decide this 199 
> thing is a good idea and makes the user experience better, so 
> it should be required in release X of their specs.
> 
> 
> > and there are presumably

---

From: Dean Willis <[email-masked]>
Date: Mon, 24 Nov 2008 07:37:09 -0600

> Then say MUST NOT except for diagnostic purposes.

"MUST NOT unless you have a reason" is the definition of "SHOULD NOT".

The product managers of the world may be illiterate, but changing SIP's
definitions of requirements language relative to the rest of IETF is not
likely to help them in the long term.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 24 Nov 2008 15:31:47 +0100

Hi,

One thing on min-2:

"Upstream" and "Downstream" are actually defined terms in RFC3261, and
also used in the text.

Regards,

Christer

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christer Holmberg
> Sent: 24. marraskuuta 2008 13:26
> To: Robert Sparks; SIP IETF
> Subject: [Sip] Sip 199-02: minors from Robert (was RE: WGLC 
> fordraft-ietf-sip-199-02)
> 
> 
> Hi,
> 
> mechanism is 
> >an optimization, but the word optimization is never used. 
> This is (as 
> >discussed so far) ONLY an optimization and should be explicitly 
> I am not sure I disagree with you, but I am trying to figure 
> out what optimization really means in this context.
> 
> As far as the limitation is concerned, I guess that is 
> because of the fact that it is an optional feature, and that 
> it cannot be assumed that
> those terms 
> >with something less likely to induce confusion especially when 
> >translating to other languages.
> 
> I think that wording has been used elsewhere, but I can use 
> something else.
> 
> 
> -----
> 
> 
> Now, assuming that both forking proxies and UASs can send 
> 199, how about the following:
> 
> "This specification defines a new SIP response code, 199 
> Early Dialog Terminated, which a SIP forking proxy and UAS 
> can use to indicate upstream towards the UAC that an early 
> dialog has been terminated, before a final response is sent 
> towards the UAC."
> 
> 
> -----
> 
> 
> terminates

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 24 Nov 2008 10:12:48 -0500

Sure we make mistakes just like anyone, though with regard to MUST NOT's we follow them more often than I think we ought to, ironically.
But no I was not referring to us - I was referring to the (rather common) situation where a device does not follow a SHOULD NOT, and because it was a SHOULD instead of MUST strength they get away with claiming it was not required to be followed.

Maybe it's just me who sees this happening?  That's certainly possible and if so I'll shut up about it.

-hadriel

> Sent: Monday, November 24, 2008 1:25 AM
>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 24 Nov 2008 09:32:51 -0600

And they have caused significant implementer confusion.

RjS

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Nov 2008 10:35:15 -0500

ISTM that the kinds of failures that will result from inappropriate use 
of Require:199 are self limiting. They will break things early in 
interop testing, and be fixed.

Omitting the option tag altogether wouldn't be so bad either. All UAs 
must be prepared to handle unknown error codes. If not understood, the 
199 will be treated as a 100. (Hmm, considering the special treatment of 
100, that isn't wonderful, but it does no harm.)

IMO the only reason to have the option tag is as an optimization, to 
prevent the sending of the extra message unless somebody cares about it. 
If it is only sent in the forking cases, this optimization may not be 
worth the trouble.

Bottom line, I propose we either:
1) have the option tag, and allow both Supported and Require, but
    include words discouraging Require; or
2) drop the option tag entirely.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Nov 2008 10:40:28 -0500

> And they have caused significant implementer confusion.

What would be better? Phrases like "toward the UAC" amd "toward the UAS" 
would *work* but are cumbersome.

Would it help to define upstream and downstream in the document?

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 24 Nov 2008 10:51:04 -0500

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, November 24, 2008 10:35 AM
>

You are refreshingly optimistic. :)  Have you read 3GPP specs recently?  In theory their behavior should be self-limiting too; but it works in their closed single-vendor environments on day-1, then breaks on day-2 when the environment grows or another vendor is added.  And since the new vendor being added is the one with motivation to make things work, the new vendor is the one that will add 199 support.  Then one day the customer will want to connect their network to others, and boom.

If we can't think of any legitimate use for an option-tag in Require, why should we allow it?

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 24 Nov 2008 22:23:37 +0100

Hi, 

>>ISTM that the kinds of failures that will result from inappropriate 
>>use of Require:199 are self limiting. They will break things early in 
>You are refreshingly optimistic. :)  Have you read 3GPP specs recently?
In theory their behavior should be self-limiting too; but it works in
their closed single-vendor environments on day-1, then 
>breaks on day-2 when the environment grows or another vendor is added.
And since the new vendor being added is the one with motivation to make
things work, the new vendor is the one that will add 199 
>support.  Then one day the customer will want to connect their network
to others, and boom.
>If we can't think of any legitimate use for an option-tag in Require,
why should we allow it?

Because there may be a legitimate use for it tomorrow, or next week, or
next year.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 24 Nov 2008 22:25:43 +0100

Hi,

If we can't even use the words defined, and used, in 3261 (and probably
in other specs) something is really wrong, and to start using different
wordings in different documents isn't going to make things more clear in
my opinion... 

However, I have no problem to copy/paste the definition text from 3261
into the 199-draft, if that helps.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, November 24, 2008 5:40 PM
To: Robert Sparks
Cc: Christer Holmberg; SIP IETF
Subject: Re: [Sip] Sip 199-02: minors from Robert (was RE: WGLC

	Paul

>> "Upstream" and "Downstream" are actually defined terms in RFC3261, 
>> and also used in the text.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>>> Of Christer Holmberg
>>> I am not sure I disagree with you, but I am trying to figure out 
>>> what optimization really means in this context.
>>>
>>> As far as the limitation is concerned, I guess that is because of 
>>> the fact that it is an optional feature, and that it cannot be 
>>> assumed that

>>> Now, assuming that both forking proxies and UASs can send 199, how 
>>> about the following:
>>>
>>> "This specification defines a new SIP response code, 199 Early 
>>> Dialog Terminated, which a SIP forking proxy and UAS can use to 
>>> indicate upstream towards the UAC that an early dialog has been 
>>> terminated, before a final response is sent towards the UAC."
>>>
>>>
>>> -----
>>>
>>>
>>>> (which starts "When SIP entities upstream
>>>> receive") says SIP entities but talk about things that only UACs 
>>>> can do, specifically terminating the session startup.
>>>
>>> When SIP entities upstream receive the non-2xx final response they 
>>> will automatically terminate the session setup and all associated 
>>> early dialogs.
>>>
>>> "When SIP entities upstream receive the non-2xx final response they 
>>> will release resources associated with the session, and the UAC will

>>> terminte the session setup."
>>>
>>>
>>> -----
>>>
>>>
>>>> min-5) Paragraph 1 of section 4 (Client Behavior) can be read to 
>>>> say a UAC MUST always insert a Supported:199. It should start with 
>>>> a conditional clause such as "If the client wants to receive 199 
>>>> responses, then".
>>>
>>> Correct. I'll fix that.
>>>
>>>
>>> -----
>>>
>>>
>>> "5. Limited access resources - in case of forking and multiple 
>>> stream it may not be possible to allow early media on all dialogs, 
>>> so media sessions associated with some dialogs may e.g. be set to 
>>> "inactive". When a dialog is terminated, media sessions associated 
>>> with other dialogs can be allowed."
>>>
>>>
>>>
>>> -----
>>>
>>>> min-8) (This will be major later in the review process if it's 
>>>> still there when we get there). Section 6 uses 2119 capitalized 
>>>> words to restate requirements from other, already published and 
>>>> referenced, documents. This is a practice we should work hard to 
>>>> avoid. I suggest replacing the first two sentences with "A proxy 
>>>> will forward a received 199 response as it is required to forward 
>>>> all other non-100 provisional responses by RFC 3261." Similarly, 
>>>> the last paragraph of section 7 should not use 2119 capitalized 
>>>> words.
>>>
>>> Ok.
>>>
>>>
>>> -----
>>>
>>>

>>>> one 199 being generated falling out as a special case. (currently 
>>>> it documents the 1 final response makes 1 provisional response and 
>>>> calls out the

>>> response MUST contain a To header tag parameter, which identifies 
>>> the early dialog that has been terminated."
>>>
>>> ...with:
>>>
>>> terminates one or more (if forking has occured early dialogs, and 
>>> the proxy does not intend to forward the final response immedialetly

>>> (due to the rules for a forking proxy), and the UAC has indicated 
>>> support of the 199 response code, the proxy must generate and send a

>>> 199 provisional response upstream for the early dialog on which the 
>>> non-2xx final response was received. If the forking proxy is able to

>>> identify additional early dialogs which are terminated by the same 
>>> non-2xx final response, the proxy must also generate and send a 199 
>>> provional response upstream for each of those early dialogs."
>>>
>>> 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
>>>
> 
> 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: "Christer Holmberg" <[email-masked]>
Date: Mon, 24 Nov 2008 22:34:31 +0100

Hi, 

>199 will be treated as a 100. (Hmm, considering the special treatment
of 100, that isn't wonderful, but it does no harm.)

Yes. That is the reason we decided to add the option-tag.
 
worth the trouble.

I see no trouble. We would just need to agree on some wording.

>2) drop the option tag entirely.

I will give my hum for 1).

Regards,

Christer

> There are thousands of deployed SIP networks.  Not one of them
currently supports this 199 mechanism, AFAIK.  Putting it in a Require
will not interoperate with any of them, and has a potential for causing
harm to the service SIP is supposed to provide: session establishment.
Obviously this interoperates in the sense that the far-end will fail it,
and we have to be able to add option tags in Require for some new
things; but this 199 mechanism isn't in the same vein as privacy or
replaces option tags which need to be put in Require sometimes to make
calls work.  Honestly we should have been more careful in the past about
this, so we might as well start now.
> 
> You may think this is a no-brainer, and that no one would be so dumb
as to put it in a Require, but history has already proven otherwise for
other option tags.  Been there, done that, have the T-shirt.  It works
in the closed environment they deploy in at first, and then breaks when
the environment grows or is no longer closed.  I can already envision
what will happen with 199: some other SDO will decide this 199 thing is
a good idea and makes the user experience better, so it should be
required in release X of their specs.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Nov 2008 16:48:39 -0500

I'm going to abstain from this particular issue from now on.
I don't see any good use for this option, but its not worth arguing more 
about.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 24 Nov 2008 22:51:15 +0100

Hi Hadriel, 

>Sure we make mistakes just like anyone,

So, soon people will have to start deploying SBCs, in order to fix the
mistakes made by their existing SBCs..... ;)

>though with regard to MUST NOT's we follow them more often than I think
we ought to, ironically.
>But no I was not referring to us - I was referring to the (rather
common) situation where a device does not follow a SHOULD NOT, and
because it was a SHOULD instead of MUST strength they get away with 
>claiming it was not required to be followed.
>

I've seen lots of funny stuff during the years also.

But, I think the correct way to prevent those is to make sure our specs
are clear enough, and easy to understand - not to start making
restrictions which may shoot back later.

Regards,

Christer

> > doesn't hurt me right now
> > - it's created a market opportunity for SBCs to go and fix it; but 
> > having middleboxes fix bad implementations is not good in the long 
> > term for SIP.
> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 24 Nov 2008 18:17:33 -0500

> Sent: Monday, November 24, 2008 4:51 PM
>

Well people do upgrade.  I think they usually find it easier to upgrade their SBCs than upgrade their customers' PBX's or peer's equipment, or even their own core servers.

> restrictions which may shoot back later.

The thing is with the 199-type of mechanism I actually don't think we should ever allow such a thing to be Required, ever.

What you are basically asking for is to create a new 1xx response code some device may require in order to operate correctly, and that I think is a bad idea.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 24 Nov 2008 18:47:32 -0500

> Sent: Monday, November 24, 2008 4:24 PM
> >

It occurs to me maybe we're talking past each other.  When I think of the *Require* header, I think of what does any random endpoint/gateway getting this request have to support for this to succeed.  I can see no value in having that behavior, and plenty of harm in doing so.  I don't want a UAC maker to ever think it can require UAS' to implement 199 in order for its request to succeed.
But maybe what you're talking about is *Proxy-Require*?

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Nov 2008 19:52:23 -0500

> But maybe what you're talking about is *Proxy-Require*?

Well, we know tht Proxy-Require is way more evil.

Even so, it probably is the thing that a UAC might want to use if it 
knew there were proxies doing the forking.

Trouble is - B2BUAs cause a lot of trouble with Require/Proxy-Require. I 
suspect that Proxy-Require should have been MiddleBox-Require, and so 
applied to B2BUAs.

So if you really need 199 responses any time a forked invite might have 
been abandoned, then I think you must use *both* Require and 
Proxy-Require. But that is pretty certain to guarantee that your call 
will fail.

This has convinced me that there is no valid use of Require / Proxy-Require.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 24 Nov 2008 20:09:50 -0600

On Nov 24, 2008, at 5:17 PM, Hadriel Kaplan wrote:

> Well people do upgrade.  I think they usually find it easier to  
> upgrade their SBCs than upgrade their customers' PBX's or peer's  
> equipment, or even their own core servers.
>
> The thing is with the 199-type of mechanism I actually don't think  
> we should ever allow such a thing to be Required, ever.
>
> What you are basically asking for is to create a new 1xx response  
> code some device may require in order to operate correctly, and that  
> I think is a bad idea.

Okay, that's an interesting argument.

In essence, you are saying that Requiring 199 support might break  
interoperability, therefore it should be forbidden.

Yet we have test scenarios where requiring 199 might be reasonable in  
order to differentiate the set of results expected in a test scenario.  
Such a scenario doesn't break anything.

This is hard to reconcile.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 24 Nov 2008 20:19:44 -0600

On Nov 24, 2008, at 5:47 PM, Hadriel Kaplan wrote:

>>> If we can't think of any legitimate use for an option-tag in  
>>> Require,
>> why should we allow it?
>>
> It occurs to me maybe we're talking past each other.  When I think  
> of the *Require* header, I think of what does any random endpoint/ 
> gateway getting this request have to support for this to succeed.  I  
> can see no value in having that behavior, and plenty of harm in  
> doing so.  I don't want a UAC maker to ever think it can require  
> UAS' to implement 199 in order for its request to succeed.

For each options tag, the RFC defining it should discuss when it is  
used in requests by the UAC.

It might be reasonable to give guidance about NOT using one; that is  
not using it in a Require. But the level of guidance, I think, is a  
SHOULD NOT. This needs to be explained: What happens if you do it  
anyhow? the answer is not "the network breaks", but "any UAS not  
supporting this feature will reject the request. Since this feature is  
only an optimization over previous behavior, rejecting a request over  
this lack is very likely to be undesirable behavior. Don't be stupid."

---

From: Dean Willis <[email-masked]>
Date: Mon, 24 Nov 2008 20:21:29 -0600

On Nov 24, 2008, at 6:52 PM, Paul Kyzivat wrote:

>> gateway getting this request have to support for this to succeed.   
>> I can see no value in having that behavior, and plenty of harm in  
> Trouble is - B2BUAs cause a lot of trouble with Require/Proxy- 
> Require. I suspect that Proxy-Require should have been MiddleBox- 
> Require, and so applied to B2BUAs.
>
> So if you really need 199 responses any time a forked invite might  
> have been abandoned, then I think you must use *both* Require and  
> Proxy-Require. But that is pretty certain to guarantee that your  
> call will fail.
>

Other than for testing for non-compliant proxies and UAs in your  
signaling path, aka "diagnostics".

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 25 Nov 2008 07:19:27 +0100

Hi, 

>>>>Require, why should we allow it?
>>>
>>>Because there may be a legitimate use for it tomorrow, or next week, 
>>> or next year.
>> 
>>It occurs to me maybe we're talking past each other.  When 
>>I think of the *Require* header, I think of what does any 
>>random endpoint/gateway getting this request have to support 
>>for this to succeed.  I can see no value in having that 
>>behavior, and plenty of harm in doing so.  I don't want a UAC 
>>maker to ever think it can require UAS' to implement 199 in 
>>order for its request to succeed.
>Even so, it probably is the thing that a UAC might want to 
>use if it knew there were proxies doing the forking.
> 
>Trouble is - B2BUAs cause a lot of trouble with 
>Require/Proxy-Require. I suspect that Proxy-Require should 
>have been MiddleBox-Require, and so applied to B2BUAs.
> 
>So if you really need 199 responses any time a forked invite 
>might have been abandoned, then I think you must use *both* 
>Require and Proxy-Require. But that is pretty certain to 
>guarantee that your call will fail.
> 

To me this has only convinced me that R/P-R in general is bad, and
should be avoided. But, that we have known all the time, and nobody has
argued against it.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 25 Nov 2008 07:29:20 +0100

Hi, 

>>It occurs to me maybe we're talking past each other.  When I think of 
>>the *Require* header, I think of what does any random endpoint/ 
>>can see no value in having that behavior, and plenty of harm in doing 
>>so.  I don't want a UAC maker to ever think it can require UAS' to 
>>implement 199 in order for its request to succeed.
>For each options tag, the RFC defining it should discuss when 
>it is used in requests by the UAC.
> 
>It might be reasonable to give guidance about NOT using one; 
>that is not using it in a Require. But the level of guidance, 
>I think, is a SHOULD NOT. This needs to be explained: What 
>happens if you do it anyhow? the answer is not "the network 
>breaks", but "any UAS not supporting this feature will reject 
>the request. Since this feature is only an optimization over 
>previous behavior, rejecting a request over this lack is very 
>likely to be undesirable behavior. Don't be stupid."

Based on the use-cases etc we have today, I think we all agree that one
really shouldn't require 199, so I don't think we need to argue about
that.

And, if the group wants to forbid Require:199 we will of course do that.
My personal prefernce, however, would still be to add text which
strongly discourages the use of Require.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 25 Nov 2008 07:33:55 +0100

Hi, 

>>What you are basically asking for is to create a new 1xx response code

>>some device may require in order to operate correctly, and that I 
>>think is a bad idea.
> 
>In essence, you are saying that Requiring 199 support might 
>break interoperability, therefore it should be forbidden.
> 
>Yet we have test scenarios where requiring 199 might be 
>reasonable in order to differentiate the set of results 
>expected in a test scenario.  

It doesn't matter what extension you require - if the other end doesn't
support it you will "break interoperability".

The point is that some extensions may really be needed in order to
things to work, so it makes more sense to require those. 

199 for sure is NOT an extensions which it makes sense to require.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 25 Nov 2008 07:35:11 +0100

Hi,

I think it would also have been very useful to have a
Forking-Proxy-Require header.

Regards,

Christer

> Sent: 25. marraskuuta 2008 2:52
> To: Hadriel Kaplan
> Subject: Re: [Sip] Sip-199-02: majors and nits from Robert
> 
> 
> 
> Hadriel Kaplan wrote:
> >