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

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Sep 2013 21:53:04 -0600

On 8/8/13 12:33 PM, Philipp Hancke wrote:

> 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;

Sorry, I neglected to incorporate this feedback into version -01. I'll
do that for -02.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 19 Sep 2013 10:46:59 -0600

Philipp, thanks for the review. Comments inline.

On 9/18/13 9:53 PM, Peter Saint-Andre wrote:
>> chat: example f2: call-id: contain jid? how about uniqueness?.

Yes, RFC 3261 says they need to be unique:

   In a new request created by a UAC outside of any dialog, the Call-ID
   header field MUST be selected by the UAC as a globally unique
   identifier over space and time unless overridden by method-specific
   behavior.  All SIP UAs must have a means to guarantee that the Call-
   ID header fields they produce will not be inadvertently generated by
   any other UA.

I was unthinkingly following the examples in specs like RFC 4975. I'll
change them to be UUIDs.

>> Is there any text on the use of <thread/>?

There is text about this in draft-ietf-stox-im, which says to map
Call-ID to <thread/> and vice-versa. However, that probably belongs in
the -chat document, since thread isn't really used in pager-mode
single messages.

>> in -im @example.com callid is used

As mentioned, I'll make them UUIDs.

>> a=lang could be taken xml:lang?

In the -im I-D we map xml:lang to the Content-Language header. I think
that's more appropriate than a=lang, which has some subtleties I'd
prefer to avoid -- see draft-gellens-mmusic-negotiating-human-language
for some related considerations.

>> before example F4: the gateway acknowledges on behalf of juliet?

Yours was a very brief comment and I'm not sure I understand the force
of your question. Are you wondering why there's an ACK at this point
in the negotiation? That's what I see in RFC 4975:

           Alice                     Bob
             |                        |
             |                        |
             |(1) (SIP) INVITE        |
             |----------------------->|
             |(2) (SIP) 200 OK        |
             |<-----------------------|
             |(3) (SIP) ACK           |
             |----------------------->|
             |(4) (MSRP) SEND         |
             |----------------------->|

>> example f5: the initial message in F1 should have an id

Agreed.

>> which gets mapped in f5. Does a786hjs2 map to thread/call id?

That's an MSRP transaction identifier, which IMHO maps to a stanza
'id' attribute in XMPP. This too needs to be documented in the -chat I-D.

>> example f6: shouldn't message-id should be different from f5?

Yes, I think so, because that's a different transaction.

>> mapping of message-id to id attribute, should be randomly
>> generated if not present

Hmm. In MSRP, the message-id can be used to identify an overall
message, which might be chunked into separate transactions. XMPP
doesn't have the concept of a message in the MSRP sense when we're
talking about IM. In XMPP, In-Band Bytestreams (XEP-0047) enables you
to chunk a large piece of data into smaller pieces, but that's used
only for file transfer, not for IM. We could add a note about this in
the -chat I-D, but for IM purposes I think we don't want to map the
MSRP message-id to anything on the XMPP side.

>> section 4: sessinos -> sessions;

Yes, my fingers often make that mistake while typing. :-)

Peter

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

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 19 Sep 2013 19:13:29 +0200

Am 19.09.2013 18:46, schrieb Peter Saint-Andre:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Stuff that is done removed. Thanks for addressing the issues.

[...]
> I was unthinkingly following the examples in specs like RFC 4975. I'll

I think what I mean was "the call id should be something along the lines 
of 711609sa.juliet.example.com". The intent was the same however.

[...]
> in the negotiation? That's what I see in RFC 4975:

What I meant (and i needed to parse this again, too) was that I think 
the gateway acknowledges on behalf of Juliet, not Romeo as the text 
says. The example itself is ok.

philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 22 Sep 2013 22:12:18 -0600

Thanks again for the review. Comments inline.

On 8/8/13 12:33 PM, Philipp Hancke wrote:

> groupchat: 2: at least in RFC 6120, jid stands for jabber id, not
> jabber identifier.

Correct. Will fix.

> 3.1: Room Nickname -> lowercase?

Sure.

> 3.1: example f2: conversion->conversation?

More like conversion->mapping :-)

BTW in the -chat spec I numbered all the examples sequentially, and
I'll start doing that here too.

> table 1: thread<->call id

Yes.

> 3.2: example f7: possibly use by= on the error element?

Sure, by=[email-masked]' seems good.

> xep 0045 has the conflicting resource in the from

Correct. Will fix.

> 3.4: "Occupant JID in another room" -- i don't think mediated 
> invites work across different rooms.

Section 7.8.2 of XEP-0045 states in part:

###

It may be wondered why the invitee does not send the decline message
directly to the inviter. The main reason is that certain
implementations might choose to base invitations on occupant JIDs
rather than bare JIDs (so that, for example, an occupant could invite
someone from one room to another without knowing that person's bare
JID). Thus the service needs to handle both the invites and declines.

###

