Subject: Re: [Sipping] WGLC review of draft-ietf-sipping-dialogusage-03

From: Paul Kyzivat <[email-masked]>
Date: Sun, 01 Oct 2006 22:28:56 -0400

I'd like to comment further on REGISTER.

As far as I can tell, the relationship between REGISTER and dialogs is 
that both use Call-ID. I don't believe 3261 or any other RFC actually 
uses the term "dialog" in relationship to registration. IMO it would be 
best to refrain from even hinting that there is any such relationship. I 
am inclined to think REGISTER should not even be mentioned in this draft.

	Paul

Vijay K. Gurbani wrote:
> Draft: draft-ietf-sipping-dialogusage-03
> Reviewer:  Vijay K. Gurbani <[email-masked]>
> Review Date: Sept. 29, 2006
> Review Deadline:  Oct. 2, 2006
> Status: WGLC
> 
> Summary:
> This draft is basically ready for publication, but has nits that should
> be fixed before publication.
> 
> Detailed review:
> This document posits that multiple dialog usage should be avoided simply
> because its use was never envisioned in the protocol (SIP).  As a
> result, the use of multiple dialogs today is rife with error cases that
> are not canonicalized anywhere (and this draft attempts to document some
> of these), nor does the working group has any substantive experience in
> other cases where multiple dialog usage may be employed (e.g., use of
> multiple dialogs with rfc3891, the "Replaces" header.)
> 
> As such, protocol designers are urged not to design extensions that
> depend on, or employ multiple dialog usage semantics, and implementors
> are urged not to support such usage in new code.
> 
> IMHO, this document needs to be more forceful in pointing the
> conclusions in the above paragraph out -- this is what I surmised after
> reading the document, especially S5.  The first two paragraphs of S5
> should be put in the Abstract and then repeated again in the
> Introduction, just to be safe.
> 
> One aspect that the draft points out on multiple occasions is that
> so far (thankfully) we do not have implementations that share REGISTER-
> created dialog usages.  It should then point out in a forceful manner
> that protocol designers should not even contemplate on doing this, nor
> should implementors assume that REGISTER establishes a dialog usage that
> can be shared.  It attempts to softly caution implementors and protocol
> designers at a couple of places -- one being the end of the first
> paragraph in S4.3,and the other being the last paragraph of S1 -- but
> the draft should take a position that no one has done it yet and it is
> expected that no one will do so in the future either.
> 
> S5 states that the working group is not comfortable with recommending
> that GRUUs be used as part of a solution, yet one of the two ways to
> avoid multiple usages shown in the document utilizes a GRUU.  I think
> that section needs to simply be re-organized such that it presents
> two ways to avoid multiple usages: one - use Join and Replaces, and
> two - use Join and Replaces with GRUU.
> 
> Also, the same section proposes a new header, Target-Dialog, to be
> included in the REFER header.  Where will this header be defined?
> 
> I will also second Paul's idea of using some sort of a table for Section 4.
> 
> Nits:
> * S2.1, paragraph 1: we need a better word than "springs" -- maybe
>  "comes"?
> 
> * S2.1, Figure 1: I think you mean "Dialog 1 Usage 1 Proceeds" towards
>  the end of the figure.
> 
> * S2.2: s/He decides skip/He decides to skip/
> 
> * S4: s/explores the problem spots/explores the problem areas/
> 
> * S4.1, discussion on 480: It says "Clarifications will be made to
>  show..." by who?  you probably mean later versions of rfc3261?  If so,
>  maybe reword it as "Later revisions of the SIP specification are
>  expected to include clarifications that show..."
> 
> * S4.1, discussion on 503: towards the end, you are missing a closing
>  parenthesis.
> 
> * S4.1, discussion on 604: s/is being 604ed/ is being responsed to by a
>  604/
> 
> * S5: s/by two primary pressures/by three primary pressures
> 
> * S5, list item 1: replace the subjective personal pronoun "we" in the
>  last sentence with more neutral phrasing.  Something like:
>     Sending the REFER on an existing dialog at the very least
>     ensured that it got to the same endpoint with which the
>     existing dialog had already been established.
> 
> * In Figure 3, flow F1, s/call-id-one/call-id one/
>                                      (i.e., no '-')
> 
> Thanks.
> 
> - vijay

_______________________________________________
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: [email-masked]
Date: Sun, 1 Oct 2006 22:51:15 -0400

From: Paul Kyzivat <[email-masked]>

