Skip to main content

Multiple Dialog Usages in the Session Initiation Protocol
draft-ietf-sipping-dialogusage-06

Revision differences

Document history

Date Rev. By Action
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2007-09-12
06 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-09-11
06 (System) IANA Action state changed to No IC from In Progress
2007-09-11
06 (System) IANA Action state changed to In Progress
2007-09-11
06 Amy Vezza IESG state changed to Approved-announcement sent
2007-09-11
06 Amy Vezza IESG has approved the document
2007-09-11
06 Amy Vezza Closed "Approve" ballot
2007-09-11
06 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2007-09-11
06 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss by Tim Polk
2007-06-08
06 (System) Removed from agenda for telechat - 2007-06-07
2007-06-07
06 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2007-06-07
06 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2007-06-07
06 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2007-06-07
06 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2007-06-07
06 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2007-06-07
06 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2007-06-06
06 Russ Housley
[Ballot comment]
From the Gen-ART by Pasi Eronen ...

  Some editorial suggestions: RFC editor nowadays recommends using
  symbolic references (e.g. [RFC3911] …
[Ballot comment]
From the Gen-ART by Pasi Eronen ...

  Some editorial suggestions: RFC editor nowadays recommends using
  symbolic references (e.g. [RFC3911] instead of [5]); and abbreviations
  should be expanded on first use (e.g. KPLM, UA, UAC, UAS, and GRUU).
2007-06-06
06 Russ Housley
[Ballot discuss]
What happened with LC comments from Ian Elz?  I think a response was
  deserved, but I cannot find one.  Did I miss …
[Ballot discuss]
What happened with LC comments from Ian Elz?  I think a response was
  deserved, but I cannot find one.  Did I miss it?
2007-06-06
06 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2007-06-06
06 Sam Hartman [Ballot Position Update] New position, Yes, has been recorded by Sam Hartman
2007-06-06
06 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2007-06-06
06 Tim Polk
[Ballot discuss]
Section 5.4.  - I am confused by the statement that REFER was "clarified in a bug against RFC
3515
".  I assumed that …
[Ballot discuss]
Section 5.4.  - I am confused by the statement that REFER was "clarified in a bug against RFC
3515
".  I assumed that meant "clarified in an errata against RFC 3515" but no such errata were
found on the IETF website.  Where is this documented?

There are also problems with the statement that INVITE, UPDATE, SUBSCRIBE, and NOTIFY
were "clarified in a bug against RFC 3565".  RFC 3565 is actually "Use of the Advanced
Encryption Standard Ecryption Algorithm in the Cryptographic Message Syntax", and I
can't find any SIP related content.  Where are these clarifications documented?
2007-06-06
06 Tim Polk
[Ballot discuss]
Section 5.4.  - I am confused by the statement that REFER was "clarified in a bug against RFC
3515
".  I assumed that …
[Ballot discuss]
Section 5.4.  - I am confused by the statement that REFER was "clarified in a bug against RFC
3515
".  I assumed that meant "clarified in an errata against RFC 3515" but no such errata were
found on the IETF website.  Where is this documented?

I am even more confused by the statement that INVITE, UPDATE, SUBSCRIBE, and NOTIFY
were "clarified in a bug against RFC 3565".  RFC 3565 is actually "Use of the Advanced
Encryption Standard Ecryption Algorithm in the Cryptographic Message Syntax", and I
can't find any SIP related content.
2007-06-06
06 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2007-06-06
06 Tim Polk
[Ballot comment]
Should Section 6 be renamed "Avoiding Multiple Usages in Applications"?  As I interpreted the
earlier sections, multiple usages are unavoidable.  The problem is …
[Ballot comment]
Should Section 6 be renamed "Avoiding Multiple Usages in Applications"?  As I interpreted the
earlier sections, multiple usages are unavoidable.  The problem is coordination and control
where an application requires multiple simultaneous usages.  Is that correct?  If so, renaming
section 6 would avoid some confusion.
2007-06-06
06 Dan Romascanu [Ballot Position Update] New position, Yes, has been recorded by Dan Romascanu
2007-06-05
06 Lisa Dusseault
[Ballot comment]
I don't understand this sentence from the Sec Cons:

"A service that disallows multiple usages should consider the effect on clients that, for …
[Ballot comment]
I don't understand this sentence from the Sec Cons:

"A service that disallows multiple usages should consider the effect on clients that, for instance, destroy the entire dialog when only a usage should be torn down."

I'm not sure if it means that a service which plans to reject attempts to create a second usage might consider first whether that would cause clients to destroy the entire dialog unnecessarily, or if there's some other way that a service might disallow multiple usages. 

Part of my confusion might be whether a "service" refers to a SIP feature standard (e.g. an extension), or an instance of a deployed and running feature (kind of analogous to a 'site' in other apps or "Web application" for the Web).
2007-06-05
06 Lisa Dusseault [Ballot Position Update] New position, Yes, has been recorded by Lisa Dusseault
2007-06-05
06 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2007-06-05
06 Lars Eggert [Ballot comment]
This document reads more like a BCP than an Informational; especially Section 6. Was there consensus against making it a BCP?
2007-06-05
06 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2007-06-04
06 Cullen Jennings [Ballot Position Update] New position, Yes, has been recorded by Cullen Jennings
2007-05-31
06 Jon Peterson Placed on agenda for telechat - 2007-06-07 by Jon Peterson
2007-05-31
06 Jon Peterson State Changes to IESG Evaluation from Waiting for Writeup by Jon Peterson
2007-05-31
06 Jon Peterson [Ballot Position Update] New position, Yes, has been recorded for Jon Peterson
2007-05-31
06 Jon Peterson Ballot has been issued by Jon Peterson
2007-05-31
06 Jon Peterson Created "Approve" ballot
2007-05-10
06 (System) State has been changed to Waiting for Writeup from In Last Call by system
2007-05-06
06 Yoshiko Fong IANA Last Call Comments:

As described in the IANA Considerations section, we understand
this document to have NO IANA Actions.
2007-04-27
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Lakshminath Dondeti
2007-04-27
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Lakshminath Dondeti
2007-04-26
06 Amy Vezza Last call sent
2007-04-26
06 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2007-04-25
06 Jon Peterson Last Call was requested by Jon Peterson
2007-04-25
06 Jon Peterson State Changes to Last Call Requested from Publication Requested by Jon Peterson
2007-04-25
06 (System) Ballot writeup text was added
2007-04-25
06 (System) Last call text was added
2007-04-25
06 (System) Ballot approval text was added
2007-02-20
06 (System) New version available: draft-ietf-sipping-dialogusage-06.txt
2006-11-25
06 Dinara Suleymanova
PROTO Write-up

    1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do …
PROTO Write-up

    1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

The SIPPING WG chairs have reviewed the document and believe it is ready for publication. Gonzalo Camarillo is its PROTO shepherd.

    1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

The draft has been thoroughly reviewed by a number of SIPPING members.

    1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

We do not have any particular concern in that respect.

    1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

We feel comfortable with the document.

    1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There is strong consensus within the WG that dialog usage is an important issue in the SIP area.

    1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

Nobody has done anything to stop this document.

    1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes, it does.

    1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

The document only has informative references.

    1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

    Several methods in the Session Initiation Protocol can create an
    association between endpoints known as a dialog.  Some of these
    methods can also create a different, but related, association within
    an existing dialog.  These multiple associations, or dialog usages,
    require carefully coordinated processing as they have independent
    life-cycles, but share common dialog state.  Processing multiple
    dialog usages correctly is not completely understood.  What is
    understood is difficult to implement.
    This memo argues that multiple dialog usages should be avoided.  It
    discusses alternatives to their use and clarifies essential behavior
    for elements that cannot currently avoid them.
    This is an informative document and makes no normative statements of
    any kind.


        *    Working Group Summary

There was strong consensus within the WG that this was an important issue that needed to be documented in an RFC.


        *    Protocol Quality

Jon Peterson is the Responsible Area Director. The WG chair shepherd
for the document is Gonzalo Camarillo.


Best regards,

Gonzalo
2006-11-25
06 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2006-11-14
05 (System) New version available: draft-ietf-sipping-dialogusage-05.txt
2006-10-23
04 (System) New version available: draft-ietf-sipping-dialogusage-04.txt
2006-08-30
03 (System) New version available: draft-ietf-sipping-dialogusage-03.txt
2006-06-27
02 (System) New version available: draft-ietf-sipping-dialogusage-02.txt
2006-03-03
01 (System) New version available: draft-ietf-sipping-dialogusage-01.txt
2005-11-28
00 (System) New version available: draft-ietf-sipping-dialogusage-00.txt