Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)
RFC 6993

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

(Richard Barnes) Yes

(Gonzalo Camarillo) Yes

(Spencer Dawkins) Yes

Comment (2013-05-28 for -03)
No email
send info
This is more for the RAI ADs than anything else (no action requested from the document authors).

In 2.  Security Considerations

   Advertising an endpoint's XMPP address over SIP could inform
   malicious entities about an alternative attack vector.  Because the
   "purpose" header field parameter could be spoofed, the receiving
   endpoint ought to check the value against an authoritative source
   such as a user directory.  Clients can integrity protect and encrypt
   this header field using end-to-end mechanisms such as S/MIME or hop-
   by-hop mechanisms such as TLS.

We're talking about a SIP client (with an XMPP address in a SIP header field parameter), is that right? Has S/MIME gotten much deployment to date? I know we didn't even mention S/MIME in SIPconnect 1.1 (,com_docman/task,doc_download/gid,476/Itemid,261/)

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Benoît Claise) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2013-05-31)
No email
send info
Thanks for considering my discuss point.


(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Comment (2013-05-30 for -03)
No email
send info
no objection on the basis of the revised id that will be coming

Barry Leiba No Objection

(Ted Lemon) No Objection

(Pete Resnick) (was Discuss) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2013-05-24 for -03)
No email
send info
Would there be other capabilities that you'd want to advertise?  Like here's my certificate?