Subject: [Stox] Stephen Farrell's No Objection on draft-ietf-stox-chat-10: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 03 Mar 2015 12:42:28 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-stox-chat-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-stox-chat/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- OTR works for xmpp. I think (not sure) it could be made
work for MSRP or SIMPLE, and presumably then it might work
here. If that's true, be good to note that and explain a bit
how to do that. (And I don't mean the long-promised OTR I-D,
just a pointer at the inevitably bad best reference we can
find.)

- End of p12: "are suggested" is odd to see in an RFC, it
might be better if you find some other wording.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 4 Mar 2015 14:34:27 +0100

> might be better if you find some other wording.

Why odd?  This doesn't affect interoperability, but somewhat affects
user experience.  If I were implementing this, I would follow the
suggestion.  If it turned out to be too hard, in my implementation, to
do that, I'd do something else.  "We suggest these" seems exactly
right here.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 4 Mar 2015 14:34:27 +0100

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Mar 2015 15:11:58 +0000

> do that, I'd do something else.  "We suggest these" seems exactly

I've lost context, but iirc it says "here's a thing, we suggest
you do it, or maybe not" and gives no further guidance. If so,
that reads oddly but I'd have to go check and can't juts now.
It's fine to skip if I'm wrong.

S

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Mar 2015 15:11:58 +0000

S

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 04 Mar 2015 16:52:18 -0700

> http://datatracker.ietf.org/doc/draft-ietf-stox-chat/

Yes, we might do that in all three of these specs (or, as Barry 
suggests, mention it in the -im spec and point there from the others).

> might be better if you find some other wording.

I tend to agree with Barry that this is a UX thing, not a true interop 
thing.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 04 Mar 2015 16:52:18 -0700

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 05 Mar 2015 14:47:09 -0700

> suggests, mention it in the -im spec and point there from the others).

Here is proposed / updated text for the -im document, to which we can 
point from the -chat document:

    This document specifies methods for exchanging "page-mode" instant
    messages through a gateway that translates between SIP and XMPP, and
    [I-D.ietf-stox-chat] specifies such methods for "session-mode"
    instant messaging between MSRP and XMPP.  Such a gateway MUST be
    compliant with the minimum security requirements of the textual chat
    protocols for which it translates (i.e., SIP or MSRP and XMPP).

    The addition of gateways to the security model of instant messaging
    specified in [RFC2779] introduces some new risks.  In particular,
    end-to-end security properties (especially confidentiality and
    integrity) between instant messaging clients that interface through a
    gateway can be provided only if common formats are supported.
    Specification of those common formats is out of scope for this
    document.  For instant messages, it is possible to use [RFC3862] and
    [RFC3923], but those methods are not widely implemented.  A more
    widely implemented albeit unstandardized method for interoperable
    end-to-end encryption would be Off-the-Record Messaging [OTR].

Peter

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Mar 2015 10:44:24 +0000

On 05/03/15 21:47, Peter Saint-Andre wrote:
> For instant messages, it is possible to use [RFC3862] and

I like that but just to check - what you're calling IM here
does work with OTR, right? OTR requires an e2e roundtrip and
IM otherwise seemed to be more fire-and-forget, at least e2e.
So is there a possible terminology glitch?

Put another way - I know that OTR will work, but there'll now
be a few messages at least to do the handshake and not just
the one, so are we actually doing a chat session and not an
IM at that point?

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Mar 2015 10:44:24 +0000

Cheers,
S.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 06 Mar 2015 09:58:27 -0700

> the one, so are we actually doing a chat session and not an

OTR doesn't care about the underlying messaging technology, since it 
treats them all as dumb transports. So yes, in OTR terms I suppose you'd 
say there is a session of some kind, but in SIP / RFC 3428 terms it's 
just a series of single instant messages ("page mode" IM), not a 
formally negotiated chat session ("session mode" IM) as happens in MSRP 
/ RFC 4975.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 06 Mar 2015 09:58:27 -0700

Peter

-- 
Peter Saint-Andre
https://andyet.com/