However, I'm not sure how widely that feature is implemented.

> example f1: hecate is benvolio? c&p error from 0045

Will fix.

> example f2: contact [email-masked] has a wrong host?

You are right.

> reeived -> received

Yes.

> example f3 is not shown

I don't feel that we need to show every 200 OK. Yes, we put the
example in example.com, but sometimes you really can have too many
examples. :-)

> below f4 there is a sip/2.0 200 ok on its own?

Will fix.

> 3.5: table 2: xmpp From/To -> from/to

Will fix.

> ex f9: where is juliets own presence in msrp?

Good catch. Will fix.

> ex f11: where is juliets own presence with code 110?

Will fix.

> ex f14: mapping <message id/> to Message-ID does msrp have a
> concept of room history?

I'm not sure.

> 3.6.2: do we have an equivalent disco feature for muc?

No, it's assumed by support for 'http://jabber.org/protocol/muc'.

> 3.7: does xmpp still support the <status/> when in muc? In IRC
> this has caused PART spam

Yes:

http://xmpp.org/extensions/xep-0045.html#changepres

> 4.1: ex f5: lack of error until when? must wait until receiving
> 110 status?

We might way "within a reasonable amount of time, such as 5 seconds".

> 4.4: presence broadcast before ack? must buffer until receiving
> 110 ack?

Your comment is a bit cryptic. Would you please expand it?

> 4.5.1: use message id instead of guessing?

Good idea.

Thanks for the feedback!

Peter

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

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 23 Sep 2013 07:57:48 +0200

> Thanks again for the review. Comments inline.

As before, removing items done.

new nit: [length] looks like it should be replaced with the examples 
actual length in three places. Only seen in -groupchat.

[...]
> example in example.com, but sometimes you really can have too many

Right. But then it might make sense to either add a "not shown" marker 
in the ascii art or not number them. I'll check if that happens often 
enough to make sense.

[...]
> Your comment is a bit cryptic. Would you please expand it?

Hah, that was the only comment you found cryptic? :-)

btw: it might make sense to reuse the caption from XEP-0045 (7.2.3 
Presence Broadcast) for the caption of F7 (which is raw, unbridled xmpp 
and not translated; current text seems copy-paste from F11 in sect 3.5):
  "Service Sends Presence from Existing Occupants to New Occupant"

Now the attempt to decipher my comments:
First part:
In MUC, the participant lists is sent to the new occupant (muc example 
21) before the new occupants own presence (muc  example 24) and 
therefore potentially before any acknowledgements that might be required 
on the MSRP side. Is that a problem?

Second part:
In example F10, two (or more) stanzas are translated into a single 
event. Unless you can do partial updates (Emil? I think you mentioned 
such a thing for COIN) here, the gateway needs to know when it can 
dispatch example 4.4 -- upon receiving the participants own presence, 
which might come with a 110 status code. Since I don't think all xmpp 
serveers do 110, i think there is some text required that the gateway 
needs to be able to recognize the self-presence and not mistake it as 
part of the participants list.
(should it be participant_s_ presence in the caption?)

Is that clearer?

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 23 Sep 2013 18:25:31 -0600

On 9/22/13 11:57 PM, Philipp Hancke wrote:
> new nit: [length] looks like it should be replaced with the
> examples actual length in three places. Only seen in -groupchat.

Will fix.

>> example in example.com, but sometimes you really can have too
>> many examples. :-)
> 
> Right. But then it might make sense to either add a "not shown"
> marker in the ascii art or not number them. I'll check if that
> happens often enough to make sense.

Well, maybe we'll just add the examples for the sake of completeness.

> [...]
>>> 4.4: presence broadcast before ack? must buffer until
>>> receiving 110 ack?
>> 

I think that I managed to decryptify the others. ;-)

> Presence Broadcast) for the caption of F7 (which is raw, unbridled
> xmpp and not translated; current text seems copy-paste from F11 in
> sect 3.5): "Service Sends Presence from Existing Occupants to New
> Occupant"

WFM.

> Now the attempt to decipher my comments: First part: In MUC, the
> participant lists is sent to the new occupant (muc example 21)
> before the new occupants own presence (muc  example 24) and 
> therefore potentially before any acknowledgements that might be
> required on the MSRP side. Is that a problem?

Well, neither RFC 4975 nor draft-ietf-simple-chat really specifies the
handling of participant lists. There is a passing mention in the
latter document, but it's not very detailed:

   Typically the conference focus acts as a notifier of the conference
   event package, RFC 4575 [RFC4575].  It is RECOMMENDED that conference
   foci and endpoints support RFC 6502 [RFC6502] for providing
   information regarding the conference, and in particular, supplying
   information of the roaster of the conference.  It is also RECOMMENDED
   that conference foci and endpoints support RFC 6501 [RFC6501], which
   extends the <user> element originally specified in RFC 4575 [RFC4575]
   with a new 'nickname' attribute.  This allows endpoints to learn the
   nicknames of participants of the chat room.

