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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 29 Sep 2006 17:10:53 -0500

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

_______________________________________________
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: "Frank Shearar" <[email-masked]>
Date: Sat, 30 Sep 2006 09:46:41 +0200

"Vijay K. Gurbani" <[email-masked]> wrote:

<snip>

> Detailed review:
<snip>
> included in the REFER header.  Where will this header be defined?

It's defined in RFC 4538.

frank

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sat, 30 Sep 2006 09:23:23 -0500

> included in the REFER header.  Where will this header be defined?

It has been pointed out to me that this header exists in rfc4538;
I should have checked the IANA registry first.

So, given this, I will like to amend the above quoted section
as follows:

   Provide a reference for the specification defining the Target-
   Dialog header (rfc4538), and possibly rephrase the sentence
   as follows:

   OLD:
   A new header, Target-Dialog: perhaps, would be included
   in the REFER listing the dialog this REFER is associated with.

   NEW:
   The Target-Dialog header [RFC4538] would be included in the
   REFER, listing the dialog that the REFER request is associated
   with.

Thanks,

- vijay