Multiple Dialog Usages in the Session Initiation Protocol
RFC 5057

Note: This ballot was opened for revision 06 and is now closed.

(Lisa Dusseault) Yes

Comment (2007-06-05)
No email
send info
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).

(Sam Hartman) Yes

(Cullen Jennings) Yes

(Jon Peterson) Yes

(Dan Romascanu) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lars Eggert) No Objection

Comment (2007-06-05)
No email
send info
This document reads more like a BCP than an Informational; especially Section 6. Was there consensus against making it a BCP?

(Russ Housley) (was Discuss) No Objection

Comment (2007-06-06)
No email
send info
  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).

(Chris Newman) No Objection

(Tim Polk) (was Discuss) No Objection

Comment (2007-06-06)
No email
send info
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.

(Mark Townsley) No Objection

(David Ward) No Objection