Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
draft-ietf-xmpp-im-22

[Note]: 'Returning to telechat to review proposed changes.  Note that changes to meet Allison''s discuss may have deployment consequences, so a quick security re-review is in order.' added by Scott Hollenbeck

[Ballot comment]
I clarified my Discuss in a telephone call with the editor and chairs after Lisa asked if it was enough that xmpp-im was normatively dependent on xmpp-e2e and that was normatively dependent on xmpp-cpim (which showed my Discuss was circumspect!).

Goal:  that a stanza can contain a form other than a JID and that this can signify either that the destination server is a gateway (viz xmpp-cpim), or a server in the xmpp realm whose url is im:user@domain or whose presence is pres:user@domain.  Allowing this may mean allowing simplification of gateway urls, instead of complex piggybacked ones per pair of technology domains.  And it allows a lot of other of the intended uses of im: and pres:  The editor introduced changes in Section 11.2 Outbound Stanzas to address my clarified Discuss, and I cleared it on this basis.

[Note]: 'Returning to telechat to review proposed changes.  Note that changes to meet Allison''s discuss may have deployment consequences, so a quick security re-review is in order.' added by Ted Hardie

[Ballot discuss]
Recent developments of major IM gateways (Reuters-MSMessenger, Reuters-AIM), based on simple, underline the relevance of interoperability extensions in the IM protocols using the cpim specifications (these gateways are proprietary, only because the IETF specs were not  settled yet).  The cpim specs include the pidf, msgfmt and cpim bodies, and the im: and pres: uri's.  In xmpp, the choice was made to support all of these through a specification of a gateway that can map between xmpp and cpim, and nothing is said in the xmpp-im spec about the existence of such gateways or their potential signficance.  A strong expectation is that im: and pres: should be used more generally than at mapping gateways, for instance, a business card with pres:user@example.com could resolve to one's presence supported by xmpp, simple or an ongoing h323 conference.  A detachment of the main xmpp-im spec from pres: and im: has the consequence of leaving xmpp out of this, and is worrisome.  If the xmpp-im spec included the cpim spec normatively, it would be possible to debate this further before closing down the im spec permanently.  About the detachment of the xmpp-im spec from pidf, msgfmt and cpim:  the effect is to have the gatewaying/interoperability function called for by the charter be non-mandatory to implement, since im is decoupled from its interoperability features.  There should be a discussion in the document about interoperability design, pointing forward to the other document.  Among other points, it can disillusion an informed reader who might expect that the presence 'types' would include one which was a reference to a pidf body (this would have certainly allowed for
better mapping between IM capabilities, and also would permit xmpp to track the use of pidf for the geopriv presence object).  Summing up, from such a forward-pointing section, the document needs to make the xmpp-cpim specification normative.  This leaves the im:, pres:discussion open, and strengthens the future of gatewaying.

If the document moderates its statement that it fulfils all* the requirements of RFC2779, it would be ok not to make the xmpp-e2e spec normative.

About resources and subscriptions -  the relation among the subscription, the roster push and the authorization is written in a way that needs a lot of interpreting and reading back and forth.  Subscription is authorized based on the bare JIDs (according to core), but the the subscriptions and roster pushes are to particular resources (all resources that request).  Is this the right interpretation?  It is hard to read.

[Ballot discuss]
1.5    ipr notice not conformant -- see my comments on the core protocol

3:      (discussion of conflicting sessions)
        my knowledge of xml is slight, but I thought that having
        two  tags for one  was forbidden.  If
        the stream: denotes different tags, one is missing a start tag.

        For that matter, that stanza doesn't start  and the
        next one does -- isn't that wrong?  Why are the two inconsistent?

5:      "If the user's server receives a presence stanza of type "error" in"
        Is there any equivalent to "probing a closed window"?  I.e., a
        transient connectivity problem may block the remote server from
        sending a presence probe.

general I'm disturbed by the possibility -- the probability? -- of two servers'
        state for a particular subscription getting out of sync.  How is this
        detected?  Recovered from?  The MUST/MUST NOT rules that prevent
        superfluous transmission of subscribe[d]/unsubscribe[d] messages
        would seem to prevent attempts to resynchronize.  (I noticed that
        the jabber client I use has options to resend authorization to/from
        messages.  I wonder if that's compliant.)