I'd say we better mention REGISTER or someone will assume things that
we don't want.

I've used the term "quasi-dialog" for the series of REGISTERs that
share a Call-Id.  They share some of the properties of a dialog -- a
common Call-Id and similar semantics for CSeq -- but they definitely
do not share some others -- particularly having a route-set, and so
all requests are routed as initial requests, not mid-dialog requests.
Calling this out in detail will reduce future misunderstandings by
implementors.

And of course we should vigorously specify that a REGISTER
"quasi-dialog" is not to be shared (its Call-Id is not to be used)
with any other purpose.

Dale

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sun, 01 Oct 2006 23:42:39 -0500

Paul Kyzivat wrote:
> best to refrain from even hinting that there is any such relationship. 

We're in agreement.

> I am inclined to think REGISTER should not even be mentioned 
> in this draft.

Silence on a topic is often interpreted as a tacit endorsement for
the implementor to fill in the blanks according to his or her wants,
often to the detriment of the protocol.  Explicitly warning people
not to create dialogs for REGISTER is a better strategy, IMHO.

I'll leave it to Robert on what to do; but my preference would be
to state point out in a forceful manner that protocol designers
should not even contemplate on doing this, nor should implementors
assume that REGISTER establishes a dialog usage that can be
shared.

Thanks.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)

---

From: Benny Prijono <[email-masked]>
Date: Mon, 02 Oct 2006 12:17:37 +0100

> not to create dialogs for REGISTER is a better strategy, IMHO.

I think partly the confusions come from RFC 3261 itself. While it says 
that the only dialog establishing method defined by 3261 is INVITE 
method, the sample REGISTER call flow (section 24.1, page 214) shows 
that the 200/OK response to REGISTER contains a To tag. As we know, 
the combination of From tag, To tag, and Call-ID defines a dialog, so 
looking at the sample call flow, people may mistakenly think that 
REGISTER session is a dialog. And I do see some people call REGISTER 
session a dialog.

I'm not suggesting that we should put explicit warning for REGISTER, 
but I'm not against it either. Although if we need to put specific 
text on REGISTER, then probably we'd better put it in broader context 
such as what methods establish a dialog.

-benny

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Oct 2006 10:46:42 -0400

To all of you - I'm fine with mentioning REGISTER in the dialogusage 
draft with the caveats you all have suggested.

	Paul

Benny Prijono wrote:
> that the 200/OK response to REGISTER contains a To tag. As we know, the 
> combination of From tag, To tag, and Call-ID defines a dialog, so 
> I'm not suggesting that we should put explicit warning for REGISTER, but 
> I'm not against it either. Although if we need to put specific text on 
> REGISTER, then probably we'd better put it in broader context such as 
> what methods establish a dialog.
> 
> -benny
>

---

From: Robert Sparks <[email-masked]>
Date: Sat, 21 Oct 2006 18:00:16 -0500

Thanks Vijay -
Responses inline

> Introduction, just to be safe.

Well, at risk of giving Paul even more indigestion, I've made minor  
tweaks
to try to help others see what you're pointing to from the beginning.

> expected that no one will do so in the future either.
Based on subsequent list discussion, I modified section 1 to be more  
explicit.
> two - use Join and Replaces with GRUU.
This text needs to be brought in line with current events.
The discomfort previously expressed may not longer be present.
If GRUU ever stops moving around (cross your fingers), the necessary  
fixes
to this text may make the problem you see here go away.
> * S2.1, paragraph 1: we need a better word than "springs" -- maybe
fixed (and made the paragraph internally consistent)
> * S2.1, Figure 1: I think you mean "Dialog 1 Usage 1 Proceeds" towards
No, I meant Dialog 2 - the one between Bob and Carol.
> * S2.2: s/He decides skip/He decides to skip/
Fixed (someone else pointed at this earlier too)
> * S4: s/explores the problem spots/explores the problem areas/
ok
>  expected to include clarifications that show..."
Made a similar change
> * S4.1, discussion on 503: towards the end, you are missing a closing
fixed
> * S4.1, discussion on 604: s/is being 604ed/ is being responsed to  
You don't like 604 as a verb? I fixed the sentence.
> * S5: s/by two primary pressures/by three primary pressures
s/two/these/ instead
>     existing dialog had already been established.
ok
> * In Figure 3, flow F1, s/call-id-one/call-id one/
And also changed call-id-four to call-id four.