Subject: Re: [Stox] AD evaluation: draft-ietf-stox-chat-08

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 02 Feb 2015 09:35:43 -0700

On 1/31/15 5:09 PM, Alissa Cooper wrote:

> = Section 7 = Is all of the delivery report behavior meant to be
> entirely optional to support, or should there be some normative
> requirements listed in this section?

IMHO this is entirely optional (as with Section 6).

> = Section 4 = "The XMPP-to-SIP gateway at the XMPP server would then
> initiate an MSRP session with Romeo on Juliet's behalf (since there
> is no reliable way for the gateway to determine if Romeo's client
> supports MSRP, it simply needs to guess).”
>
> “Guessing” makes it sound like the gateway might use heuristics or
> some such to determine whether to initiate an MSRP session, and that
> in some cases it might not initiate a session. Would it be more
> accurate to say that MSRP session initiation may yield an error since
> there is no reliable way for the gateway to determine if Romeo's
> client supports MSRP?

Yes, that's better.

Peter

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

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 9 Feb 2015 15:44:02 -0800

> IMHO this is entirely optional (as with Section 6).

I think the difference between Section 6 and Section 7 is that Section 6 at least gives a little narrative description of how to do the mapping for composing notifications, whereas in Section 7 there is no such description, it’s just illustrated by examples. So I would suggest adding a sentence or two that generically describes what the gateway in each direction should do to map an MSRP REPORT to an XMPP message receipt request/response and vice versa. This is obviously a small thing but seems like good practice. This can be dealt with during IETF LC.

Ben has sent comments on this draft and I’d like to see how that discussion resolves before issuing the IETF LC.

Thanks,
Alissa

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 11 Feb 2015 19:57:55 -0700

> I think the difference between Section 6 and Section 7 is that Section 6 at least gives a little narrative description of how to do the mapping for composing notifications, whereas in Section 7 the…

Yes, I see your point. Will add.

> Ben has sent comments on this draft and I’d like to see how that discussion resolves before issuing the IETF LC.

Agreed.

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 11 Feb 2015 20:13:22 -0700

On 2/11/15 7:57 PM, Peter Saint-Andre - &yet wrote:
>> I think the difference between Section 6 and Section 7 is that Section
>> 6 at least gives a little narrative description of how to do the
>> mapping for composing notifications, whereas in Section 7 there is no
>> such description, it’s just illustrated by examples. So I would
>> suggest adding a sentence or two that generically describes what the
>> gateway in each direction should do to map an MSRP REPORT to an XMPP
>> message receipt request/response and vice versa. This is obviously a
>> small thing but seems like good practice. This can be dealt with
>> during IETF LC.
>

Here is proposed text.

###

    An XMPP Message Receipts element of <request
    xmlns='urn:xmpp:receipts'/> is to be mapped to an MSRP Success-Report
    header field with a value of "yes", and an XMPP Message Receipts
    element of <received xmlns='urn:xmpp:receipts'/> is to be mapped to
    an MSRP REPORT request.

    A Success-Report header field with a value of "yes" in an MSRP SEND
    request is to be mapped to an XMPP Message Receipts element of
    <request xmlns='urn:xmpp:receipts'/>, and an MSRP REPORT request is
    to be mapped to an XMPP message containing only a Message Receipts
    element of <received xmlns='urn:xmpp:receipts'/>.

    There are no other suggested mappings (e.g., for the MSRP Failure-
    Report header field).

###

Peter

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

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 13 Feb 2015 15:06:14 -0800

>   There are no other suggested mappings (e.g., for the MSRP Failure-

Thanks, this looks good.
Alissa