However, in draft-ietf-stox-groupchat we assume that the conference
focus does support the conference-info package for the room roster.

[ Hopefully the RFC Editor will correct "roaster" to "roster" :-) ]

> Second part: In example F10, two (or more) stanzas are translated
> into a single event. Unless you can do partial updates (Emil? I
> think you mentioned such a thing for COIN) here, the gateway needs
> to know when it can dispatch example 4.4 -- upon receiving the
> participants own presence, which might come with a 110 status code.
> 
That's all correct.

> Since I don't think all xmpp serveers do 110, i think there is some
> text required that the gateway needs to be able to recognize the
> self-presence and not mistake it as part of the participants list. 

The SIP-to-XMPP gateway will need to maintain state about the MSRP
session that the SIP user agent has requested. This implies that the
gateway will need to know the user's SIP URI and the mapping of that
URI into an XMPP address, then based on that mapping determine when it
has received a complete room roster from the MUC room (with or without
a 110 status code), i.e., when it has received the in-room presence of
the SIP user (which according to XEP-0045 is the last presence stanza
received in the initial batch sent after joining). Once that happens,
the SIP-to-XMPP gateway can construct the conference-info document
containg the complete room roster and send that to the SIP user.

And yes, we need to make that clear in the spec.

> Is that clearer?

Yes, thanks.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 24 Sep 2013 20:23:57 -0600

On 9/23/13 6:25 PM, Peter Saint-Andre wrote:
>> btw: it might make sense to reuse the caption from XEP-0045
>> (7.2.3 Presence Broadcast) for the caption of F7 (which is raw,
>> unbridled xmpp and not translated; current text seems copy-paste
>> from F11 in sect 3.5): "Service Sends Presence from Existing
>> Occupants to New Occupant"
> 
> WFM.
> 
> Well, neither RFC 4975 nor draft-ietf-simple-chat really specifies
> the handling of participant lists. There is a passing mention in
> the latter document, but it's not very detailed:
> 
> Typically the conference focus acts as a notifier of the
> conference event package, RFC 4575 [RFC4575].  It is RECOMMENDED
> that conference foci and endpoints support RFC 6502 [RFC6502] for
> providing information regarding the conference, and in particular,
> supplying information of the roaster of the conference.  It is also
> RECOMMENDED that conference foci and endpoints support RFC 6501
> [RFC6501], which extends the <user> element originally specified in
> RFC 4575 [RFC4575] with a new 'nickname' attribute.  This allows
> endpoints to learn the nicknames of participants of the chat room.
> 
> However, in draft-ietf-stox-groupchat we assume that the
> conference focus does support the conference-info package for the
> room roster.
> 
>> Second part: In example F10, two (or more) stanzas are
>> translated into a single event. Unless you can do partial updates
>> (Emil? I think you mentioned such a thing for COIN) here, the
>> gateway needs to know when it can dispatch example 4.4 -- upon
>> receiving the participants own presence, which might come with a
>> 110 status code.
> 
> That's all correct.
> 
>> Since I don't think all xmpp serveers do 110, i think there is
>> some text required that the gateway needs to be able to recognize
>> the self-presence and not mistake it as part of the participants
>> list. (should it be participant_s_ presence in the caption?)
> 
> session that the SIP user agent has requested. This implies that
> the gateway will need to know the user's SIP URI and the mapping of
> that URI into an XMPP address, then based on that mapping determine
> when it has received a complete room roster from the MUC room (with
> or without a 110 status code), i.e., when it has received the
> in-room presence of the SIP user (which according to XEP-0045 is
> the last presence stanza received in the initial batch sent after
> joining). Once that happens, the SIP-to-XMPP gateway can construct
> the conference-info document containg the complete room roster and
> send that to the SIP user.
> 

Here is proposed text:

   Because the "room roster" is communicated in XMPP by means of
   multiple presence stanzas (one for each participant) whereas the
   participant list is communicated in SIP by means of a single
   conference-info document, the SIP-to-XMPP gateway will need to keep
   track of the user's SIP URI and the mapping of that URI into an XMPP
   address; then, based on that mapping, it will need to determine when
   it has received a complete room roster from the MUC room, i.e., when
   it has received the in-room presence of the SIP user (which according
   to XEP-0045 is the last presence stanza received in the initial batch
   sent after joining).  Once that happens, the SIP-to-XMPP gateway can
   construct the conference-info document containing the complete room
   roster and send that to the SIP user.

Peter

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

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 30 Sep 2013 16:12:26 +0200 (CEST)

> Well, maybe we'll just add the examples for the sake of completeness.

humm, just noticed that -groupchat is odd here while checking this.
X4 is called ACK in both the diagram and example 4 (and is a sip ack)
whereas the S3 ACK in the diagram is a 200 in example 28.
I think it should be ACK in example 28.

I think not numbering things that are not shown (e.g. S2) would be 
consistent.