Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
draft-ietf-xmpp-cpim-05

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
In section 3.3, the text has:

5.  Translate & to #26;, ' to #27;, and / to @2f respectively

shouldn't the final entry should be #2f?  This is the mapping given
above in XMPP to CPIM.

In section 4.9, the text has:

  If the charset is "US-ASCII" or "UTF-8", the gateway SHOULD map the
  "Message/CPIM" object; otherwise it SHOULD NOT.

The text above seems to imply that the mapping should be a MUST
if the charset is UTF-8 (since that mapping is pretty much the point of the gateway).
Why is it a SHOULD?

[Ballot discuss]
There are some ambiguities in the language.  In several sections (4.2.3, 4.2.4, and more), when talking about headers present in CPIM but not XMPP, the document says that a gateway "SHOULD NOT pass that information on".  What is the antecedent of "that information"?  The offending header?  The entire stanza?  Something else?

4.2.7 (and elswhere): The document says that the mandatory-to-recognize header should be ignored.  Does that mean that the gateway does not have to understand certain headers that have been flagged as mandatory?  What if a flagged header is one of those for which XMPP has no equivalent?  How is that handled?