Subject: RE: [Sipping] Reminder: WG item : dialog-usage

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 3 Mar 2006 14:03:41 +0100

Hi, 

>GENERAL
>----------------
>
>C1: It is good to give recommendations, write informative drafts etc, 
>to use as base for future work. BUT, for an implementor that is not 
>enough.
>An implementor MUST know what is allowed and what is not. We must 
>remember that this is not only an endpoint issue. Intermediate, 
>stateful proxies also need to know what to do.

I agree that there is normative work to be done - the draft calls that
out as it identifies it. This analysis step will help us make sure we
make the right normative changes in the right priority as the next step.

[CHH] Ok, I guess we have a different view of the purpose of the draft
:) I would like to see it as normative, while you seem to see it as a
document describing "issues for which we have to come up with normative
text". I don't really care which way we go, but as I said earlier: since
the re-usage is allowed, and used, in SIP we need to somewhere have
normative text on how it is to be correctly handled. I think it would be
very interesting to test this as SIPit (assuming there are entities
doing this kind of stuff, that is :)

>Yes, the drafts strongly recommends aginst dialog re-usage, and it has
been said it causes interop problems etc etc etc. But, then my  
>question is: why allow it in the first place???

My opinion: only because the existing deployed systems rely on it for
transfer (REFER inside an INVITE usage). We didn't really intend to
have multiple usages in dialogs - they're an artifact we discovered,
and early on took advantage of to address problems with routing to
particular destinations. Now that we've realized there are problems
with multiple usages, we're doing work to make them unnecessary.
I hope things will go such that, eventually, we'll look around and say
"Wow, nothing's relying on this multiple-usage thing anymore, lets
go ahead and completely remove it."

[CHH] ...or at least minimize the allowed "usage combinations".

>IF we want to allow it (which I assume we DO want, EVENT if one may say
>it's a bad idea), I think we should specify normative text, instead of
>just recommendations... Interop problems are caused by the fact that
>legal things are not clearly specified.

Agreed. Normative changes are the next step.

>One question is of course whether dialog re-usage should be considered
>as a SIP extension, with an assoicated option-tag etc. If not, I think
>there should be normative text for how to implement support of dialog
>re-usage. And, if someone does NOT support dialog re-usage, requests
>should be rejected - in order to cause strange and unwanted behaviour.

I think you were missing a "not" in that last sentence?

[CHH] Yes :)

>C2: Sometime in the document I think it would be useful to have some
>kind of "table", showing the different usages, and how each usage it
>initiated and terminated. Yes, one can get that information from
>elsewhere, but I think it would be useful to collect it in one place.

Hrm. Ok - its worth a short reference spot, and it is short
( REGISTER, SUBSCRIBE/NOTIFY (REFER/NOTIFY), and INVITE.)

[CHH] What I had in mind was to list the different usage types, as
you've done, but also for each type describe how each type is initiated,
and how it is terminated. Then it is easier, when e.g. a BYE is
recieved, to check and see that only the invite dialog usage shall be
terminated.

Something like:

Usage type				Initiated
Terminated
-----------------------------------------------------------------

SUBSCRIBE/NOTIFY			SUBSCRIBE
SUBSCRIBE/NOTIFY (duration value = zero)
...

Or something like that...

>ABSTRACT CHAPTER
>---------------------------------
>
>C3 (EDITORIAL):
>
>It if first said that a dialog is an association between endpoints.
>Later it is said that an association is a dialog usage, and that
>multiple associations may exist within an existing dialog. That is
>confusing. An association shall be EITHER a dialog OR a dialog usage -
>it can't be both.

I disagree with the last statement, but will attempt to wordsmith  
around the confusion.
The usage and dialog are both associations, they're just _different_
but related associations.
Paul's suggestion to capture a description of the state involved in  
These different associations may be enough to clear up the confusion.

[CHH] You can of course have multiple dialogs between endpoints. But,
then they are completely separated from each other, and I don't think
that is what you mean by multiple associations. At least I see multiple
associations as multiple dialog usages inside a SINGLE dialog.

>INTRODUCTION CHAPTER
>----------------------------------------
>
>Q4:
>
>Should it be added to the first paragraph that a dialog initiated  
>with a REFER request (outside an existing dialog) has a "refer usage"
(we can
>say that it is similar to subscribe usage)?

A REFER usage _IS_ a subscribe usage, it's not just similar to one.
I can state that explicitly here.

[CHH] I think it would be good to mention that the difference is that
the REFER will not contain a dialog usage duration, and that
implementations should be aware of that (again, in case there is no
NOTIFY/SUBSCRIBE sent the dialog may live forever).

>CHAPTER 3.1
>---------------------
>
>
>C5: This chapter uses the subscibe dialog as "base". Shouldn't it be
>more generic? For example, for 403 it is said "This response terminates
>the subscription, but has no effect on any other usage of the dialog".
>Shouldn't it simply say "This response terminates the dialog usage for
>which it was received", or something like that. And the same for other
>response codes...

