Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
draft-ietf-xmpp-cpim-05
Yes
(Scott Hollenbeck)
(Ted Hardie)
No Objection
(Alex Zinin)
(Allison Mankin)
(Bill Fenner)
(David Kessens)
(Margaret Cullen)
(Steven Bellovin)
(Thomas Narten)
No Record
(Harald Alvestrand)
Note: This ballot was opened for revision 05 and is now closed.
Scott Hollenbeck Former IESG member
Yes
Yes
()
Unknown
Ted Hardie Former IESG member
(was Discuss)
Yes
Yes
()
Unknown
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
(2004-04-15)
Unknown
Reference:
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
Should probably be changed to:
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
(2004-04-15)
Unknown
It seems a little odd that the resource identifier mapping in 5.1.1 (mapping the XMPP resource identifier to the PIDF tuple ID) does not admit of any complementary reverse mapping in 5.2 from PIDF to XMPP. If the two are equivalent in one direction of the mapping, why not in both? The notes in 5.1.5 about the 'show' element refer to the example urn:ietf:params:xml:ns:pidf:im namespace from the PIDF document (as does 5.2.10). While there has been ongoing work to provide extended presence constructs like "away" and "dnd" and so on, it has not been in that namespace (the RPID work, for example, uses pidf:status:rpid-status). The text here strongly suggests that work on populating the pidf:im namespace is underway. It might be best to state that this is just an example, and that ns:pidf:im may or may not be populated in the future. It might be worth mentioning in Section 6.1 that some non-XMPP protocols have a concept of a limited-duration subscription that must be periodically refreshed. Accordingly, an XMPP-to-whatever gateway might be responsible for sending periodic refreshes to the non-XMPP side which have no corollary in the XMPP protocol. The reverse case (whatever-to-XMPP) is covered well by the last paragraph of Section 6.2.
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2004-04-12)
Unknown
Please delete section 1.4.
Steven Bellovin Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Thomas Narten Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
(was No Objection)
No Record
No Record
()
Unknown