Multiple Dialog Usages in the Session Initiation Protocol
RFC 5057

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

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?

(Cullen Jennings; former steering group member) Yes

Yes ()
No email
send info

(Dan Romascanu; former steering group member) Yes

Yes ()
No email
send info

(Jon Peterson; former steering group member) Yes

Yes ()
No email
send info

(Lisa Dusseault; former steering group member) Yes

Yes (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; former steering group member) Yes

Yes ()
No email
send info

(Chris Newman; former steering group member) No Objection

No Objection ()
No email
send info

(David Ward; former steering group member) No Objection

No Objection ()
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ()
No email
send info

(Mark Townsley; former steering group member) No Objection

No Objection ()
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ()
No email
send info

(Ross Callon; former steering group member) No Objection

No Objection ()
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (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).

(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection (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.