Subject: [Stox] review of core, chat, groupchat and presence

From: Philipp Hancke <[email-masked]>
Date: Thu, 08 Aug 2013 20:33:40 +0200

I just noticed i reviewed -00 from the draft package... but anyway, 
quite a number of nits. Read them coming from XMPP land.

Comments prefixed with example of section number.
editorial comments:
- inconsistent usage of note. sometimes (Note: ...) other times (-im,
   presence) Note:
- chat and im prefix examples with '|'

chat:
     example f2: call-id: contain jid? how about uniqueness?.
	    Is there any text on the use of <thread/>?
	in -im @example.com callid is used
     	a=lang could be taken xml:lang?
     before example F4: the gateway acknowledges on behalf of juliet?

     example f5: the initial message in F1 should have an id
	attribute which gets mapped in f5. Does a786hjs2 map to
	thread/call id?

     example f6: shouldn't message-id should be different from f5?
         mapping of message-id to id attribute, should be randomly
	generated if not present

     section 4: sessinos -> sessions;

core:
     the draft says:
	     instant messaging and presence applications of XMPP also
	     need to support im: and pres: URIs
	     as specified in [RFC3860] and [RFC3859] respectively
	while this is encouraged in RFC 6121, those are informative
	references.

     4.2 bullet 1: ref to jid escaping xep here instead of in bullet 3
     5.1: <policy-violation/> is missing from the list.

groupchat:
     2: at least in RFC 6120, jid stands for jabber id, not jabber
	identifier.
     3.1: Room Nickname -> lowercase?
     3.1: example f2: conversion->conversation?
          table 1: thread<->call id
     3.2: example f7: possibly use by= on the error element?
	xep 0045 has the conflicting resource in the from
     3.4: "Occupant JID in another room" -- i don't think mediated
	invites work across different rooms.
         example f1: hecate is benvolio? c&p error from 0045
         example f2: contact [email-masked] has a wrong host?
         reeived -> received
         example f3 is not shown
         below f4 there is a sip/2.0 200 ok on its own?
     3.5: table 2: xmpp From/To -> from/to
         ex f9: where is juliets own presence in msrp?
         ex f11: where is juliets own presence with code 110?
         ex f14: mapping <message id/> to Message-ID
         	does msrp have a concept of room history?
     3.6.2: do we have an equivalent disco feature for muc?
     3.7: does xmpp still support the <status/> when in muc? In IRC this
	has caused PART spam
     4.1: ex f5: lack of error until when? must wait until receiving 110
	status?
     4.4: presence broadcast before ack? must buffer until receiving 110
	ack?
     4.5.1: use message id instead of guessing?

im:
     table 4: align tables accross documents and put normative version
	to -core.

pres:
     should mention different concepts, long-lived vs short-lived in
	intro, not only in 3.3.2
     3.1: im uri of the form <pres:>?
     3.3.1: if a subscription already exists -> already defined in 6121,
	not sure if this was in 3921 already
     4.3: table 7 CSeq <-> id?! consistency...

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Aug 2013 15:25:56 -0600

Hi Philipp, thanks for the review. I'm splitting up my replies for
easier tracking...

> - chat and im prefix examples with '|'

I'll review the documents for consistency, because I like consistency. :)

>     while this is encouraged in RFC 6121, those are informative

If I understand your comment correctly, you might agree with the
following change...

OLD
   The XMPP address format is specified in [RFC6122]; as discussed in
   [RFC6121], instant messaging and presence applications of XMPP also
   need to support 'im:' and 'pres:' URIs as specified in [RFC3860] and
   [RFC3859] respectively, although such support might simply involve
   leaving resolution of such addresses up to an XMPP server.

NEW
   The XMPP address format is specified in [RFC6122]; in addition,
   [RFC6121] encourages instant messaging and presence applications of
   XMPP to support 'im:' and 'pres:' URIs as specified in [RFC3860] and
   [RFC3859] respectively, although such support might simply involve
   leaving resolution of such addresses up to an XMPP server.

>     4.2 bullet 1: ref to jid escaping xep here instead of in bullet 3

It seems to me that the reference is appropriate in both places, so
adding it to bullet 1 seems reasonable.

>     5.1: <policy-violation/> is missing from the list.

Good catch. What SIP response code do you suggest mapping that to? The
best option I can see is "400 Bad Request".

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Aug 2013 15:54:49 -0600

>     should mention different concepts, long-lived vs short-lived in

Yes, Ben Campbell mentioned that during the WG session in Berlin, too. I
propose adding the following paragraph to the introduction:

   SIP and XMPP differ significantly in their presence subscription
   models, since SIP subscriptions are short-lived (requiring relatively
   frequent refreshes even during a presence session) whereas XMPP
   subscriptions last across presence sessions until they are explicitly
   cancelled.  This document provides suggestions for bridging the gap
   between these very different models.

>     3.1: im uri of the form <pres:>?

Copy and paste error. Will fix.

>     not sure if this was in 3921 already

RFC 3921 said:

   However, if the user receives a presence stanza of type
   "subscribe" from a contact to whom the user has already granted
   permission to see the user's presence information (e.g., in cases
   when the contact is seeking to resynchronize subscription states),
   the user's server SHOULD auto-reply on behalf of the user.

I suspect that RFC 6121 goes into more detail about that scenario, since
it goes into more detail about everything. ;-)

>     4.3: table 7 CSeq <-> id?! consistency...

That was fixed in -01.

Thanks for the feedback!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 16 Aug 2013 10:00:39 +0200

Hi Philip,

Thanks for the feedback, I hope to look into these issues over the weekend and either make changes or come back with more questions :-)

--
Saúl Ibarra Corretgé
AG Projects