When I prepared the original individual submission, I tried to write  
This ith the motivating scenario being a generic usage, and the wording
became very awkward - even opaque. The approach this section
currently uses, (basing the description on a particular scenario and  
Calling ut when things would be different in other scenarios) worked
much  
better.
But I can see spots, like the example you point out, where we can speak
more generically about a result without introducing error, and agree  
that it ill reduce potential confusion. I'll see if I can change all
those  
in this revision.

>C6: For most response codes, it is recommended that the dialog  
>usage for which the response code is sent/received is terminated, but
other  
>dialog usages are kept "alive". That is probably no big issue for the
UAC,
>because it knows for which dialog usage a request was sent, so it  
>knows for which dialog usage a response is received. BUT, in case there
are
>requests that can be used for multiple dialog usages (as described in
>chapter 3.3), the UAS sending the response code (and stateful
intermediated nodes) may now WHICH dialog usage to terminate. Is this
>theoretical, or?

The answer on the UAS side is going to be the same as what's in that  
section.
For such requests (like OPTIONS), no usage gets affected unless _all_  
Usage are affected (by destroying the dialog). I'll make that explicit
in  
this section.

>C7: In general, I think it's rather complicated when some response  
>codes terminate the whole dialog, while other response codes within the
same
>"response code group" (4xx, 5xx, 6xx etc) do not. Especially for
>stateful intermediate nodes this may cause problems.

No kidding! That's why this is worthy of so many bits in a draft :)

[CHH] Do you think it would be possible to say that e.g. ALL 4xx
responses terminates only the dialog usage? I KNOW there are response
codes, for which one can claim that the whole dialog should be
terminated, but from an implementation (read: interop) point of view I
think it would be more clear.

>Again, assuming we don't want to FORBID (recommendations and should- 
>nots doesn't help very much) re-usage, one idea could be to define a
new
>header/header parameter, which would be used to indicate whether a
>request/response is related to a dialog usage only, or to the whole
>dialog. The value could e.g. be "0", indicating all dialogs, or  
>another integer with a value that has been assigned for the specific
dialog
>usage (of course, things like target refreshes would still affect the
>whole dialog, even if the target refresh request may for some other
>purpose be for a specific dialog usage only).

Well, I've already said where I stand on this.

[CHH] I don't necessarily disagree with you, but IF we at some point
find out that we need to allow people to do this re-usage...

> CHAPTER 3.2
> ---------------------
>
> C6: See C2.
>
>
> CHAPTER 3.3
> ---------------------
>
> C7: Here it is said that UPDATE is used only for invite dialogs.  
> But, as I said earlier (in the "Questions on subscription dialogs"
thread),  
> that is not (as far as I know) specified anywhere. That same goes for

> INFO. I can't find any text in RFC2976 saying that INFO can be used
only  
> for an INVITE initiated dialog. The RFC does talk about sending
mid-call
> information, but is a call always an invite dialog?

As our understanding evolves, so does our language. There's a reason
we try really hard not to say "call" in our specs anymore - it's very  
hard to agree on what it means.

So, I think you're exposing an action to be sure to clarify UPDATE  
the next time it's touched. It is clear that UPDATE modifies
INVITE-usages  
(session-usages?).
It's expressed reason to exist is to "update the parameters of a  
session".

And you have to read INFO in the context it was written. At that  
time, a "call" was a dialog (at least as much as it was anything well
defined). We were  
talking about invite-usages there, but didn't know it yet. Like UPDATE,
it will  
need to be clarified the next time it's touched.

[CHH] Just we were talking about invite usages (invite usage = session)
at that point I don't think we can by default it's not allowed for other
usages - especially since we, as you said, weren't aware of any other
usages at that time :)

> CHAPTER 3.4
> ---------------------
>
>C8: VERY important text. I think "requests" should be removed from the
>chapter name, because I see target refresh as a function.

Not sure that changes the meaning of the section at all.
I'd prefer to leave the word requests here to help people who are  
Searching for strings (they'll still find just "target refresh").

> CHAPTER 3.6
> ---------------------
>
> C9: I don't think 603 is always the best option, because the new usage
> may be rejected because of temporary reasons.

Hrmm. Well, per the recommendation of the draft, you don't want
new usages in general. 603 is the safest way to say no when somebody
asks for a new one without destroying your existing one, when your
policy is not to allow multiple usages.

But even in the case you are describing, where you allow multiple usages
but don't want to allow this extra usage right now, 603 allows for  
Retry-After...

[CHH] Yes, but there may be "dialog specific" reasons. I can't use
Retry-After so say "Please don't use the xxx capabilities next time,
because I can't allow you to do dialog reusage". Maybe we should have a
NEW response code "4yz (Dialog usage not allowed)", or something...

Regards,

Christer

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Mar 2006 10:32:07 -0500

> NOTIFY/SUBSCRIBE sent the dialog may live forever).

The REFER will not specify the expiration time, but the resulting 
subscribe usage *will* still *have* an expiration time. It will simply 
be populated with a default, and then potentially be overridden in the 
first NOTIFY.

	Paul