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

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 2 Mar 2006 07:22:48 +0100

Hi,

Here are some comments on the draft.

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.

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???

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.

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.

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.

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.

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)?

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...

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?

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.

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).

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?

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.

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.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 2. maaliskuuta 2006 7:25
To: Robert Sparks; sipping
Subject: Re: [Sipping] Reminder: WG item : dialog-usage

Robert Sparks wrote:
> Ah - now that I've had a chance to look, I don't feel quite as bad :)
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sipping- 
> dialogusage-00.txt
> 
> is not expired. I think you were remembering the individual
submission.

Duh. You took the hyphen out of dialogusage, which screwed up all my
attempts to find it. :-(

> I do still need to reflect the 481 clarification we converged on in  
> the list.

I think some of the discussion we have been having about what state is
associated with a dialog vs what is associated with each kind of dialog
usage would be helpful, as would a few words about the fact that the
dialog event package is really about the invite dialog usage. I have to
find some time to review the draft again carefully and see for sure if
stuff like that makes sense in there. While this kind of stuff could go
somewhere else, it would be good for it to go somewhere, and I doubt
that yet another draft is in anyone's best interest.

	Thanks,
	Paul

> RjS
> 
> 
> On Mar 1, 2006, at 8:29 PM, Paul Kyzivat wrote:
> 
>>
>>
>> Robert Sparks wrote:
>>
>>> Fair point. And I will have an -01 in before the -01+ deadline to   
>>> correct that problem.
>>> I'll comb the pre-Vancouver conversations again and make sure I   
>>> captured all those clarifications.
>>> I hope we get some other gems from the discussion Christian started.
>>> The biggest objection you had to the -00 version (IIRC), was the   
>>> position it took that multiple usages
>>> were to be avoided. The list and meeting discussion around that   
>>> reinforced for me that this was the
>>> consensus position and that's what the -01 draft will continue to
say.
>>
>>
>> Yeah. There was also some discussion about what 481 means.
>>
>>     Paul
>>
>>> RjS
>>> On Mar 1, 2006, at 4:28 PM, Paul Kyzivat wrote:
>>>
>>>> Robert,
>>>>
>>>> Its hard to have last call on a document that isn't in the  server.

>>>> The -00 version expired quite some time ago, and I'm not  aware of 
>>>> a  newer one.
>>>>
>>>> We had some discussion of it before the last meeting, and there   
>>>> were at least a few points that needed some clarification.
>>>>
>>>> Based on some of the recent discussion threads, we may want to   
>>>> consider putting more into it. Maybe we need to have an informal   
>>>> hallway ad hoc in Dallas among those who are interested.
>>>>
>>>>     Paul
>>>>
>>>> Robert Sparks wrote:
>>>>
>>>>> We've taken on documenting the issues around having multiple   
>>>>> dialog  usages share a dialog as a working group item.
>>>>> draft-ietf-sipping-dialog-usage-00.txt is the current draft    
>>>>> addressing that item.
>>>>> I believe it to be essentially done and will ask the chairs to   
>>>>> last  call the document as soon as I re-verify coverage of the 
>>>>> response codes.
>>>>> If you have not read this document, now would be a good time.
>>>>> Thanks!
>>>>> 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
> 
> 

_______________________________________________
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

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: Thu, 2 Mar 2006 11:05:07 -0600

Thanks Christer!

responses inline:

> Here are some comments on the draft.

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.

> 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."

> legal things are not clearly specified.

Agreed. Normative changes are the next step.

> should be rejected - in order to cause strange and unwanted behaviour.

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

> 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.)

I'll also see if it would be too messy to put in more discussion of
reuses (the draft already talks about subscriptions within invite- 
initiated dialogs).
I'll see if I can put in a paragraph about invite-usages inside  
subscriptions).

> ABSTRACT CHAPTER

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.

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

> CHAPTER 3.1

When I prepared the original individual submission, I tried to write  
this
with 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
out 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
will reduce potential confusion. I'll see if I can change all those  
in this revision.

> intermediated nodes) may now WHICH dialog usage to terminate. Is this
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_  
usages
are affected (by destroying the dialog). I'll make that explicit in  
this section.

> stateful intermediate nodes this may cause problems.

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

> purpose be for a specific dialog usage only).
Well, I've already said where I stand on this.
> CHAPTER 3.2
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.

> CHAPTER 3.4

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

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...