Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)
draft-ietf-sip-uri-list-message-03

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

Lars Eggert No Objection

(Cullen Jennings; former steering group member) Yes

Yes ()
No email
send info

(Dan Romascanu; 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

(Jon Peterson; former steering group member) No Objection

No Objection ()
No email
send info

(Lisa Dusseault; former steering group member) (was Discuss) No Objection

No Objection (2008-06-17)
No email
send info
COMMENTS

1. Page 10, grammar nit:  please fix the sentence that reads

   Failing to copy the From header field of the sender would
   prevent the recipient to get a hint of the sender's identity.

Along with the grammar fix, I'd like a stronger term than "hint".  How about

   Failure to copy the From header field of the sender results
   in unacceptable security and privacy failures.

Still vague but maybe there's something better.

2. The requirement related to CSeq should reference RFC3261?

3. The VIA header field that the URI-list service adds should distinguish what it did from pure forwarding.  Is there room in SIP Via headers to indicate the function that was performed?

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

No Objection ()
No email
send info

(Tim Polk; former steering group member) No Objection

No Objection ()
No email
send info