From rjsparks@nostrum.com  Tue Dec  3 12:14:30 2013
Return-Path: <rjsparks@nostrum.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F661AE0E0; Tue,  3 Dec 2013 12:14:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.035
X-Spam-Level: 
X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swrJGEEGRgNy; Tue,  3 Dec 2013 12:14:28 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE421AE0D6; Tue,  3 Dec 2013 12:14:28 -0800 (PST)
Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3KEPWW034676 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Tue, 3 Dec 2013 14:14:25 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <529E3BA1.1010606@nostrum.com>
Date: Tue, 03 Dec 2013 14:14:25 -0600
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: ietf@ietf.org
References: <20131127124920.17385.35362.idtracker@ietfa.amsl.com>
In-Reply-To: <20131127124920.17385.35362.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------090607010300090202060101"
Received-SPF: pass (shaman.nostrum.com: 173.71.10.88 is authenticated by a trusted mechanism)
Cc: stox@ietf.org
Subject: Re: [Stox] Last Call: <draft-ietf-stox-core-07.txt> (Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling) to Proposed Standard
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 20:14:30 -0000

This is a multi-part message in MIME format.
--------------090607010300090202060101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

With many apologies to Peter and to the STOX WG for the timing of this:

I still think there's a couple of small problems with the treatment of 
translation into and out of 503.

The first is that we left folks without guidance if they're handling 
translating a SIP response into an XMPP
response in this case - the document's rather silent about that 
direction in the note in section 6.1.
Should they translate a 503 into a <internal-server-error/> as for 
unknown 5xx-class responses?
There's a similar issue with 402 - the pointer to note 1 says 
<payment-required/> no longer exists, but
doesn't give us anything to map a 402 into. is <bad-request/> (the 
unknown 4xx mapping) ok?

The second is a nit with the text in the note in section 6.1. It 
currently says " the SIP 503 response
code will be interpreted as applying to the entire domain, not only the 
specific user". That's not
quite right, and it's important to get this right since we're leaving it 
mostly to the gateway designer
to guess at what to do. The 503 talks about the element that returned 
it, not anything in the request,
so while it's right that it's not only talking about a specific user, 
it's not right to say it's talking about
an entire domain (and while that entire domain would be affected _at 
this element_, it's more than that -
_ANY_ domain's resource routed to this element will not be handled by 
this element until the condition
that led to the 503 goes away). I suggest saying this instead: "the SIP 
503 response code will be interpreted
as applying to all future requests to this server, not just requests for 
the specific user".

I also whipped up some bad python to look at what round-tripping an 
errror from XMPP->SIP->XMPP and
vice-versa looked like as a sanity check (which brought the 503 and 402 
issues in the first item above to
my attention). Here's the result. Please look over them and see if any 
of them are surprising or unacceptable.
(They are easier to read in a fixed-width font).

I'm particularly suspicious of subscription-required -> 
registration-required and of 301 -> 410.


XMPP -> SIP -> XMPP
bad-request              -> bad-request
conflict                 -> bad-request
feature-not-implemented  -> feature-not-implemented
forbidden                -> policy-violation, forbidden, 
recipient-unavailable, not-allowed
gone                     -> gone
internal-server-error    -> internal-server-error
item-not-found           -> item-not-found, remote-server-not-found
jid-malformed            -> bad-request
not-acceptable           -> not-acceptable
not-allowed              -> policy-violation, forbidden, not-allowed
not-authorized           -> not-authorized
policy-violation         -> policy-violation, forbidden, not-allowed
recipient-unavailable    -> recipient-unavailable
redirect                 -> redirect
registration-required    -> registration-required
remote-server-not-found  -> remote-server-timeout, item-not-found, 
remote-server-not-found
remote-server-timeout    -> remote-server-timeout, remote-server-not-found
resource-constraint      -> internal-server-error
service-unavailable      -> policy-violation, forbidden, 
feature-not-implemented, not-allowed
subscription-required    -> registration-required
undefined-condition      -> bad-request
unexpected-request       -> bad-request, unexpected-request

SIP -> XMPP -> SIP
300 -> 302
301 -> 410
302 -> 302
305 -> 302
380 -> 606, 406
400 -> 400
401 -> 401
402 -> UNDEFINED
403 -> 603, 403
404 -> 408, 604, 404
405 -> 405, 501
406 -> 606, 406
407 -> 407
408 -> 408, 404
410 -> 410
413 -> 403
414 -> 403
415 -> 606, 406
416 -> 606, 406
420 -> 405, 501
421 -> 606, 406
423 -> 500
430 -> 480, 600
439 -> 405, 501
440 -> 403
480 -> 480, 600
481 -> 604, 404
482 -> 606, 406
483 -> 606, 406
484 -> 604, 404
485 -> 604, 404
486 -> 480, 600
487 -> 480, 600
488 -> 606, 406
489 -> 403
491 -> 400, 491
493 -> 400
500 -> 500
501 -> 405, 501
502 -> 408, 404
503 -> UNDEFINED
504 -> 408
505 -> 606, 406
513 -> 403
600 -> 480, 600
603 -> 480, 600
604 -> 604, 404
606 -> 606, 406


RjS

--------------090607010300090202060101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    With many apologies to Peter and to the STOX WG for the timing of
    this:<br>
    <br>
    I still think there's a couple of small problems with the treatment
    of translation into and out of 503.<br>
    <br>
    The first is that we left folks without guidance if they're handling
    translating a SIP response into an XMPP<br>
    response in this case - the document's rather silent about that
    direction in the note in section 6.1.<br>
    Should they translate a 503 into a &lt;internal-server-error/&gt; as
    for unknown 5xx-class responses?<br>
    There's a similar issue with 402 - the pointer to note 1 says
    &lt;payment-required/&gt; no longer exists, but<br>
    doesn't give us anything to map a 402 into. is &lt;bad-request/&gt;
    (the unknown 4xx mapping) ok?<br>
    <br>
    The second is a nit with the text in the note in section 6.1. It
    currently says "
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    the SIP 503 response<br>
    code will be interpreted as applying to the entire domain, not only
    the specific user". That's not<br>
    quite right, and it's important to get this right since we're
    leaving it mostly to the gateway designer<br>
    to guess at what to do. The 503 talks about the element that
    returned it, not anything in the request,<br>
    so while it's right that it's not only talking about a specific user,
    it's not right to say it's talking about<br>
    an entire domain (and while that entire domain would be affected _at
    this element_, it's more than that -<br>
    _ANY_ domain's resource routed to this element will not be handled
    by this element until the condition<br>
    that led to the 503 goes away). I suggest saying this instead: "the
    SIP 503 response code will be interpreted<br>
    as applying to all future requests to this server, not just requests
    for the specific user".<br>
    <br>
    I also whipped up some bad python to look at what round-tripping an
    errror from XMPP-&gt;SIP-&gt;XMPP and<br>
    vice-versa looked like as a sanity check (which brought the 503 and
    402 issues in the first item above to<br>
    my attention). Here's the result. Please look over them and see if
    any of them are surprising or unacceptable.<br>
    (They are easier to read in a fixed-width font).<br>
    <br>
    I'm particularly suspicious of subscription-required -&gt;
    registration-required and of 301 -&gt; 410.<br>
    <br>
    <br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    XMPP -&gt; SIP -&gt; XMPP<br>
    bad-request&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; bad-request<br>
    conflict&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; bad-request<br>
    feature-not-implemented&nbsp; -&gt; feature-not-implemented<br>
    forbidden&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; policy-violation, forbidden,
    recipient-unavailable, not-allowed<br>
    gone&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; gone<br>
    internal-server-error&nbsp;&nbsp;&nbsp; -&gt; internal-server-error<br>
    item-not-found&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; item-not-found,
    remote-server-not-found<br>
    jid-malformed&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; bad-request<br>
    not-acceptable&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; not-acceptable<br>
    not-allowed&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; policy-violation, forbidden,
    not-allowed<br>
    not-authorized&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; not-authorized<br>
    policy-violation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; policy-violation, forbidden,
    not-allowed<br>
    recipient-unavailable&nbsp;&nbsp;&nbsp; -&gt; recipient-unavailable<br>
    redirect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; redirect<br>
    registration-required&nbsp;&nbsp;&nbsp; -&gt; registration-required<br>
    remote-server-not-found&nbsp; -&gt; remote-server-timeout,
    item-not-found, remote-server-not-found<br>
    remote-server-timeout&nbsp;&nbsp;&nbsp; -&gt; remote-server-timeout,
    remote-server-not-found<br>
    resource-constraint&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; internal-server-error<br>
    service-unavailable&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; policy-violation, forbidden,
    feature-not-implemented, not-allowed<br>
    subscription-required&nbsp;&nbsp;&nbsp; -&gt; registration-required<br>
    undefined-condition&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; bad-request<br>
    unexpected-request&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; bad-request, unexpected-request<br>
    <br>
    SIP -&gt; XMPP -&gt; SIP<br>
    300 -&gt; 302<br>
    301 -&gt; 410<br>
    302 -&gt; 302<br>
    305 -&gt; 302<br>
    380 -&gt; 606, 406<br>
    400 -&gt; 400<br>
    401 -&gt; 401<br>
    402 -&gt; UNDEFINED<br>
    403 -&gt; 603, 403<br>
    404 -&gt; 408, 604, 404<br>
    405 -&gt; 405, 501<br>
    406 -&gt; 606, 406<br>
    407 -&gt; 407<br>
    408 -&gt; 408, 404<br>
    410 -&gt; 410<br>
    413 -&gt; 403<br>
    414 -&gt; 403<br>
    415 -&gt; 606, 406<br>
    416 -&gt; 606, 406<br>
    420 -&gt; 405, 501<br>
    421 -&gt; 606, 406<br>
    423 -&gt; 500<br>
    430 -&gt; 480, 600<br>
    439 -&gt; 405, 501<br>
    440 -&gt; 403<br>
    480 -&gt; 480, 600<br>
    481 -&gt; 604, 404<br>
    482 -&gt; 606, 406<br>
    483 -&gt; 606, 406<br>
    484 -&gt; 604, 404<br>
    485 -&gt; 604, 404<br>
    486 -&gt; 480, 600<br>
    487 -&gt; 480, 600<br>
    488 -&gt; 606, 406<br>
    489 -&gt; 403<br>
    491 -&gt; 400, 491<br>
    493 -&gt; 400<br>
    500 -&gt; 500<br>
    501 -&gt; 405, 501<br>
    502 -&gt; 408, 404<br>
    503 -&gt; UNDEFINED<br>
    504 -&gt; 408<br>
    505 -&gt; 606, 406<br>
    513 -&gt; 403<br>
    600 -&gt; 480, 600<br>
    603 -&gt; 480, 600<br>
    604 -&gt; 604, 404<br>
    606 -&gt; 606, 406<br>
    <br>
    <br>
    RjS<br>
  </body>
</html>

--------------090607010300090202060101--

From yana@sip-communicator.org  Wed Dec  4 05:17:34 2013
Return-Path: <yana@sip-communicator.org>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A741AE08B for <stox@ietfa.amsl.com>; Wed,  4 Dec 2013 05:17:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSrbS89uiK2P for <stox@ietfa.amsl.com>; Wed,  4 Dec 2013 05:17:31 -0800 (PST)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9C24B1AE061 for <stox@ietf.org>; Wed,  4 Dec 2013 05:17:31 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id hq4so7934630wib.1 for <stox@ietf.org>; Wed, 04 Dec 2013 05:17:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=MbGAlJHHWZnT3KmVA3gIYxEEEOPScRmovCU7SbL6E+c=; b=Eah1eVIFhrripi7N7dLvrk0UlV7RsoYLpqj8dQH7/5zExuo3wJ5RHWPtalUKbFbvn7 zCv7ZY5+r64qMnArc+LSVmfAJ8Fa2plCQZ6msSo3CyNqgEEvxyhfhIjPbtFlpGUM/R1L SNOwCCu4gS748BurvYZm7JeZy1w/P5vifmBCI31iv+ezRi3ovFECheakYqDN7CNHYvkF MnuoKSSIJk5q+u2FnLg//st657mpXfSnQcV/gcWrQHAlXJNh8s4CtLaLllN2EhC+hKTc 4fi5eiyxeCoPVYAms2c1cv9beIFhE6wTkrVlwiJfh+/rx9g2lf3g36jzVGMfMNHZCzlw U4Bw==
X-Gm-Message-State: ALoCoQnyIz409i6HZ6jZjmFnI4dZW5aNcYRDHMPKyslM6cOdEDbTRVSfdxM8bJ+ZFojoACMRMu4o
X-Received: by 10.194.171.34 with SMTP id ar2mr2023289wjc.81.1386163048090; Wed, 04 Dec 2013 05:17:28 -0800 (PST)
Received: from [192.168.1.31] (neu67-4-88-160-65-79.fbx.proxad.net. [88.160.65.79]) by mx.google.com with ESMTPSA id n6sm6912415wix.3.2013.12.04.05.17.26 for <stox@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 05:17:27 -0800 (PST)
From: Yana Stamcheva <yana@jitsi.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <648368DC-1BD5-4D6A-B4E0-3D72B2EB3A6D@jitsi.org>
Date: Wed, 4 Dec 2013 14:17:24 +0100
To: stox@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
X-Mailer: Apple Mail (2.1822)
Subject: [Stox] Reminder WGLC on -im and -chat
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Dec 2013 13:17:34 -0000

This is a reminder for the WGLC on:

draft-ietf-stox-im-05 : http://tools.ietf.org/html/draft-ietf-stox-im-05
draft-ietf-stox-chat-03 : =
http://tools.ietf.org/html/draft-ietf-stox-chat-03

Less than a week left until the deadline December 9, 2013.

If you've reviewed the documents, please don't forget to send a note to =
the list with any remaining issues you may have found or just that you =
find the documents complete.

Regards,
Yana Stamcheva=

From fippo@goodadvice.pages.de  Sun Dec  8 03:38:41 2013
Return-Path: <fippo@goodadvice.pages.de>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7F81ADF51 for <stox@ietfa.amsl.com>; Sun,  8 Dec 2013 03:38:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Level: 
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo8vvKh1y-dx for <stox@ietfa.amsl.com>; Sun,  8 Dec 2013 03:38:39 -0800 (PST)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 15A451ADDD1 for <stox@ietf.org>; Sun,  8 Dec 2013 03:38:38 -0800 (PST)
Received: from [192.168.2.101] (p54970265.dip0.t-ipconnect.de [84.151.2.101]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id rB8BcWTN031137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <stox@ietf.org>; Sun, 8 Dec 2013 12:38:33 +0100
Message-ID: <52A45A33.5090708@goodadvice.pages.de>
Date: Sun, 08 Dec 2013 12:38:27 +0100
From: Philipp Hancke <fippo@goodadvice.pages.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: stox@ietf.org
References: <648368DC-1BD5-4D6A-B4E0-3D72B2EB3A6D@jitsi.org>
In-Reply-To: <648368DC-1BD5-4D6A-B4E0-3D72B2EB3A6D@jitsi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Stox] review of -im (was: Re:  Reminder WGLC on -im and -chat)
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 11:38:41 -0000

Am 04.12.2013 14:17, schrieb Yana Stamcheva:
> This is a reminder for the WGLC on:
>
> draft-ietf-stox-im-05 : http://tools.ietf.org/html/draft-ietf-stox-im-05
> draft-ietf-stox-chat-03 : http://tools.ietf.org/html/draft-ietf-stox-chat-03
>
> Less than a week left until the deadline December 9, 2013.
>
> If you've reviewed the documents, please don't forget to send a note to the list with any remaining issues you may have found or just that you find the documents complete.

Looking good to me, even though I think that numbering the examples 
would be highly appreciated by readers.

table 1: might be worth mentioning that type has no mapping since we're 
only dealing with single instant messages for which this is not set.

table 2: Request-URI or To can map to 'to', right?

From fippo@goodadvice.pages.de  Sun Dec  8 03:45:26 2013
Return-Path: <fippo@goodadvice.pages.de>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C3D1ADF67 for <stox@ietfa.amsl.com>; Sun,  8 Dec 2013 03:45:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpOkViK_05Yj for <stox@ietfa.amsl.com>; Sun,  8 Dec 2013 03:45:25 -0800 (PST)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 1238B1ADF53 for <stox@ietf.org>; Sun,  8 Dec 2013 03:45:24 -0800 (PST)
Received: from [192.168.2.101] (p54970265.dip0.t-ipconnect.de [84.151.2.101]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id rB8BjIon031208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <stox@ietf.org>; Sun, 8 Dec 2013 12:45:20 +0100
Message-ID: <52A45BCA.4040301@goodadvice.pages.de>
Date: Sun, 08 Dec 2013 12:45:14 +0100
From: Philipp Hancke <fippo@goodadvice.pages.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: stox@ietf.org
References: <648368DC-1BD5-4D6A-B4E0-3D72B2EB3A6D@jitsi.org>
In-Reply-To: <648368DC-1BD5-4D6A-B4E0-3D72B2EB3A6D@jitsi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Stox] review of -chat (was: Re:  Reminder WGLC on -im and -chat)
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 11:45:26 -0000

> Less than a week left until the deadline December 9, 2013.
>
> If you've reviewed the documents, please don't forget to send a note to the list with any remaining issues you may have found or just that you find the documents complete.

Looking good to me with just a single comment on section 1:
I think it's worth mentioning that RFC 6121 section 5.1 encourages the 
inclusion of a <thread/> element, which makes it easier to track the 
informal construct.


From dave@cridland.net  Mon Dec  9 06:22:07 2013
Return-Path: <dave@cridland.net>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8F11AE2B9 for <stox@ietfa.amsl.com>; Mon,  9 Dec 2013 06:22:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG6JM1e5lsVb for <stox@ietfa.amsl.com>; Mon,  9 Dec 2013 06:22:05 -0800 (PST)
Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 65BA01ADF79 for <stox@ietf.org>; Mon,  9 Dec 2013 06:22:05 -0800 (PST)
Received: by mail-oa0-f45.google.com with SMTP id o6so3912948oag.32 for <stox@ietf.org>; Mon, 09 Dec 2013 06:22:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TNZAa81HXUSngeKHDgFQdxkbsO/UJWPc9/om5beKzGs=; b=HnQoHY60ZvMuWNAv42LJilbg68X64eXMT5vWnyH3I12MrpSfXVQWNCe//vMPIzd+vU I0jSm2uAiwUag0eJPKF1AhvWVnpWliPN8CVT5MwvxqGkn27pr5yUJcKqtqU9nJW53J1u wkgZzfozKHh9jcmtd9Az3kKyVvCWZ39FySy2k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TNZAa81HXUSngeKHDgFQdxkbsO/UJWPc9/om5beKzGs=; b=RK3lVKQka4OxcxgAT4wOT0aJAE5gTb+2egpDaNXEr6Gn6qCB/FiO2XnB+0YpO1xIzV nc1xFuSSu19qpJ/Wyh92DopEwUO2UFuwo0EhMjEAoGIrLkHQJGqJxqbg+IYFtKAJvB8Z BtpFBqbWhgUJfPwpsyhwSWngMh4kKNtu30iXPQG/4TLNnEjRy2qQ8gys398dA+hmvUWl dH0ej4YbBZ+YCajekkEKqIfmenlpO659Ge0i8niaNkR4GDOxEnvADLmDs72+LCp6BeDn 0ZaYrjjhGEGu514cwV/XzYhPI4bW25p7MQTAgSfISP8TqdmSPmU/wwweLV8aWLRHmk2I HXMA==
X-Gm-Message-State: ALoCoQlV6cUzpkg4lAbj7cFE0wmwRbNYn+fHDeWpWTMfOoprV5ymn26wHLvMPtRA/xQzswUnJJlM
MIME-Version: 1.0
X-Received: by 10.182.229.34 with SMTP id sn2mr85812obc.86.1386598920324; Mon, 09 Dec 2013 06:22:00 -0800 (PST)
Received: by 10.60.144.38 with HTTP; Mon, 9 Dec 2013 06:22:00 -0800 (PST)
In-Reply-To: <648368DC-1BD5-4D6A-B4E0-3D72B2EB3A6D@jitsi.org>
References: <648368DC-1BD5-4D6A-B4E0-3D72B2EB3A6D@jitsi.org>
Date: Mon, 9 Dec 2013 14:22:00 +0000
Message-ID: <CAKHUCzwRBEDH3_zc6ESz7YYP0FAbKuZEqX3Dc+_bqV_X=fgXGA@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: Yana Stamcheva <yana@jitsi.org>
Content-Type: multipart/alternative; boundary=001a1134975017c6cc04ed1ab8a9
Cc: stox@ietf.org
Subject: Re: [Stox] Reminder WGLC on -im and -chat
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 14:22:07 -0000

--001a1134975017c6cc04ed1ab8a9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

World's shortest reviews to try and sneak past the deadline:

On Wed, Dec 4, 2013 at 1:17 PM, Yana Stamcheva <yana@jitsi.org> wrote:

> draft-ietf-stox-im-05 : http://tools.ietf.org/html/draft-ietf-stox-im-05
> <http://tools.ietf.org/html/draft-ietf-stox-im-05 draft-ietf-stox-chat-03=
>


FWIW, I don't think you could actually do much of this wrong - that is,
beyond -core (and therefore address and error mappings), I suspect
everything else can fall into a quality-of-implementation issue - so as
such, I think this only needs to supply guidance and wisdom rather than
laying down the law - I'm reviewing accordingly.

This largely seems OK.

=A76 appears to have interesting mangling of the characters. I think
&amp;#xC3A9; is intended to be &#xC3A9; isn't it?

I think this is an unfortunate choice of notation, actually, because in the
XMPP case this is valid as-is, whereas in the SIP case it needs to be
unencoded UTF-8 - I don't know whether the Content-Type should also include
a charset parameter for SIP.

It may be better to show either C-style or URL escaping of the UTF-8 in the
SIP version, or else a <U+C389>, or something. This will impact the
Content-Length of course.

Security Considerations should probably refer back to -core as well,
shouldn't they?

draft-ietf-stox-chat-03 <http://tools.ietf.org/html/draft-ietf-stox-im-05
> draft-ietf-stox-chat-03> :
> http://tools.ietf.org/html/draft-ietf-stox-chat-03


This draft appears to consist mostly of two giant examples. :-)

However, it seems to be sufficient guidance to build an interoperable
gateway, so I'm happy this is ready - however as with the above, Security
Considerations should probably refer back to -im and -core.

Dave.

--001a1134975017c6cc04ed1ab8a9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">World&#39;s shortest reviews to try and sneak past the dea=
dline:<div><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Wed, Dec 4, 2013 at 1:17 PM, Yana Stamcheva <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:yana@jitsi.org" target=3D"_blank">yana@jitsi.org</a>&gt;</span>=
 wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">draft-ietf-stox-im-05 : <a href=3D"http://to=
ols.ietf.org/html/draft-ietf-stox-im-05
draft-ietf-stox-chat-03" target=3D"_blank">http://tools.ietf.org/html/draft=
-ietf-stox-im-05<br></a></blockquote><div><br></div><div>FWIW, I don&#39;t =
think you could actually do much of this wrong - that is, beyond -core (and=
 therefore address and error mappings), I suspect everything else can fall =
into a quality-of-implementation issue - so as such, I think this only need=
s to supply guidance and wisdom rather than laying down the law - I&#39;m r=
eviewing accordingly.</div>
<div><br></div><div>This largely seems OK.</div><div><br></div><div>=A76 ap=
pears to have interesting mangling of the characters. I think &amp;amp;#xC3=
A9; is intended to be &amp;#xC3A9; isn&#39;t it?</div><div><br></div><div>
I think this is an unfortunate choice of notation, actually, because in the=
 XMPP case this is valid as-is, whereas in the SIP case it needs to be unen=
coded UTF-8 - I don&#39;t know whether the Content-Type should also include=
 a charset parameter for SIP.</div>
<div><br></div><div>It may be better to show either C-style or URL escaping=
 of the UTF-8 in the SIP version, or else a &lt;U+C389&gt;, or something. T=
his will impact the Content-Length of course.</div><div><br></div><div>
Security Considerations should probably refer back to -core as well, should=
n&#39;t they?</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href=
=3D"http://tools.ietf.org/html/draft-ietf-stox-im-05
draft-ietf-stox-chat-03" target=3D"_blank">
draft-ietf-stox-chat-03</a> : <a href=3D"http://tools.ietf.org/html/draft-i=
etf-stox-chat-03" target=3D"_blank">http://tools.ietf.org/html/draft-ietf-s=
tox-chat-03</a></blockquote><div><br></div><div>This draft appears to consi=
st mostly of two giant examples. :-)</div>
<div><br></div><div>However, it seems to be sufficient guidance to build an=
 interoperable gateway, so I&#39;m happy this is ready - however as with th=
e above, Security Considerations should probably refer back to -im and -cor=
e.</div>
<div><br></div><div>Dave.</div></div></div></div>

--001a1134975017c6cc04ed1ab8a9--

From stpeter@stpeter.im  Mon Dec  9 07:47:22 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC31A1AE2FE for <stox@ietfa.amsl.com>; Mon,  9 Dec 2013 07:47:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTJxCnRkCx0i for <stox@ietfa.amsl.com>; Mon,  9 Dec 2013 07:47:19 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E80371AE28C for <stox@ietf.org>; Mon,  9 Dec 2013 07:47:18 -0800 (PST)
Received: from ergon.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8FE9A4010C; Mon,  9 Dec 2013 08:47:13 -0700 (MST)
Message-ID: <52A5E600.3050103@stpeter.im>
Date: Mon, 09 Dec 2013 08:47:12 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Philipp Hancke <fippo@goodadvice.pages.de>, stox@ietf.org
References: <648368DC-1BD5-4D6A-B4E0-3D72B2EB3A6D@jitsi.org> <52A45A33.5090708@goodadvice.pages.de>
In-Reply-To: <52A45A33.5090708@goodadvice.pages.de>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Stox] review of -im
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 15:47:22 -0000

On 12/8/13 4:38 AM, Philipp Hancke wrote:
> Am 04.12.2013 14:17, schrieb Yana Stamcheva:
>> This is a reminder for the WGLC on:
>>
>> draft-ietf-stox-im-05 : http://tools.ietf.org/html/draft-ietf-stox-im-05
>> draft-ietf-stox-chat-03 :
>> http://tools.ietf.org/html/draft-ietf-stox-chat-03
>>
>> Less than a week left until the deadline December 9, 2013.
>>
>> If you've reviewed the documents, please don't forget to send a note
>> to the list with any remaining issues you may have found or just that
>> you find the documents complete.
> 
> Looking good to me, even though I think that numbering the examples
> would be highly appreciated by readers.

Yes. The examples in the other documents have numbers, so it's an
oversight that these don't.

> table 1: might be worth mentioning that type has no mapping since we're
> only dealing with single instant messages for which this is not set.

That's true as far as it goes, but I think this document is making the
more general claim that there's no direct mapping of XMPP message 'type'
values (such as "chat", "headline", and "groupchat") to SIP headers.

> table 2: Request-URI or To can map to 'to', right?

Correct.

Peter

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



From stpeter@stpeter.im  Mon Dec  9 08:18:25 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8131D1AE2B6 for <stox@ietfa.amsl.com>; Mon,  9 Dec 2013 08:18:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kS1MpEy-fwPz for <stox@ietfa.amsl.com>; Mon,  9 Dec 2013 08:18:23 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DD1BA1AE2A4 for <stox@ietf.org>; Mon,  9 Dec 2013 08:18:23 -0800 (PST)
Received: from ergon.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E58B34010C; Mon,  9 Dec 2013 09:18:18 -0700 (MST)
Message-ID: <52A5ED4A.3080809@stpeter.im>
Date: Mon, 09 Dec 2013 09:18:18 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Philipp Hancke <fippo@goodadvice.pages.de>, stox@ietf.org
References: <648368DC-1BD5-4D6A-B4E0-3D72B2EB3A6D@jitsi.org> <52A45BCA.4040301@goodadvice.pages.de>
In-Reply-To: <52A45BCA.4040301@goodadvice.pages.de>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Stox] review of -chat
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 16:18:25 -0000

On 12/8/13 4:45 AM, Philipp Hancke wrote:
>> Less than a week left until the deadline December 9, 2013.
>>
>> If you've reviewed the documents, please don't forget to send a note
>> to the list with any remaining issues you may have found or just that
>> you find the documents complete.
> 
> Looking good to me with just a single comment on section 1:
> I think it's worth mentioning that RFC 6121 section 5.1 encourages the
> inclusion of a <thread/> element, which makes it easier to track the
> informal construct.

Noted!

Peter

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



From dromasca@avaya.com  Mon Dec  9 09:11:19 2013
Return-Path: <dromasca@avaya.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A049D1AE355; Mon,  9 Dec 2013 09:11:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDqZtRvvPsXD; Mon,  9 Dec 2013 09:11:16 -0800 (PST)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id C43511AE350; Mon,  9 Dec 2013 09:11:15 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqcLAFn5pVLGmAcV/2dsb2JhbABZgmYhOFOkEQOVAYEvFm0HgicBAQMSKD8SARUHDhRCJgEEDg0ah2ABDKdRmg+NIYE+MYMngRMDmUSFPIsngymCKg
X-IronPort-AV: E=Sophos;i="4.93,859,1378872000"; d="scan'208";a="40513469"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Dec 2013 12:11:10 -0500
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 09 Dec 2013 12:03:39 -0500
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Mon, 9 Dec 2013 18:11:08 +0100
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "gen-art@ietf.org" <gen-art@ietf.org>
Thread-Topic: Gen-ART review for draft-ietf-stox-core-07
Thread-Index: Ac71AaYkPSSEa/FRR8+uoKOrpd6+Ag==
Date: Mon, 9 Dec 2013 17:11:07 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129DE669@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-stox-core.all@tools.ietf.org" <draft-ietf-stox-core.all@tools.ietf.org>, "stox@ietf.org" <stox@ietf.org>
Subject: [Stox] Gen-ART review for draft-ietf-stox-core-07
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 17:11:19 -0000

I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR=
T, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you m=
ay receive.

Document: draft-ietf-stox-core-07
Reviewer: Dan Romascanu
Review Date: 12/9/13
IETF LC End Date: 12/11/13
IESG Telechat date:=20

Summary:
Ready

Major issues:
None

Minor issues:
None

Nits/editorial comments:

1. Please expand XSF at first occurrence
2. It would be good to find some other wording for 'This document inaugurat=
es a series of SIP-XMPP interworking specifications'. For example 'This doc=
ument provides information for a series of SIP-XMPP interworking specificat=
ions'



From stpeter@stpeter.im  Mon Dec  9 09:22:16 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F971AE287 for <stox@ietfa.amsl.com>; Mon,  9 Dec 2013 09:22:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCc6U_YE1uSZ for <stox@ietfa.amsl.com>; Mon,  9 Dec 2013 09:22:12 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDC21AE005 for <stox@ietf.org>; Mon,  9 Dec 2013 09:22:12 -0800 (PST)
Received: from ergon.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1A6364010C; Mon,  9 Dec 2013 10:22:07 -0700 (MST)
Message-ID: <52A5FC3E.4070704@stpeter.im>
Date: Mon, 09 Dec 2013 10:22:06 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Dave Cridland <dave@cridland.net>, Yana Stamcheva <yana@jitsi.org>
References: <648368DC-1BD5-4D6A-B4E0-3D72B2EB3A6D@jitsi.org> <CAKHUCzwRBEDH3_zc6ESz7YYP0FAbKuZEqX3Dc+_bqV_X=fgXGA@mail.gmail.com>
In-Reply-To: <CAKHUCzwRBEDH3_zc6ESz7YYP0FAbKuZEqX3Dc+_bqV_X=fgXGA@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: stox@ietf.org
Subject: Re: [Stox] Reminder WGLC on -im and -chat
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 17:22:17 -0000

On 12/9/13 7:22 AM, Dave Cridland wrote:
> World's shortest reviews to try and sneak past the deadline:

Hi Dave, thanks for the review. Comments inline.

> On Wed, Dec 4, 2013 at 1:17 PM, Yana Stamcheva <yana@jitsi.org
> <mailto:yana@jitsi.org>> wrote:
> 
>     draft-ietf-stox-im-05 : http://tools.ietf.org/html/draft-ietf-stox-im-05
>     <http://tools.ietf.org/html/draft-ietf-stox-im-05
>     draft-ietf-stox-chat-03>
> 
> 
> FWIW, I don't think you could actually do much of this wrong - that is,
> beyond -core (and therefore address and error mappings), I suspect
> everything else can fall into a quality-of-implementation issue - so as
> such, I think this only needs to supply guidance and wisdom rather than
> laying down the law - I'm reviewing accordingly.
> 
> This largely seems OK.
> 
> §6 appears to have interesting mangling of the characters. I think
> &amp;#xC3A9; is intended to be &#xC3A9; isn't it?

Yes. <![CDATA[]]> is your friend for escaping purposes.

> I think this is an unfortunate choice of notation, 

It's driven by the limitations of the RFC format.

> actually, because in
> the XMPP case this is valid as-is, whereas in the SIP case it needs to
> be unencoded UTF-8 

What is "unencoded UTF-8"? UTF-8 is itself an encoding. Plus, RFC 3261 says:

   SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279
   [7]).

> - I don't know whether the Content-Type should also
> include a charset parameter for SIP.

Like this?

OLD
Content-Type: text/plain

NEW
Content-Type: text/plain; charset=utf-8

Given that SIP natively "uses the UTF-8 charset", it strikes me that the
charset parameter is unnecessary here.

> It may be better to show either C-style or URL escaping of the UTF-8 in
> the SIP version, or else a <U+C389>, or something. 

I'm not convinced that this is needed.

> Security Considerations should probably refer back to -core as well,
> shouldn't they?

Yes.

>     draft-ietf-stox-chat-03
>     <http://tools.ietf.org/html/draft-ietf-stox-im-05
>     draft-ietf-stox-chat-03> :
>     http://tools.ietf.org/html/draft-ietf-stox-chat-03
> 
> 
> This draft appears to consist mostly of two giant examples. :-)
> 
> However, it seems to be sufficient guidance to build an interoperable
> gateway, so I'm happy this is ready - however as with the above,
> Security Considerations should probably refer back to -im and -core.

Agreed.

Peter

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



From stpeter@stpeter.im  Mon Dec  9 09:26:49 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D8D1AE36D; Mon,  9 Dec 2013 09:26:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0v0OUeyzS15H; Mon,  9 Dec 2013 09:26:45 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1242D1AE317; Mon,  9 Dec 2013 09:26:24 -0800 (PST)
Received: from ergon.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2B0874010C; Mon,  9 Dec 2013 10:26:19 -0700 (MST)
Message-ID: <52A5FD3A.1080400@stpeter.im>
Date: Mon, 09 Dec 2013 10:26:18 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>,  "gen-art@ietf.org" <gen-art@ietf.org>
References: <9904FB1B0159DA42B0B887B7FA8119CA129DE669@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA129DE669@AZ-FFEXMB04.global.avaya.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "draft-ietf-stox-core.all@tools.ietf.org" <draft-ietf-stox-core.all@tools.ietf.org>, "stox@ietf.org" <stox@ietf.org>
Subject: Re: [Stox] Gen-ART review for draft-ietf-stox-core-07
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 17:26:49 -0000

On 12/9/13 10:11 AM, Romascanu, Dan (Dan) wrote:
> I am the assigned Gen-ART reviewer for this draft. 

Hi Dan, thanks for the review!

> For background on Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments you may receive.
> 
> Document: draft-ietf-stox-core-07
> Reviewer: Dan Romascanu
> Review Date: 12/9/13
> IETF LC End Date: 12/11/13
> IESG Telechat date: 
> 
> Summary:
> Ready
> 
> Major issues:
> None
> 
> Minor issues:
> None
> 
> Nits/editorial comments:
> 
> 1. Please expand XSF at first occurrence

Ack.

> 2. It would be good to find some other wording for 'This document inaugurates a series of SIP-XMPP interworking specifications'. For example 'This document provides information for a series of SIP-XMPP interworking specifications'

How about s/inaugurates/provides the basis for/ ?

Peter

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



From dromasca@avaya.com  Mon Dec  9 09:29:08 2013
Return-Path: <dromasca@avaya.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B482C1AE304; Mon,  9 Dec 2013 09:29:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WI7deEfe1uH; Mon,  9 Dec 2013 09:29:07 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 554B01ADFEF; Mon,  9 Dec 2013 09:29:07 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAC/9pVKHCzI1/2dsb2JhbABZgmYhgQu5FYEvFnSCJQEBAQEDEig/DAQCAQgNCA0UCQcyFBEBAQQBDQUIGodgAaddmXgXjl8xB4MggRMDnwCLJ4Mpgio
X-IronPort-AV: E=Sophos;i="4.93,859,1378872000"; d="scan'208";a="40241500"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Dec 2013 12:29:02 -0500
Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 09 Dec 2013 12:17:40 -0500
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Mon, 9 Dec 2013 18:28:45 +0100
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Peter Saint-Andre <stpeter@stpeter.im>, "gen-art@ietf.org" <gen-art@ietf.org>
Thread-Topic: [Stox] Gen-ART review for draft-ietf-stox-core-07
Thread-Index: Ac71AaYkPSSEa/FRR8+uoKOrpd6+AgALAe8AAAppGXA=
Date: Mon, 9 Dec 2013 17:28:44 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129DE6E6@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA129DE669@AZ-FFEXMB04.global.avaya.com> <52A5FD3A.1080400@stpeter.im>
In-Reply-To: <52A5FD3A.1080400@stpeter.im>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-stox-core.all@tools.ietf.org" <draft-ietf-stox-core.all@tools.ietf.org>, "stox@ietf.org" <stox@ietf.org>
Subject: Re: [Stox] Gen-ART review for draft-ietf-stox-core-07
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 17:29:08 -0000

> -----Original Message-----
> From: Peter Saint-Andre [mailto:stpeter@stpeter.im]
>=20
> How about s/inaugurates/provides the basis for/ ?
>=20

Fine.=20

Thanks,=20

Dan


From stpeter@stpeter.im  Mon Dec  9 10:32:08 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B011AE35B; Mon,  9 Dec 2013 10:32:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.703
X-Spam-Level: 
X-Spam-Status: No, score=-2.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_12=0.6, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzzn0EjxIZja; Mon,  9 Dec 2013 10:32:07 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EF5171AE057; Mon,  9 Dec 2013 10:32:06 -0800 (PST)
Received: from ergon.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B28284010C; Mon,  9 Dec 2013 11:32:01 -0700 (MST)
Message-ID: <52A60CA1.6040503@stpeter.im>
Date: Mon, 09 Dec 2013 11:32:01 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Dave Cridland <dave@cridland.net>,  "ietf@ietf.org Discussion" <ietf@ietf.org>
References: <20131127124920.17385.35362.idtracker@ietfa.amsl.com> <CAKHUCzz4jYi9GVbPaHgM2PMAb3M1POryYCx2bdsqGcM4bE=hQQ@mail.gmail.com>
In-Reply-To: <CAKHUCzz4jYi9GVbPaHgM2PMAb3M1POryYCx2bdsqGcM4bE=hQQ@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: "stox@ietf.org" <stox@ietf.org>
Subject: Re: [Stox] Last Call: <draft-ietf-stox-core-07.txt> (Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling) to Proposed Standard
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 18:32:08 -0000

On 12/9/13 6:53 AM, Dave Cridland wrote:
> On Wed, Nov 27, 2013 at 12:49 PM, The IESG <iesg-secretary@ietf.org
> <mailto:iesg-secretary@ietf.org>> wrote:
> 
> 
>     The IESG has received a request from the SIP-TO-XMPP WG (stox) to
>     consider the following document:
>     - 'Interworking between the Session Initiation Protocol (SIP) and the
>        Extensible Messaging and Presence Protocol (XMPP): Architecture,
>        Addresses, and Error Handling'
>       <draft-ietf-stox-core-07.txt> as Proposed Standard
> 
> 
> A small nit - §5.5 contains:
> 
>     Several examples follow, illustrating steps 3, 5, and 8 described
>    above (the percent-encoded string "%C3%BC" and XML Notation string
>    "&#00FC;" both represent the Unicode character LATIN SMALL LETTER U
>    WITH DIAERESIS).
> 
> I don't think this is quite true. The percent-encoded string is an
> encoding of the codepoint U+FC as UTF-8, whereas the construct &#00FC;
> is an XML notation for the character - which crucially is not part of
> the address format, but simple how one could transmit the address over
> XML (including XMPP).

You sent a similar message to the STOX WG list about another I-D
produced by that WG, but I didn't grok your point until just now. I
think this text would be clearer:

###

      +----------------------------+--------------------------+
      | SIP URI                    |  XMPP Address            |
      +----------------------------+--------------------------+
      | sip:f%C3%BC@sip.example    |  f&#xFC;@sip.example     |
      | sip:o'malley@sip.example   |  o\27malley@sip.example  |
      | sip:foo@sip.example;gr=bar |  foo@sip.example/bar     |
      +----------------------------+--------------------------+

   In the first example, the string "%C3%BC" is a percent-encoded
   representation of the UTF-8-encoded Unicode character LATIN SMALL
   LETTER U WITH DIAERESIS (U+00FC), whereas the string "&#xFC;" is the
   same character shown for documentation purposes using the XML
   Notation defined in [RFC3987] (in XMPP it would be sent directly as a
   UTF-8-encoded Unicode character and not percent-encoded as in a SIP
   URI to comply with the URI syntax defined in [RFC3986]).

###

> The example given is actually tsch&#00FCss@xmpp.example - due to there
> being no terminating ";", I'd expect that to be taken literally by an
> XML parser, and not be treated as tschüss@xmpp.example as I suspect is
> desired.

That's a typo - the ';' is missing (and in fact the "00" is not needed
in accordance with the XML Notation from RFC 3987). Thus:

OLD
tsch&#00FCss@xmpp.example
NEW
tsch&#xFC;ss@xmpp.example

Peter

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



From stpeter@stpeter.im  Mon Dec  9 11:26:06 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9B61AE4E1; Mon,  9 Dec 2013 11:26:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level: 
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZS_SOTAQQJ5; Mon,  9 Dec 2013 11:26:03 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A2F281AE4C3; Mon,  9 Dec 2013 11:26:03 -0800 (PST)
Received: from ergon.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9C5484010C; Mon,  9 Dec 2013 12:25:58 -0700 (MST)
Message-ID: <52A61946.5010908@stpeter.im>
Date: Mon, 09 Dec 2013 12:25:58 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Robert Sparks <rjsparks@nostrum.com>, ietf@ietf.org
References: <20131127124920.17385.35362.idtracker@ietfa.amsl.com> <529E3BA1.1010606@nostrum.com>
In-Reply-To: <529E3BA1.1010606@nostrum.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
Subject: Re: [Stox] Last Call: <draft-ietf-stox-core-07.txt> (Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling) to Proposed Standard
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 19:26:06 -0000

On 12/3/13 1:14 PM, Robert Sparks wrote:
> With many apologies to Peter and to the STOX WG for the timing of this:

Hi Robert, no apologies are necessary (although I apologize for the slow
reply!) -- that's what WG and IETF-wide reviews are for. :-)

> I still think there's a couple of small problems with the treatment of
> translation into and out of 503.
> 
> The first is that we left folks without guidance if they're handling
> translating a SIP response into an XMPP
> response in this case - the document's rather silent about that
> direction in the note in section 6.1.

Good point. I think it would be helpful to make this clear in Section
6.2 (referring back to the note in Section 6.1).

> Should they translate a 503 into a <internal-server-error/> as for
> unknown 5xx-class responses?

Yes, I think that's a reasonable mapping given the semantics of the SIP
503 response code.

> There's a similar issue with 402 - the pointer to note 1 says
> <payment-required/> no longer exists, but
> doesn't give us anything to map a 402 into. is <bad-request/> (the
> unknown 4xx mapping) ok?

I think so, but will make that explicit in the text.

> The second is a nit with the text in the note in section 6.1. It
> currently says " the SIP 503 response
> code will be interpreted as applying to the entire domain, not only the
> specific user". That's not
> quite right, and it's important to get this right since we're leaving it
> mostly to the gateway designer
> to guess at what to do. The 503 talks about the element that returned
> it, not anything in the request,
> so while it's right that it's not only talking about a specific user,
> it's not right to say it's talking about
> an entire domain (and while that entire domain would be affected _at
> this element_, it's more than that -
> _ANY_ domain's resource routed to this element will not be handled by
> this element until the condition
> that led to the 503 goes away). I suggest saying this instead: "the SIP
> 503 response code will be interpreted
> as applying to all future requests to this server, not just requests for
> the specific user".

Although the subtleties of SIP elements and response codes are not
completely clear to me, based on what I know your text seems better to me.

> I also whipped up some bad python to look at what round-tripping an
> errror from XMPP->SIP->XMPP and
> vice-versa looked like as a sanity check (which brought the 503 and 402
> issues in the first item above to
> my attention). Here's the result. Please look over them and see if any
> of them are surprising or unacceptable.

It's good that you checked these. Comments below.

> (They are easier to read in a fixed-width font).
> 
> I'm particularly suspicious of subscription-required ->
> registration-required and of 301 -> 410.
> 
> 
> XMPP -> SIP -> XMPP
> bad-request              -> bad-request
> conflict                 -> bad-request
> feature-not-implemented  -> feature-not-implemented
> forbidden                -> policy-violation, forbidden,
> recipient-unavailable, not-allowed
> gone                     -> gone
> internal-server-error    -> internal-server-error
> item-not-found           -> item-not-found, remote-server-not-found
> jid-malformed            -> bad-request
> not-acceptable           -> not-acceptable
> not-allowed              -> policy-violation, forbidden, not-allowed
> not-authorized           -> not-authorized
> policy-violation         -> policy-violation, forbidden, not-allowed
> recipient-unavailable    -> recipient-unavailable
> redirect                 -> redirect
> registration-required    -> registration-required
> remote-server-not-found  -> remote-server-timeout, item-not-found,
> remote-server-not-found
> remote-server-timeout    -> remote-server-timeout, remote-server-not-found
> resource-constraint      -> internal-server-error
> service-unavailable      -> policy-violation, forbidden,
> feature-not-implemented, not-allowed
> subscription-required    -> registration-required

Looking again at RFC 3261 and RFC 6120, I conclude that mapping XMPP
subscription-required to SIP 407 isn't quite right, because as far I
understand it SIP 407 has to do with authentication at a proxy, which is
not what XMPP subscription-required is about. Thus I suggest that we map
XMPP subscription-required to SIP 400, which would result in a
round-trip translation of:

subscription-required -> bad-request

IMHO that's less problematic than the translation you've highlighted.

> undefined-condition      -> bad-request
> unexpected-request       -> bad-request, unexpected-request
> 
> SIP -> XMPP -> SIP
> 300 -> 302
> 301 -> 410

It seems that the difference between 301 and 410 in SIP response codes
is just the lack of a forwarding address. If that is correct, we can
handle this by mapping as follows:

SIP 301 -> XMPP <gone/> with XML character data for new address
SIP 410 -> XMPP <gone/> with no XML character data (new address unknown)

Then we can map:

XMPP <gone/> with XML character data -> SIP 301
XMPP <gone/> without XML character data -> SIP 410

This would result in a round-trip mapping of 301 -> 301.

> 302 -> 302
> 305 -> 302
> 380 -> 606, 406
> 400 -> 400
> 401 -> 401
> 402 -> UNDEFINED

I think that would now be 402 -> 400.

> 403 -> 603, 403
> 404 -> 408, 604, 404
> 405 -> 405, 501
> 406 -> 606, 406
> 407 -> 407
> 408 -> 408, 404
> 410 -> 410
> 413 -> 403
> 414 -> 403
> 415 -> 606, 406
> 416 -> 606, 406
> 420 -> 405, 501
> 421 -> 606, 406
> 423 -> 500
> 430 -> 480, 600
> 439 -> 405, 501
> 440 -> 403
> 480 -> 480, 600
> 481 -> 604, 404
> 482 -> 606, 406
> 483 -> 606, 406
> 484 -> 604, 404
> 485 -> 604, 404
> 486 -> 480, 600
> 487 -> 480, 600
> 488 -> 606, 406
> 489 -> 403
> 491 -> 400, 491
> 493 -> 400
> 500 -> 500
> 501 -> 405, 501
> 502 -> 408, 404
> 503 -> UNDEFINED

I think that would now be 503 -> 500.

> 504 -> 408
> 505 -> 606, 406
> 513 -> 403
> 600 -> 480, 600
> 603 -> 480, 600
> 604 -> 604, 404
> 606 -> 606, 406
> 
> 
> RjS

Thanks again for the thorough reviews!

Peter

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



From rjsparks@nostrum.com  Mon Dec  9 12:03:33 2013
Return-Path: <rjsparks@nostrum.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BAB1AE2AB; Mon,  9 Dec 2013 12:03:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLM64ysuivUk; Mon,  9 Dec 2013 12:03:32 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C9A5F1AE281; Mon,  9 Dec 2013 12:03:31 -0800 (PST)
Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB9K3Pfb025910 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Mon, 9 Dec 2013 14:03:26 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <52A6220D.8010005@nostrum.com>
Date: Mon, 09 Dec 2013 14:03:25 -0600
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>, ietf@ietf.org
References: <20131127124920.17385.35362.idtracker@ietfa.amsl.com> <529E3BA1.1010606@nostrum.com> <52A61946.5010908@stpeter.im>
In-Reply-To: <52A61946.5010908@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 173.71.10.88 is authenticated by a trusted mechanism)
Cc: stox@ietf.org
Subject: Re: [Stox] Last Call: <draft-ietf-stox-core-07.txt> (Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling) to Proposed Standard
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 20:03:34 -0000

Everything below looks good to me.

RjS

On 12/9/13 1:25 PM, Peter Saint-Andre wrote:
> On 12/3/13 1:14 PM, Robert Sparks wrote:
>> With many apologies to Peter and to the STOX WG for the timing of this:
> Hi Robert, no apologies are necessary (although I apologize for the slow
> reply!) -- that's what WG and IETF-wide reviews are for. :-)
>
>> I still think there's a couple of small problems with the treatment of
>> translation into and out of 503.
>>
>> The first is that we left folks without guidance if they're handling
>> translating a SIP response into an XMPP
>> response in this case - the document's rather silent about that
>> direction in the note in section 6.1.
> Good point. I think it would be helpful to make this clear in Section
> 6.2 (referring back to the note in Section 6.1).
>
>> Should they translate a 503 into a <internal-server-error/> as for
>> unknown 5xx-class responses?
> Yes, I think that's a reasonable mapping given the semantics of the SIP
> 503 response code.
>
>> There's a similar issue with 402 - the pointer to note 1 says
>> <payment-required/> no longer exists, but
>> doesn't give us anything to map a 402 into. is <bad-request/> (the
>> unknown 4xx mapping) ok?
> I think so, but will make that explicit in the text.
>
>> The second is a nit with the text in the note in section 6.1. It
>> currently says " the SIP 503 response
>> code will be interpreted as applying to the entire domain, not only the
>> specific user". That's not
>> quite right, and it's important to get this right since we're leaving it
>> mostly to the gateway designer
>> to guess at what to do. The 503 talks about the element that returned
>> it, not anything in the request,
>> so while it's right that it's not only talking about a specific user,
>> it's not right to say it's talking about
>> an entire domain (and while that entire domain would be affected _at
>> this element_, it's more than that -
>> _ANY_ domain's resource routed to this element will not be handled by
>> this element until the condition
>> that led to the 503 goes away). I suggest saying this instead: "the SIP
>> 503 response code will be interpreted
>> as applying to all future requests to this server, not just requests for
>> the specific user".
> Although the subtleties of SIP elements and response codes are not
> completely clear to me, based on what I know your text seems better to me.
>
>> I also whipped up some bad python to look at what round-tripping an
>> errror from XMPP->SIP->XMPP and
>> vice-versa looked like as a sanity check (which brought the 503 and 402
>> issues in the first item above to
>> my attention). Here's the result. Please look over them and see if any
>> of them are surprising or unacceptable.
> It's good that you checked these. Comments below.
>
>> (They are easier to read in a fixed-width font).
>>
>> I'm particularly suspicious of subscription-required ->
>> registration-required and of 301 -> 410.
>>
>>
>> XMPP -> SIP -> XMPP
>> bad-request              -> bad-request
>> conflict                 -> bad-request
>> feature-not-implemented  -> feature-not-implemented
>> forbidden                -> policy-violation, forbidden,
>> recipient-unavailable, not-allowed
>> gone                     -> gone
>> internal-server-error    -> internal-server-error
>> item-not-found           -> item-not-found, remote-server-not-found
>> jid-malformed            -> bad-request
>> not-acceptable           -> not-acceptable
>> not-allowed              -> policy-violation, forbidden, not-allowed
>> not-authorized           -> not-authorized
>> policy-violation         -> policy-violation, forbidden, not-allowed
>> recipient-unavailable    -> recipient-unavailable
>> redirect                 -> redirect
>> registration-required    -> registration-required
>> remote-server-not-found  -> remote-server-timeout, item-not-found,
>> remote-server-not-found
>> remote-server-timeout    -> remote-server-timeout, remote-server-not-found
>> resource-constraint      -> internal-server-error
>> service-unavailable      -> policy-violation, forbidden,
>> feature-not-implemented, not-allowed
>> subscription-required    -> registration-required
> Looking again at RFC 3261 and RFC 6120, I conclude that mapping XMPP
> subscription-required to SIP 407 isn't quite right, because as far I
> understand it SIP 407 has to do with authentication at a proxy, which is
> not what XMPP subscription-required is about. Thus I suggest that we map
> XMPP subscription-required to SIP 400, which would result in a
> round-trip translation of:
>
> subscription-required -> bad-request
>
> IMHO that's less problematic than the translation you've highlighted.
>
>> undefined-condition      -> bad-request
>> unexpected-request       -> bad-request, unexpected-request
>>
>> SIP -> XMPP -> SIP
>> 300 -> 302
>> 301 -> 410
> It seems that the difference between 301 and 410 in SIP response codes
> is just the lack of a forwarding address. If that is correct, we can
> handle this by mapping as follows:
>
> SIP 301 -> XMPP <gone/> with XML character data for new address
> SIP 410 -> XMPP <gone/> with no XML character data (new address unknown)
>
> Then we can map:
>
> XMPP <gone/> with XML character data -> SIP 301
> XMPP <gone/> without XML character data -> SIP 410
>
> This would result in a round-trip mapping of 301 -> 301.
>
>> 302 -> 302
>> 305 -> 302
>> 380 -> 606, 406
>> 400 -> 400
>> 401 -> 401
>> 402 -> UNDEFINED
> I think that would now be 402 -> 400.
>
>> 403 -> 603, 403
>> 404 -> 408, 604, 404
>> 405 -> 405, 501
>> 406 -> 606, 406
>> 407 -> 407
>> 408 -> 408, 404
>> 410 -> 410
>> 413 -> 403
>> 414 -> 403
>> 415 -> 606, 406
>> 416 -> 606, 406
>> 420 -> 405, 501
>> 421 -> 606, 406
>> 423 -> 500
>> 430 -> 480, 600
>> 439 -> 405, 501
>> 440 -> 403
>> 480 -> 480, 600
>> 481 -> 604, 404
>> 482 -> 606, 406
>> 483 -> 606, 406
>> 484 -> 604, 404
>> 485 -> 604, 404
>> 486 -> 480, 600
>> 487 -> 480, 600
>> 488 -> 606, 406
>> 489 -> 403
>> 491 -> 400, 491
>> 493 -> 400
>> 500 -> 500
>> 501 -> 405, 501
>> 502 -> 408, 404
>> 503 -> UNDEFINED
> I think that would now be 503 -> 500.
>
>> 504 -> 408
>> 505 -> 606, 406
>> 513 -> 403
>> 600 -> 480, 600
>> 603 -> 480, 600
>> 604 -> 604, 404
>> 606 -> 606, 406
>>
>>
>> RjS
> Thanks again for the thorough reviews!
>
> Peter
>


From internet-drafts@ietf.org  Tue Dec 10 12:56:58 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0A71ADFF5; Tue, 10 Dec 2013 12:56:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlAMd6RhUPlh; Tue, 10 Dec 2013 12:56:57 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE871AE0D6; Tue, 10 Dec 2013 12:56:57 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131210205657.28238.37301.idtracker@ietfa.amsl.com>
Date: Tue, 10 Dec 2013 12:56:57 -0800
Cc: stox@ietf.org
Subject: [Stox] I-D Action: draft-ietf-stox-core-08.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 20:56:58 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.

	Title           : Interworking between the Session Initiation Protocol (SI=
P) and the Extensible Messaging and Presence Protocol (XMPP): Architecture,=
 Addresses, and Error Handling
	Author(s)       : Peter Saint-Andre
                          Avshalom Houri
                          Joe Hildebrand
	Filename        : draft-ietf-stox-core-08.txt
	Pages           : 19
	Date            : 2013-12-10

Abstract:
   As a foundation for the definition of bidirectional protocol mappings
   between the Session Initiation Protocol (SIP) and the Extensible
   Messaging and Presence Protocol (XMPP), this document specifies the
   architectural assumptions underlying such mappings as well as the
   mapping of addresses and error conditions.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-stox-core

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-stox-core-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-core-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Tue Dec 10 12:57:55 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337601AE0BD; Tue, 10 Dec 2013 12:57:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbWyJYW3NPVl; Tue, 10 Dec 2013 12:57:54 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C941ADFF5; Tue, 10 Dec 2013 12:57:54 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131210205753.32110.57411.idtracker@ietfa.amsl.com>
Date: Tue, 10 Dec 2013 12:57:53 -0800
Cc: stox@ietf.org
Subject: [Stox] I-D Action: draft-ietf-stox-im-06.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 20:57:55 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.

	Title           : Interworking between the Session Initiation Protocol (SI=
P) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messa=
ging
	Author(s)       : Peter Saint-Andre
                          Avshalom Houri
                          Joe Hildebrand
	Filename        : draft-ietf-stox-im-06.txt
	Pages           : 12
	Date            : 2013-12-10

Abstract:
   This document defines a bidirectional protocol mapping for the
   exchange of single instant messages between the Session Initiation
   Protocol (SIP) and the Extensible Messaging and Presence Protocol
   (XMPP).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-stox-im

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-stox-im-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-im-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Tue Dec 10 12:58:21 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38AD1AE181; Tue, 10 Dec 2013 12:58:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7pilf6L8lD3; Tue, 10 Dec 2013 12:58:20 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7F31AE0D6; Tue, 10 Dec 2013 12:58:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131210205820.15229.16033.idtracker@ietfa.amsl.com>
Date: Tue, 10 Dec 2013 12:58:20 -0800
Cc: stox@ietf.org
Subject: [Stox] I-D Action: draft-ietf-stox-chat-04.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 20:58:21 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.

	Title           : Interworking between the Session Initiation Protocol (SI=
P) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Te=
xt Chat Sessions
	Author(s)       : Peter Saint-Andre
                          Salvatore Loreto
	Filename        : draft-ietf-stox-chat-04.txt
	Pages           : 18
	Date            : 2013-12-10

Abstract:
   This document defines a bidirectional protocol mapping for the
   exchange of instant messages in the context of a one-to-one chat
   session between a user of the Session Initiation Protocol (SIP) and a
   user of the Extensible Messaging and Presence Protocol (XMPP).
   Specifically for SIP text chat, this document specifies a mapping to
   the Message Session Relay Protocol (MSRP).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-stox-chat

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-stox-chat-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-chat-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From stpeter@stpeter.im  Tue Dec 10 13:08:46 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F97F1AE1C3 for <stox@ietfa.amsl.com>; Tue, 10 Dec 2013 13:08:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcIfpRackBMP for <stox@ietfa.amsl.com>; Tue, 10 Dec 2013 13:08:44 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 727E31AE18A for <stox@ietf.org>; Tue, 10 Dec 2013 13:08:44 -0800 (PST)
Received: from dhcp-10-129-4-79.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 677A14010C; Tue, 10 Dec 2013 14:08:38 -0700 (MST)
Message-ID: <52A782D5.7080004@stpeter.im>
Date: Tue, 10 Dec 2013 14:08:37 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: "stox@ietf.org" <stox@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: [Stox] updated I-Ds
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 21:08:46 -0000

I've just updated the core, im, and chat documents to incorporate
feedback received during IETF LC (core) and WGLC (im and chat).

Saúl and I should have an updated version of the groupchat document
available soon, and Emil, Saúl, and I will do the same for the media
document (likely media before groupchat, so that we are ready for the
interim meeting next week).

Peter

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



From dhc@dcrocker.net  Wed Dec 11 21:36:06 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4E31AE08F; Wed, 11 Dec 2013 21:36:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3
X-Spam-Level: 
X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNFZsiPErGBh; Wed, 11 Dec 2013 21:36:01 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 216741A802D; Wed, 11 Dec 2013 21:36:01 -0800 (PST)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rBC5ZpSF017650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Dec 2013 21:35:54 -0800
Message-ID: <52A94AF6.8090702@dcrocker.net>
Date: Wed, 11 Dec 2013 21:34:46 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Apps Discuss <apps-discuss@ietf.org>, draft-ietf-stox-presence.all@tools.ietf.org, stox@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 11 Dec 2013 21:35:55 -0800 (PST)
X-Mailman-Approved-At: Thu, 12 Dec 2013 01:00:24 -0800
Cc: iesg <iesg@ietf.org>
Subject: [Stox] Review of:  draft-ietf-stox-presence-06
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 05:36:06 -0000

G'day.

I have been selected as the Applications Area Review Team reviewer for 
this draft (for background on apps-review, please see 
http://www.apps.ietf.org/content/applications-area-review-team).
Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.



Review of:    Interworking between the Session Initiation Protocol (SIP) 
and the
               Extensible Messaging and Presence Protocol (XMPP): Presence
I-D:          draft-ietf-stox-presence-06

Reviewer:     D. Crocker
Review date:  12 Dec 13



Summary:

XMPP and SIP both have deployed versions of instant messaging and 
presence.  The current draft is part of a set of specifications that 
define a gateway capability between the the two services.  In 
particular, the current draft specifies the translation mechanism 
between the presence mechanisms used by SIP and XMPP.

The draft is well-structured and the text is mostly clear.  For an 
implementer already familiar with the details of the two services and 
the basics of the gatewaying specified here, the document probably is 
sufficient -- although responses to some of the detailed comments, 
below, might to turn out to show that a bit more work is needed. 
However at the most, any technical improvements that might be needed 
will be minor.  And I expect these to more in the nature of clarifying 
language than of changing bits over the wire.

However for a reader who is new to the topic, the document needs to be 
clearer and sometimes more complete.

Specific changes or concerns:

    1.  When citing the earlier efforts, there should be something to 
explain why the current work is expected to be more successful. That is, 
what makes the current approach notably tractable for implementation and 
deployment?

    2.  The document is not clear about the prerequisites for reading 
this draft.  What must the reader already know in depth?  What must they 
have at least superficial knowledge of?  I suspect that, in particular, 
they need deep familiarity with stox-core.

    3.  Saying that terms are taken from a substantial number of other 
documents, and then merely citing the documents in their entirety, is 
not helpful to the reader, unless the reader is required to be deeply 
familiar with those documents.  If that's what this document requires, 
say that.  If it's not, I suggest listing terms explicitly and 
indicating what document they are drawn from.

    4.  As the architecture diagram in Section 3 of stox-core shows, 
this service has at least separate actors Actually I think it actually 
has at least 6, which that diagram probably should show explicitly.  The 
six are:

        a. SIP user
        b. SIP server
        c. SIP-XMPP gateway
        d. XMPP-SIP gateway
        e. XMPP server
        f. XMPP user

        In any event, the specification needs to be very diligent to 
carefully identify each actor involved in an activity and the 
interaction between actors.  The current document uses language that 
often left me wondering such things as who was the target of the action.

        Much of this would be aided by some form of protocol sequence 
diagrams, to show who does what and in what order.

    5.  When showing protocol examples, usually only one side of the 
sequence is shown.  For gatewaying that does interesting transforms, 
such as this one, an example should show both the before and after 
versions.  That is, the 'native' protocol unit that was created and then 
the one that results from the translation.




Detailed Comments:


> Table of Contents


Nicely organized and concise TOC [ie, document structure).



> 1.  Introduction
...
>    One approach to helping ensure interworking between these protocols
>    is to map each protocol to the abstract semantics described in
>    [RFC3860]; that is the approach taken by both [RFC3922] and
>    [I-D.ietf-simple-cpim-mapping].  The approach taken in this document
>    is to directly map semantics from one protocol to another (i.e., from
>    SIP/SIMPLE to XMPP and vice-versa).

This begs the obvious question:  Why?  What was wrong with the previous 
approach?

The purpose of the question is not for criticizing prior work but to 
understand the expected benefit of the approach taken in the current 
work.  What are the function, or OA&M differences produced through this 
new approach, that are expected to be helpful?


>    The architectural assumptions underlying such direct mappings are
>    provided in [I-D.ietf-stox-core], including mapping of addresses and
>    error conditions.  The mappings specified in this document cover
>    basic presence functionality.  Mapping of more advanced functionality
>    (e.g., so-called "rich presence") is out of scope for this document.
>
>    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.
>
>
> 2.  Terminology
>
>    A number of terms used here are explained in [RFC3261], [RFC3856],
>    [RFC6120], and [RFC6121].

This sentence probably implies that the current draft should not be read 
in the absence of familiarity with all 4 of those RFCs.  I suggest some 
sort of explicit statement about how much prior knowledge is needed for 
understanding the current draft, and where to get that knowledge.

In purely mechanical terms, the problem with the above sentence is that 
it means that when the reader sees a term they don't understand, they 
have to run around to four different documents looking for definitions. 
  This mostly ensures reader frustration, for everyone but experts.

The cleanest fix for this is to list terms and where they are defined. 
The other, usual fix is to indeed say that the reader must be familiar 
with those other documents before reading this one.  (sigh.)


> 3.1.  Overview
...
>    As described in [RFC6121], XMPP presence subscriptions are managed
>    using XMPP presence stanzas of type "subscribe", "subscribed",
>    "unsubscribe", and "unsubscribed".  The main subscription states are
>    "none" (neither the user nor the contact is subscribed to the other's
>    presence information), "from" (the user has a subscription from the
>    contact), "to" (the user has a subscription to the contact's presence
>    information), and "both" (both user and contact are subscribed to
>    each other's presence information).

Nit:  for technical documents, lists like the above should be shown in 
list format.  It really does help for quick comprehension.


>
>    As described in [RFC3856], SIP presence subscriptions are managed
>    through the use of SIP SUBSCRIBE events sent from a SIP user agent to
>    an intended recipient who is most generally referenced by a Presence
>    URI of the form <pres:user@domain> but who might be referenced by a
>    SIP or SIPS URI of the form <sip:user@domain> or <sips:user@domain>.
>
>    The subscription models underlying XMPP and SIP are quite different.
>    For instance, XMPP presence subscriptions are long-lived (indeed
>    permanent if not explicitly cancelled), whereas SIP presence
>    subscriptions are short-lived (the default time-to-live of a SIP
>    presence subscription is 3600 seconds, as specified in Section 6.4 of
>    [RFC3856]).  These differences are addressed below.

The text that follows this 'addresses' the differences in terms of 
specifying how to handle specific differences.

What's missing -- but I think would aid for the framework of this 
document's effort -- is for the above "For instance" to instead be 
expanded into a detailed statement of what the differences are, separate 
from the later text that says how to deal with the differences.

Someone needing to implement this spec, probably will be starting with a 
reasonable model of one side -- or at least, reasonable knowledge of the 
details, if not a thoughtful, higher-level model -- and considerable 
ignorance of the other. Text that discusses details of differences, 
distinct from how to resolve them, will put the implementer into a 
better position of understanding what's being done.

This probably raises a larger issue:  How much expertise is expected of 
someone who is implementing this or otherwise reading for deep 
comprehension?  In the extreme, they will need to have serious expertise 
on both protocol sets.  The other extreme would be a cookbook inside 
this document, with no outside knowledge required.  The document needs 
to specify the nature and extent of the expertise required.  (In fact, 
the document seems pretty clean, in terms of explaining things, so I 
suspect that 'fair' knowledge of one suite will suffice.  But the author 
and wg beliefs about the requirement should be made explicit.)


> 3.2.  XMPP to SIP
>
> 3.2.1.  Establishing a Presence Subscription
>
>    An XMPP user (e.g., juliet@example.com) initiates a subscription by
>    sending a subscription request to another entity (e.g.,
>    romeo@example.net), and the other entity (conventionally called a

Move definition of contact up to first occurrence, above.


>    "contact") either accepts or declines the request.  If the contact
>    accepts the request, the user will have a subscription to the
>    contact's presence information until (1) the user unsubscribes or (2)
>    the contact cancels the subscription.  The subscription request is
>    encapsulated in a presence stanza of type "subscribe":
>
>
>
>
> Saint-Andre, et al.      Expires April 21, 2014                 [Page 4]
> 
> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>
>
>    Example 1: XMPP user subscribes to SIP contact:
>
>    |  <presence from='juliet@example.com'
>    |            to='romeo@example.net'
>    |            type='subscribe'/>
>
>    Upon receiving such a presence stanza, the XMPP server to which
>    Juliet has connected needs to determine the identity of the
>    domainpart in the 'to' address, which it does by following the
>    procedures discussed in [I-D.ietf-stox-core].  Here we assume that

Unfortunately, given the context of a citation like this, it really 
needs much greater precision, to point the reader to the exact portion 
of the document that is relevant to this context.

Unless, of course, the premise of the current document is that the 
reader must be deeply familiar with the -core document.  In which case, 
/that's/ what should be specified early in this document.  Based on what 
follows, I fear that indeed, this document requires deep familiarity 
with -core.


>    the XMPP server has determined the domain is serviced by a SIMPLE
>    server, that it contains or has available to it an XMPP-SIMPLE
>    gateway or connection manager (which enables it to speak natively to
>    SIMPLE servers), and that it hands off the presence stanza to the
>    XMPP-SIMPLE gateway.
>
>    The XMPP-SIMPLE gateway is then responsible for translating the XMPP
>    subscription request into a SIP SUBSCRIBE request from the XMPP user
>    to the SIP user:
>
>    Example 2: XMPP user subscribes to SIP contact (SIP transformation):

It took a moment to decide whether I was looking at XMPP form or SIP 
form.  Perhaps a more helpufl title for the example would be something like:

      Example 2: Translation of XMPP user's subscription request into SIP


>    |  SUBSCRIBE sip:romeo@example.net SIP/2.0

Later text (section 4.1) equates the label pres: with sip: and sips:. 
Why choose sip: here?


>    |  Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk
>    |  From: <sip:juliet@example.com>;tag=ffd2
>    |  Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C
>    |  Event: presence
>    |  Max-Forwards: 70
>    |  CSeq: 123 SUBSCRIBE
>    |  Contact: <sip:x2s.example.com;transport=tcp>
>    |  Accept: application/pidf+xml
>    |  Expires: 3600
>    |  Content-Length: 0
>
>    The SIP user then SHOULD send a response indicating acceptance of the
>    subscription request:
>
>    Example 3: SIP accepts subscription request:
>
>    |  SIP/2.0 200 OK
>    |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>    |  From: <sip:romeo@example.net>;tag=ffd2
>    |  To: <sip:juliet@example.com>;tag=j89d
>    |  Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C
>    |  CSeq: 234 SUBSCRIBE
>    |  Contact: <sip:simple.example.net;transport=tcp>
>    |  Expires: 3600
>    |  Content-Length: 0

Hmmm.  This appears to be the original SIP acceptance, but with no 
separate display of it's being translated into XMPP.


>
> Saint-Andre, et al.      Expires April 21, 2014                 [Page 5]
> 
> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>
>
>    In accordance with [RFC6665], the XMPP-SIMPLE gateway SHOULD consider
>    the subscription state to be "neutral" until it receives a NOTIFY
>    message.  Therefore the SIP user or SIP-XMPP gateway at the SIP
>    user's domain SHOULD immediately send a NOTIFY message containing a
>    "Subscription-State" header whose value contains the string "active"
>    (see Section 4).
>
>    Example 4: SIP user sends presence notification:
>
>    |  NOTIFY sip:192.0.2.1 SIP/2.0
>    |  Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk
>    |  From: <sip:romeo@example.net>;tag=yt66
>    |  To: <sip:juliet@example.com>;tag=bi54
>    |  Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C
>    |  Event: presence
>    |  Subscription-State: active;expires=499
>    |  Max-Forwards: 70
>    |  CSeq: 8775 NOTIFY
>    |  Contact: <sip:simple.example.net;transport=tcp>
>    |  Content-Type: application/pidf+xml
>    |  Content-Length: 193
>    |
>    |  <?xml version='1.0' encoding='UTF-8'?>
>    |  <presence xmlns='urn:ietf:params:xml:ns:pidf'
>    |            entity='pres:romeo@example.net'>
>    |    <tuple id='ID-orchard'>
>    |      <status>
>    |        <basic>open</basic>
>    |        <show xmlns='jabber:client'>away</show>
>    |      </status>
>    |    </tuple>
>    |  </presence>

Where is the xmpp translation of this?


>    In response, the SIMPLE-XMPP gateway would send a 200 OK (not shown

Sent it to whom?  (I probably know the answer, but the reader shouldn't 
have to guess; this is a spec.)


>    here since it is not translated into an XMPP stanza).
>
>    Upon receiving the first NOTIFY with a subscription state of active,
>    the XMPP-SIMPLE gateway MUST generate a presence stanza of type
>    "subscribed":
>
>    Example 5: XMPP user receives acknowledgement from SIP contact:
>
>    |  <presence from='romeo@example.net'
>    |            to='juliet@example.com'
>    |            type='subscribed'/>
>
>    As described under Section 4, the gateway MUST also generate a
>    presence notification to the XMPP user:
>
>
> Saint-Andre, et al.      Expires April 21, 2014                 [Page 6]
> 
> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>
>
>    Example 6: XMPP user receives presence notification from SIP contact:
>
>    |  <presence from='romeo@example.net/orchard'
>    |            to='juliet@example.com'/>


This sequence feels like it should have a protocol sequence diagram, of 
the type used in rfc5263.


> 3.2.3.  Cancelling a Presence Subscription
>
>    At any time after subscribing, the XMPP user can unsubscribe from the
>    contact's presence.  This is done by sending a presence stanza of
>    type "unsubscribe":
>
>    Example 7: XMPP user unsubscribes from SIP contact:
>
>    |  <presence from='juliet@example.com'
>    |            to='romeo@example.net'
>    |            type='unsubscribe'/>
>
>    The XMPP-SIMPLE gateway is responsible for translating the
>    unsubscribe command into a SIP SUBSCRIBE request with the "Expires"
>    header set to a value of zero:
>
>    Example 8: XMPP user unsubscribes from SIP contact (SIP
>    transformation):
>
>    |  SUBSCRIBE sip:romeo@example.net SIP/2.0
>    |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>    |  From: <sip:juliet@example.com>;tag=j89d
>    |  Call-ID: 9D9F00DF-FCA9-4E7E-B970-80B638D5218A
>    |  Event: presence
>    |  Max-Forwards: 70
>    |  CSeq: 789 SUBSCRIBE
>    |  Contact: <sip:x2s.example.com;transport=tcp>
>    |  Accept: application/pidf+xml
>    |  Expires: 0
>    |  Content-Length: 0
>
>
>
> Saint-Andre, et al.      Expires April 21, 2014                 [Page 7]
> 
> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>
>
>    Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway
>    SHOULD send a presence stanza of type "unsubscribed" to the XMPP
>    user:
>
>    Example 9: XMPP user receives unsubscribed notification:
>
>    |  <presence from='romeo@example.net'
>    |            to='juliet@example.com'
>    |            type='unsubscribed'/>


One of the advantages of showing sequences like these in a protocol 
sequence diagram is that it concisely shows which of the 4 actors does 
what and when.  Being able to see visual summaries like that will make 
the life of an implementer /much/ easier.


> 3.3.  SIP to XMPP
>
> 3.3.1.  Establishing a Presence Subscription
>
>    A SIP user initiates a subscription to a contact's presence
>    information by sending a SIP SUBSCRIBE request to the contact.  The
>    following is an example of such a request:
>
>    Example 10: SIP user subscribes to XMPP contact:
>
>    |  SUBSCRIBE sip:juliet@example.com SIP/2.0
>    |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>    |  From: <sip:romeo@example.net>;tag=xfg9
>    |  Call-ID: AA5A8BE5-CBB7-42B9-8181-6230012B1E11
>    |  Event: presence
>    |  Max-Forwards: 70
>    |  CSeq: 263 SUBSCRIBE
>    |  Contact: <sip:simple.example.net;transport=tcp>
>    |  Accept: application/pidf+xml
>    |  Content-Length: 0
>
>    Notice that the "Expires" header was not included in the SUBSCRIBE
>    request; this means that the default value of 3600 (i.e., 3600
>    seconds = 1 hour) applies.
>
>    Upon receiving the SUBSCRIBE, the SIP server needs to determine the
>    identity of the domain portion of the Request-URI or To header, which
>    it does by following the procedures discussed in
>    [I-D.ietf-stox-core].  Here we assume that the SIP server has
>    determined that the domain is serviced by an XMPP server, that it


This seems to mean that a regular SIP server needs to be familiar with 
technical details in a gatewaying specification??


>    Example 11: SIP user subscribes to XMPP contact (XMPP
>    transformation):
>
>    |  <presence from='romeo@example.net'
>    |            to='juliet@example.com'
>    |            type='subscribe'/>
>
>    In accordance with [RFC6121], the XMPP user's server MUST deliver the
>    presence subscription request to the XMPP user (or, if a subscription
>    already exists in the XMPP user's roster, send a presence stanza of
>    type 'subscribed').
>
>    If the XMPP user approves the subscription request, the XMPP server
>    then MUST return a presence stanza of type "subscribed" from the XMPP
>    user to the SIP user; if a subscription already exists, the XMPP

The XMPP server does not communicate (directly) with the SIP user.  It 
has to go through one or both gateways.  (From the architectural 
diagram, I assume the sequence is through both.)  This spec needs to be 
very careful to identify what entity is talking with what entity 
directly and who is mediating, when it isn't direct.


> 3.3.2.  Refreshing a Presence Subscription
>
>    For as long as a SIP user is online and interested in receiving
>    presence notifications from the XMPP users, the user's SIP user agent
>    is responsible for periodically refreshing the subscription by
>    sending an updated SUBSCRIBE request with an appropriate value for

sending it to which actor directly?


>    the Expires header.  In response, the SIMPLE-XMPP gateway MUST send a
>
>
>
> Saint-Andre, et al.      Expires April 21, 2014                 [Page 9]
> 
> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>
>
>    SIP NOTIFY to the user agent (per [RFC6665]; if the gateway has
>    meaningful information about the availability state of the XMPP user

This prompts the thought that early in the document, there should 
probably be some discussion about what state information needs to be 
maintained in the gateways.


>    then the NOTIFY MUST communicate that information (e.g., by including
>    a PIDF body [RFC3863] with the relevant data), whereas if the gateway
>    does not have meaningful information about the availability state of
>    the XMPP user then the NOTIFY MUST be empty as allowed by [RFC6665].
>
>    Once the SIP user goes offline at the end of a presence session, it

"goes offline" seems odd phrasing here; I'm not entirely sure what it 
means.  isn't the simple point that the SIP user terminates the presence 
session (for whatever reason)?  If the point is that the SIP user 
literally disappears from the session -- again, there are lots of 
possible reasons, where 'going offline' is only one -- some language 
like that might work better.



> 4.1.  Overview

In general, this overview (4.1) section seems odd to have appear so late 
in the document.  Everything in it feels like stuff that should be in 
Section 1, not Section 4.


>    Both XMPP and presence-aware SIP systems enable entities (often but
>    not necessarily human users) to send presence notifications to other
>    entities.  At a minimum, the term "presence" refers to information
>    about an entity's availability for communication on a network (on/
>    off), often supplemented by information that further specifies the
>    entity's communications context (e.g., "do not disturb").  Some
>    systems and protocols extend this notion even further and refer to
>    any relatively ephemeral information about an entity as a kind of
>    presence; categories of such "extended presence" include geographical

The above text seems a bit confusing.  First it distinguishes between 
presence and status, and then describes something which is both as 
'extended status.'

Here's my guess about what is needed:

1. Very narrow and precise use of the term presence; I think that means 
it only mean "connected to a presence service", or somesuch.

2. Consistent distinction of presence-related attributes, like do not 
disturb.  What's missing here is a simple term for it.

3. Clarity that "ephemeral information about an entity" is probably a 
form of #2, rather than #1.  That is, I think it's a presence attribute, 
rather than "a presence".

And if I've gotten this entirely confused, then that means the text 
needs a different kind of fixing...


>    location (e.g., GPS coordinates), user mood (e.g., grumpy), user
>    activity (e.g., walking), and ambient environment (e.g., noisy).  In
>    this document, we focus on the "least common denominator" of network
>    availability only, although future documents might address broader
>    notions of presence, including extended presence.
>
>
>
>
> Saint-Andre, et al.      Expires April 21, 2014                [Page 12]
> 
> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>
>
>    [RFC6121] defines how XMPP presence stanzas can indicate availability
>    (via absence of a 'type' attribute) or lack of availability (via a
>    'type' attribute with a value of "unavailable").  SIP presence using
>    a SIP event package for presence is specified in [RFC3856].
>
>    As described in [RFC6121], presence information about an entity is

    information -> XMPP information


>    communicated by means of an XML <presence/> stanza sent over an XML
>    stream.  In this document we will assume that such a presence stanza
>    is sent from an XMPP client to an XMPP server over an XML stream
>    negotiated between the client and the server, and that the client is
>    controlled by a human user (again, this is a simplifying assumption
>    introduced for explanatory purposes only).  In general, XMPP presence
>    is sent by the user to the user's server and then broadcasted to all
>    entities who are subscribed to the user's presence information.

http://www.dailywritingtips.com/broadcast-vs-broadcasted-as-past-form/

In spite of having some formal linguistic legitimacy, I suggest using 
'broadcast'.


>
>    As described in [RFC3856], presence information about an entity is
>    communicated by means of a SIP NOTIFY event sent from a SIP user
>    agent to an intended recipient who is most generally referenced by an
>    Presence URI of the form <pres:user@domain> but who might be
>    referenced by a SIP or SIPS URI of the form <sip:user@domain> or
>    <sips:user@domain>.  Here again we introduce the simplifying
>    assumption that the user agent is controlled by a human user.

I guess I'm not understanding how the nature of what is controlling the 
agent affects anything in this document.  Might be worth explaining that.



> 4.2.  XMPP to SIP
>
>    When Juliet interacts with her XMPP client to modify her presence
>    information (or when her client automatically updates her presence
>    information, e.g. via an "auto-away" feature), her client generates
>    an XMPP <presence/> stanza.  The syntax of the <presence/> stanza,
>    including required and optional elements and attributes, is defined
>    in [RFC6121].  The following is an example of such a stanza:
>
>    Example 17: XMPP user sends presence notification:
>
>    |  <presence from='juliet@example.com/balcony'/>
>
>    Upon receiving such a stanza, the XMPP server to which Juliet has
>    connected broadcasts it to all subscribers who are authorized to
>    receive presence notifications from Juliet (this is similar to the
>    SIP NOTIFY method).  For each subscriber, broadcasting the presence
>    notification involves either delivering it to a local recipient (if
>    the hostname in the subscriber's address matches one of the hostnames
>    serviced by the XMPP server) or attempting to route it to the foreign
>    domain that services the hostname in the subscriber's address.  Thus
>
>
>
> Saint-Andre, et al.      Expires April 21, 2014                [Page 13]
> 
> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>
>
>    the XMPP server needs to determine the identity of the domainpart in
>    the 'to' address, which it does by following the procedures discussed
>    in [I-D.ietf-stox-core].  Here we assume that the XMPP server has
>    determined the domain is serviced by a SIMPLE server, that it

again, the idea that a pure xmpp server can 'know' about a simple 
destination doesn't make sense to me.  (And by that way, is it simple or 
is it sip...? Note that the term 'simple' hasn't been getting used in 
this document.)

at a minimum, this is a good place to repeat the pointer to text that 
explains how gateways are operational fit into two native networks, 
where their nature is transparent -- that is, with the native entities 
thinking they are merely talking to other native entities.


>    contains or has available to it an XMPP-SIMPLE gateway or connection
>    manager (which enables it to speak natively to SIMPLE servers), and
>    that it hands off the presence stanza to the XMPP-SIMPLE gateway.
>
>    The XMPP-SIMPLE gateway is then responsible for translating the XMPP
>    presence stanza into a SIP NOTIFY request and included PIDF document
>    from the XMPP user to the SIP user.
>
>    Example 18: XMPP user sends presence notification (SIP
>    transformation):
>
>    |  NOTIFY sip:192.0.2.2 SIP/2.0
>    |  Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk
>    |  From: <sip:juliet@example.com>;tag=gh19
>    |  To: <sip:romeo@example.net>;tag=yt66
>    |  Contact: <sip:juliet@example.com>;gr=balcony
>    |  Call-ID: 2B44E147-3B53-45E4-9D48-C051F3216D14
>    |  Event: presence
>    |  Subscription-State: active;expires=599
>    |  Max-Forwards: 70
>    |  CSeq: 157 NOTIFY
>    |  Contact: <sip:x2s.example.com;transport=tcp>
>    |  Content-Type: application/pidf+xml
>    |  Content-Length: 192
>    |
>    |  <?xml version='1.0' encoding='UTF-8'?>
>    |  <presence xmlns='urn:ietf:params:xml:ns:pidf'
>    |            entity='pres:juliet@example.com'>
>    |    <tuple id='ID-balcony'>
>    |      <status>
>    |        <basic>open</basic>
>    |        <show xmlns='jabber:client'>away</show>
>    |      </status>
>    |    </tuple>
>    |  </presence>
>
>    The mapping of XMPP syntax elements to SIP syntax elements SHOULD be
>    as shown in the following table.  (Mappings for elements not
>    mentioned are undefined.)
>
>
>
>
>
>
>
>
> Saint-Andre, et al.      Expires April 21, 2014                [Page 14]
> 
> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>
>
>    Table 1: Presence syntax mapping from XMPP to SIP
>
>       +-----------------------------+---------------------------+
>       |  XMPP Element or Attribute  |  SIP Header or PIDF Data  |
>       +-----------------------------+---------------------------+
>       |  <presence/> stanza         |  "Event: presence" (1)    |
>       |  XMPP resource identifer    |  tuple 'id' attribute (2) |
>       |  from                       |  From                     |
>       |  id                         |  CSeq (3)                 |
>       |  to                         |  To                       |
>       |  type                       |  basic status (4) (5)     |
>       |  xml:lang                   |  Content-Language         |
>       |  <priority/>                |  priority for tuple (6)   |
>       |  <show/>                    |  no mapping (7)           |
>       |  <status/>                  |  <note/>                  |
>       +-----------------------------+---------------------------+

The format of this makes the table reads as two (unsynchronized) 
columns, rather than a series of rows.

I suggest different formatting, such as (in spite of it's being longer:


         +-----------------------------+---------------------------+
         |  XMPP Element or Attribute  |  SIP Header or PIDF Data  |
         +-----------------------------+---------------------------+
         |  <presence/  stanza            "Event: presence" (1)    |
         +-----------------------------+---------------------------+
         |  XMPP resource identifer       tuple 'id' attribute (2) |
         +-----------------------------+---------------------------+
         |  from                          From                     |
         +-----------------------------+---------------------------+
         |  id                            CSeq (3)                 |
         +-----------------------------+---------------------------+
         |  to                            To                       |
         +-----------------------------+---------------------------+
         |  type                          basic status (4) (5)     |
         +-----------------------------+---------------------------+
         |  xml:lang                      Content-Language         |
         +-----------------------------+---------------------------+
         |  <priority/>                   priority for tuple (6)   |
         +-----------------------------+---------------------------+
         |  <show/>                       no mapping (7)           |
         +-----------------------------+---------------------------+
         |  <status/>                     <note/>                  |
         +-----------------------------+---------------------------+

>    Note the following regarding these mappings:
>
>    1.  Only a presence stanza that lacks a 'type' attribute or whose

    presence -> XMPP presence


>        'type' attribute has a value of "unavailable" SHOULD be mapped by
>        an XMPP-SIMPLE gateway to a SIP NOTIFY request, since those are
>        the only presence stanzas that represent notifications.
>    2.  The PIDF schema defines the tuple 'id' attribute as having a
>        datatype of "xs:ID"; because this datatype is more restrictive
>        than the "xs:string" datatype for XMPP resourceparts (in
>        particular, a number is not allowed as the first character of an
>        ID), it is RECOMMENDED to prepend the resourcepart with "ID-" or
>        some other alphabetic string when mapping from XMPP to SIP.
>    3.  This mapping is OPTIONAL.

What does that mean?  This sort of mapping is usually the essence of 
gatewaying semantics.  How can interoperability tolerate it's being 
optional?



> 4.3.  SIP to XMPP
>
>    When Romeo changes his presence, his SIP user agent generates a SIP

Romeo is doing SIP?  And Juliet does XMPP?

So, SIP is more macho than XMPP???




d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

From saul@ag-projects.com  Thu Dec 12 01:24:14 2013
Return-Path: <saul@ag-projects.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218B31AE09D for <stox@ietfa.amsl.com>; Thu, 12 Dec 2013 01:24:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.389
X-Spam-Level: 
X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maI3a3h958X3 for <stox@ietfa.amsl.com>; Thu, 12 Dec 2013 01:24:12 -0800 (PST)
Received: from mail3.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0AABF1AE208 for <stox@ietf.org>; Thu, 12 Dec 2013 01:24:11 -0800 (PST)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail3.sipthor.net (Postfix) with ESMTPSA id 07B9D14AC003; Thu, 12 Dec 2013 10:30:17 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
In-Reply-To: <52799DF7.9080803@stpeter.im>
Date: Thu, 12 Dec 2013 10:24:02 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C72EAFC5-62D8-40C7-A866-17714D6DEA11@ag-projects.com>
References: <1B5D6CBE-2151-4749-8A7C-8122B04BB071@ag-projects.com> <52799DF7.9080803@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1085)
Cc: stox@ietf.org
Subject: Re: [Stox] On generating RFC4575 participants list out of a MUC
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 09:24:14 -0000

I finally managed to update the goupchat draft with this :-)

It's on the IETF svn repo, can you take a look.

I don't have any other open issues on my list.


Cheers,

On Nov 6, 2013, at 2:40 AM, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Hi Sa=FAl!
>=20
> On 10/25/13 1:38 AM, Sa=FAl Ibarra Corretg=E9 wrote:
>> Hi all,
>>=20
>> This is regarding the issue I mentioned at the meeting in Berlin
>> to which Peter referred recently.
>>=20
>> In 4575 there are 2 types of entities which kind of relate to=20
>> participants: users and endpoints. Each user contains a list of=20
>> endpoints. As per the RFC:
>>=20
>> - "The <users> element is a container of <user> child elements,
>> each describing a single participant in the conference."
>>=20
>> - "By including one or more <endpoint> elements under a parent=20
>> <user> element, the server can provide the desired level of detail
>> (including the state, media streams, and access information) about
>> the user's devices and signaling sessions taking part in the=20
>> conference."
>>=20
>> In SIP a user would be an AoR and an endpoint would be the contact
>> or GRUU.
>>=20
>> In XMPP tough, things are a bit more complicated. In the beginning
>> I thought we could use the user bare JID as the <user> element and
>> the occupant JID as the <endpoint>, but in practice this is not
>> going to work, because the real JID is not always available in a
>> MUC.
>>=20
>> So, considering that, here is how I propose we proceed:
>>=20
>> - <user> element entity is the occupant JID - if the real JID is=20
>> available, it MAY be added as a <associated-aors> child element of=20
>> <user> (4575, sec 5.6.2) (based on local policy) - <endpoint>
>> entity is also the occupant JID
>>=20
>> Neither user entity or endpoint entity is an xs:ID, so using it in=20
>> both places doesn't invalidate the document :-)
>>=20
>> Thoughts?
>=20
> Your analysis looks reasonable to me, and I think that's the best we
> can do given the information that will usually be available in an XMPP
> multi-user chat room.
>=20
> Peter
>=20
> - --=20
> Peter Saint-Andre
> https://stpeter.im/
>=20
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>=20
> iQIcBAEBAgAGBQJSeZ32AAoJEOoGpJErxa2pXOEQALM+zCq83LaE82YTP4Hzar/g
> Jd5zRksJdrj32yVX2sEvO2pF7Zmi+4lHN6NTlJ+y219pTox4sB+BPFK89viRjyG/
> J5tdfruQ9A4ugKV+DGw9l9ddO5od7CVvjwSqalBI+n0xApuC+acpLKspA7uuKsfu
> 4qRVborWHAm/FL0whklSDduBeFaaVFibH/OGEIRkf7vldTiNaGV0POsbDTx8uHlf
> 1eHYvonkeGYDTRcWC2/Ry6KBCFN2fN+s43PFqkaAHjIkDoFZNUGcx0enyAQ5TjUW
> tP3uniGrayVYbgcx2M4HYelkPJSCKAxXELJZODWEL8xKvFC5zsnsId9XqaY1iszf
> fiwDCjGoeUWDzrcxU7PWv4L+7MFCQmZv06EXphWBLEzDU05nNbHsBVBovlLyu88l
> bjGyg8+RJyOeh0F1l4zx0aiHV2EB4K7PshPsBG+kCSvx2ApFf9sKn6zAvECc0d//
> DAYYwjftD1v6gR5Fv2wlbN147xdWJKGTBtGFBC44P3+FyadZNj5wxD6Z0+kOESV8
> mbSlVNntJFE2T7Iw1Td2LtHj+aPaarxZ/6SL4xs0gMk7sOv366z1eHzmyPlBC24V
> NKuw0MzBfEwgLEXOL3u1LqLSII13+MnmqsBuyogBe+L9J/cN3rpOxtFN6r4XhPVp
> VReUows2wtCw6gyQ96CZ
> =3DTmo1
> -----END PGP SIGNATURE-----
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From stpeter@stpeter.im  Thu Dec 12 05:41:39 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325841AE2D4 for <stox@ietfa.amsl.com>; Thu, 12 Dec 2013 05:41:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.603
X-Spam-Level: 
X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0fz831HaXM5 for <stox@ietfa.amsl.com>; Thu, 12 Dec 2013 05:41:37 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D88FE1AE2C4 for <stox@ietf.org>; Thu, 12 Dec 2013 05:41:37 -0800 (PST)
Received: from sjc-vpn5-1487.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8CC9C4010C; Thu, 12 Dec 2013 06:41:31 -0700 (MST)
Message-ID: <52A9BD0A.60605@stpeter.im>
Date: Thu, 12 Dec 2013 06:41:30 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
References: <1B5D6CBE-2151-4749-8A7C-8122B04BB071@ag-projects.com> <52799DF7.9080803@stpeter.im> <C72EAFC5-62D8-40C7-A866-17714D6DEA11@ag-projects.com>
In-Reply-To: <C72EAFC5-62D8-40C7-A866-17714D6DEA11@ag-projects.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: stox@ietf.org
Subject: Re: [Stox] On generating RFC4575 participants list out of a MUC
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 13:41:39 -0000

On 12/12/13 2:24 AM, Saúl Ibarra Corretgé wrote:
> I finally managed to update the goupchat draft with this :-)
> 
> It's on the IETF svn repo, can you take a look.

Will do later today or tonight.

> I don't have any other open issues on my list.

Me, neither.

Onward and upward! :-)

Peter

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



From internet-drafts@ietf.org  Thu Dec 12 09:41:54 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFA31AE34E; Thu, 12 Dec 2013 09:41:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sqy7W87fIpt; Thu, 12 Dec 2013 09:41:52 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F4D1ADF12; Thu, 12 Dec 2013 09:41:52 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131212174152.396.53393.idtracker@ietfa.amsl.com>
Date: Thu, 12 Dec 2013 09:41:52 -0800
Cc: stox@ietf.org
Subject: [Stox] I-D Action: draft-ietf-stox-groupchat-02.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 17:41:54 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.

	Title           : Interworking between the Session Initiation Protocol (SI=
P) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat
	Author(s)       : Peter Saint-Andre
                          Saul Ibarra
                          Salvatore Loreto
	Filename        : draft-ietf-stox-groupchat-02.txt
	Pages           : 34
	Date            : 2013-12-12

Abstract:
   This document defines a bidirectional protocol mapping for the
   exchange of instant messages in the context of a multiparty chat
   session among users of the Session Initiation Protocol (SIP) and
   users of the Extensible Messaging and Presence Protocol (XMPP).
   Specifically, this document defines a mapping between the SIP-based
   Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat
   (MUC) extension.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-stox-groupchat

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-stox-groupchat-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-groupchat-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Thu Dec 12 10:26:27 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8511AE369; Thu, 12 Dec 2013 10:26:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYqyvTvAZgTs; Thu, 12 Dec 2013 10:26:25 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B511AE3A5; Thu, 12 Dec 2013 10:26:25 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131212182625.7247.96401.idtracker@ietfa.amsl.com>
Date: Thu, 12 Dec 2013 10:26:25 -0800
Cc: stox@ietf.org
Subject: [Stox] I-D Action: draft-ietf-stox-media-02.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 18:26:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.

	Title           : Interworking between the Session Initiation Protocol (SI=
P) and the Extensible Messaging and Presence Protocol (XMPP): Media Session=
s.
	Author(s)       : Peter Saint-Andre
                          Saul Ibarra
                          Emil Ivov
	Filename        : draft-ietf-stox-media-02.txt
	Pages           : 21
	Date            : 2013-12-12

Abstract:
   This document defines a bi-directional protocol mapping for use by
   gateways that enable the exchange of media signalling messages
   between systems that implement the Jingle extensions to the
   Extensible Messaging and Presence Protocol (XMPP) and those that
   implement the Session Initiation Protocol (SIP).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-stox-media

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-stox-media-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-media-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From stpeter@stpeter.im  Fri Dec 13 14:47:20 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2D61AE448; Fri, 13 Dec 2013 14:47:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.196
X-Spam-Level: *
X-Spam-Status: No, score=1.196 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rijBw6ZfBwTK; Fri, 13 Dec 2013 14:47:16 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A022D1AE44F; Fri, 13 Dec 2013 14:47:14 -0800 (PST)
Received: from ergon.local (unknown [64.101.72.104]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7DA3E4010C; Fri, 13 Dec 2013 15:47:06 -0700 (MST)
Message-ID: <52AB8E69.7070906@stpeter.im>
Date: Fri, 13 Dec 2013 15:47:05 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: dcrocker@bbiw.net, Apps Discuss <apps-discuss@ietf.org>,  draft-ietf-stox-presence.all@tools.ietf.org, stox@ietf.org
References: <52A94AF6.8090702@dcrocker.net>
In-Reply-To: <52A94AF6.8090702@dcrocker.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: iesg <iesg@ietf.org>
Subject: Re: [Stox] Review of:  draft-ietf-stox-presence-06
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Dec 2013 22:47:21 -0000

Hi Dave, thank you for the review. Comments inline. I have not yet
proposed text for the issues you raise, because that will take more time.

On 12/11/13 10:34 PM, Dave Crocker wrote:
> 
> G'day.
> 
> I have been selected as the Applications Area Review Team reviewer for
> this draft (for background on apps-review, please see
> http://www.apps.ietf.org/content/applications-area-review-team).
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> 
> 
> Review of:    Interworking between the Session Initiation Protocol (SIP)
> and the
>               Extensible Messaging and Presence Protocol (XMPP): Presence
> I-D:          draft-ietf-stox-presence-06
> 
> Reviewer:     D. Crocker
> Review date:  12 Dec 13
> 
> 
> 
> Summary:
> 
> XMPP and SIP both have deployed versions of instant messaging and
> presence.  The current draft is part of a set of specifications that
> define a gateway capability between the the two services.  In
> particular, the current draft specifies the translation mechanism
> between the presence mechanisms used by SIP and XMPP.
> 
> The draft is well-structured and the text is mostly clear.  For an
> implementer already familiar with the details of the two services and
> the basics of the gatewaying specified here, the document probably is
> sufficient -- although responses to some of the detailed comments,
> below, might to turn out to show that a bit more work is needed. However
> at the most, any technical improvements that might be needed will be
> minor.  And I expect these to more in the nature of clarifying language
> than of changing bits over the wire.
> 
> However for a reader who is new to the topic, the document needs to be
> clearer and sometimes more complete.
> 
> Specific changes or concerns:
> 
>    1.  When citing the earlier efforts, there should be something to
> explain why the current work is expected to be more successful. 

Not "expected", but "is". :-) AFAIK there are no implementations of the
approach taken by RFC 3922 and draft-ietf-simple-cpim-mapping (i.e.,
mapping to the abstract semantics of RFC 3860), whereas there are
multiple implementations of the approach described here (i.e., direct
mapping between SIP and XMPP).

> That is,
> what makes the current approach notably tractable for implementation and
> deployment?

Do you think that explaining why would improve the document? IMHO this
verges into developer psychology (I've got this SIP thing here and this
XMPP thing there, let me see how I can make them work as easily as
possible without venturing off into abstract semantic stuff).

>    2.  The document is not clear about the prerequisites for reading
> this draft.  What must the reader already know in depth?  What must they
> have at least superficial knowledge of?  I suspect that, in particular,
> they need deep familiarity with stox-core.

At the very least. Also RFC 3261, RFC 3856, RFC 6120, and RFC 6121.
(Note: the total page count of those RFCs is 621.) The specifications
normatively referenced by RFC 3856 are also relevant.

>    3.  Saying that terms are taken from a substantial number of other
> documents, and then merely citing the documents in their entirety, is
> not helpful to the reader, unless the reader is required to be deeply
> familiar with those documents. 

I do think it's required.

> If that's what this document requires,
> say that.  If it's not, I suggest listing terms explicitly and
> indicating what document they are drawn from.
> 
>    4.  As the architecture diagram in Section 3 of stox-core shows, this
> service has at least separate actors Actually I think it actually has at
> least 6, which that diagram probably should show explicitly.  The six are:
> 
>        a. SIP user
>        b. SIP server
>        c. SIP-XMPP gateway
>        d. XMPP-SIP gateway
>        e. XMPP server
>        f. XMPP user
> 
>        In any event, the specification needs to be very diligent to
> carefully identify each actor involved in an activity and the
> interaction between actors.  The current document uses language that
> often left me wondering such things as who was the target of the action.
> 
>        Much of this would be aided by some form of protocol sequence
> diagrams, to show who does what and in what order.

I'll review the document again with these comments in mind. Your
suggestion of sequence diagrams is a good one.

>    5.  When showing protocol examples, usually only one side of the
> sequence is shown.  For gatewaying that does interesting transforms,
> such as this one, an example should show both the before and after
> versions.  That is, the 'native' protocol unit that was created and then
> the one that results from the translation.

I thought we'd already done that. For instance, Example 2 is the SIP
transformation of the XMPP stanza shown in Example 1.

> Detailed Comments:
> 
> 
>> Table of Contents
> 
> 
> Nicely organized and concise TOC [ie, document structure).
> 
> 
> 
>> 1.  Introduction
> ...
>>    One approach to helping ensure interworking between these protocols
>>    is to map each protocol to the abstract semantics described in
>>    [RFC3860]; that is the approach taken by both [RFC3922] and
>>    [I-D.ietf-simple-cpim-mapping].  The approach taken in this document
>>    is to directly map semantics from one protocol to another (i.e., from
>>    SIP/SIMPLE to XMPP and vice-versa).
> 
> This begs the obvious question:  Why?  What was wrong with the previous
> approach?

No one implemented it. The running code all takes the direct gatewaying
approach.

> The purpose of the question is not for criticizing prior work but to
> understand the expected benefit of the approach taken in the current
> work.  What are the function, or OA&M differences produced through this
> new approach, that are expected to be helpful?

These documents describe what people do in the field, what works and
what doesn't, etc. We're not saying that other approaches are bad or
infeasible.

>>    The architectural assumptions underlying such direct mappings are
>>    provided in [I-D.ietf-stox-core], including mapping of addresses and
>>    error conditions.  The mappings specified in this document cover
>>    basic presence functionality.  Mapping of more advanced functionality
>>    (e.g., so-called "rich presence") is out of scope for this document.
>>
>>    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.
>>
>>
>> 2.  Terminology
>>
>>    A number of terms used here are explained in [RFC3261], [RFC3856],
>>    [RFC6120], and [RFC6121].
> 
> This sentence probably implies that the current draft should not be read
> in the absence of familiarity with all 4 of those RFCs.  I suggest some
> sort of explicit statement about how much prior knowledge is needed for
> understanding the current draft, and where to get that knowledge.

Agreed.

> In purely mechanical terms, the problem with the above sentence is that
> it means that when the reader sees a term they don't understand, they
> have to run around to four different documents looking for definitions.
>  This mostly ensures reader frustration, for everyone but experts.
> 
> The cleanest fix for this is to list terms and where they are defined.
> The other, usual fix is to indeed say that the reader must be familiar
> with those other documents before reading this one.  (sigh.)

I think these documents are for experts. In all likelihood, members of
the target audience already have a SIP implementation and need to
connect it to the XMPP network, or vice-versa. I don't think someone who
is not familiar with either SIP or XMPP (or both) is going to hack up a
gateway. There are much more rewarding tasks one might choose.

To your point, we need to say that.

>> 3.1.  Overview
> ...
>>    As described in [RFC6121], XMPP presence subscriptions are managed
>>    using XMPP presence stanzas of type "subscribe", "subscribed",
>>    "unsubscribe", and "unsubscribed".  The main subscription states are
>>    "none" (neither the user nor the contact is subscribed to the other's
>>    presence information), "from" (the user has a subscription from the
>>    contact), "to" (the user has a subscription to the contact's presence
>>    information), and "both" (both user and contact are subscribed to
>>    each other's presence information).
> 
> Nit:  for technical documents, lists like the above should be shown in
> list format.  It really does help for quick comprehension.

Will fix.

>>    As described in [RFC3856], SIP presence subscriptions are managed
>>    through the use of SIP SUBSCRIBE events sent from a SIP user agent to
>>    an intended recipient who is most generally referenced by a Presence
>>    URI of the form <pres:user@domain> but who might be referenced by a
>>    SIP or SIPS URI of the form <sip:user@domain> or <sips:user@domain>.
>>
>>    The subscription models underlying XMPP and SIP are quite different.
>>    For instance, XMPP presence subscriptions are long-lived (indeed
>>    permanent if not explicitly cancelled), whereas SIP presence
>>    subscriptions are short-lived (the default time-to-live of a SIP
>>    presence subscription is 3600 seconds, as specified in Section 6.4 of
>>    [RFC3856]).  These differences are addressed below.
> 
> The text that follows this 'addresses' the differences in terms of
> specifying how to handle specific differences.
> 
> What's missing -- but I think would aid for the framework of this
> document's effort -- is for the above "For instance" to instead be
> expanded into a detailed statement of what the differences are, separate
> from the later text that says how to deal with the differences.

That "for instance" is the main thing, so you're right that it needs to
be described in more detail.

> Someone needing to implement this spec, probably will be starting with a
> reasonable model of one side -- or at least, reasonable knowledge of the
> details, if not a thoughtful, higher-level model -- and considerable
> ignorance of the other. Text that discusses details of differences,
> distinct from how to resolve them, will put the implementer into a
> better position of understanding what's being done.
> 
> This probably raises a larger issue:  How much expertise is expected of
> someone who is implementing this or otherwise reading for deep
> comprehension?  In the extreme, they will need to have serious expertise
> on both protocol sets.  The other extreme would be a cookbook inside
> this document, with no outside knowledge required.  The document needs
> to specify the nature and extent of the expertise required.  (In fact,
> the document seems pretty clean, in terms of explaining things, so I
> suspect that 'fair' knowledge of one suite will suffice.  But the author
> and wg beliefs about the requirement should be made explicit.)

See above. Perhaps not expert level, but significant familiarity with
one "side" or the other.

>> 3.2.  XMPP to SIP
>>
>> 3.2.1.  Establishing a Presence Subscription
>>
>>    An XMPP user (e.g., juliet@example.com) initiates a subscription by
>>    sending a subscription request to another entity (e.g.,
>>    romeo@example.net), and the other entity (conventionally called a
> 
> Move definition of contact up to first occurrence, above.

Yes.

>>    "contact") either accepts or declines the request.  If the contact
>>    accepts the request, the user will have a subscription to the
>>    contact's presence information until (1) the user unsubscribes or (2)
>>    the contact cancels the subscription.  The subscription request is
>>    encapsulated in a presence stanza of type "subscribe":
>>
>>
>>
>>
>> Saint-Andre, et al.      Expires April 21, 2014                 [Page 4]
>> 
>> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>>
>>
>>    Example 1: XMPP user subscribes to SIP contact:
>>
>>    |  <presence from='juliet@example.com'
>>    |            to='romeo@example.net'
>>    |            type='subscribe'/>
>>
>>    Upon receiving such a presence stanza, the XMPP server to which
>>    Juliet has connected needs to determine the identity of the
>>    domainpart in the 'to' address, which it does by following the
>>    procedures discussed in [I-D.ietf-stox-core].  Here we assume that
> 
> Unfortunately, given the context of a citation like this, it really
> needs much greater precision, to point the reader to the exact portion
> of the document that is relevant to this context.

Agreed.

> Unless, of course, the premise of the current document is that the
> reader must be deeply familiar with the -core document.  In which case,
> /that's/ what should be specified early in this document.  Based on what
> follows, I fear that indeed, this document requires deep familiarity
> with -core.

I definitely think that's so. All of the STOX WG documents build upon
the framework described in draft-ietf-stox-core.

>>    the XMPP server has determined the domain is serviced by a SIMPLE
>>    server, that it contains or has available to it an XMPP-SIMPLE
>>    gateway or connection manager (which enables it to speak natively to
>>    SIMPLE servers), and that it hands off the presence stanza to the
>>    XMPP-SIMPLE gateway.
>>
>>    The XMPP-SIMPLE gateway is then responsible for translating the XMPP
>>    subscription request into a SIP SUBSCRIBE request from the XMPP user
>>    to the SIP user:
>>
>>    Example 2: XMPP user subscribes to SIP contact (SIP transformation):
> 
> It took a moment to decide whether I was looking at XMPP form or SIP
> form.  Perhaps a more helpufl title for the example would be something
> like:
> 
>      Example 2: Translation of XMPP user's subscription request into SIP

Yes, that's better.

>>    |  SUBSCRIBE sip:romeo@example.net SIP/2.0
> 
> Later text (section 4.1) equates the label pres: with sip: and sips:.
> Why choose sip: here?

In practice, we don't see 'pres' URIs in the wild.

>>    |  Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk
>>    |  From: <sip:juliet@example.com>;tag=ffd2
>>    |  Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C
>>    |  Event: presence
>>    |  Max-Forwards: 70
>>    |  CSeq: 123 SUBSCRIBE
>>    |  Contact: <sip:x2s.example.com;transport=tcp>
>>    |  Accept: application/pidf+xml
>>    |  Expires: 3600
>>    |  Content-Length: 0
>>
>>    The SIP user then SHOULD send a response indicating acceptance of the
>>    subscription request:
>>
>>    Example 3: SIP accepts subscription request:
>>
>>    |  SIP/2.0 200 OK
>>    |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>>    |  From: <sip:romeo@example.net>;tag=ffd2
>>    |  To: <sip:juliet@example.com>;tag=j89d
>>    |  Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C
>>    |  CSeq: 234 SUBSCRIBE
>>    |  Contact: <sip:simple.example.net;transport=tcp>
>>    |  Expires: 3600
>>    |  Content-Length: 0
> 
> Hmmm.  This appears to be the original SIP acceptance, but with no
> separate display of it's being translated into XMPP.

That is Example 5.

>> Saint-Andre, et al.      Expires April 21, 2014                 [Page 5]
>> 
>> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>>
>>
>>    In accordance with [RFC6665], the XMPP-SIMPLE gateway SHOULD consider
>>    the subscription state to be "neutral" until it receives a NOTIFY
>>    message.  Therefore the SIP user or SIP-XMPP gateway at the SIP
>>    user's domain SHOULD immediately send a NOTIFY message containing a
>>    "Subscription-State" header whose value contains the string "active"
>>    (see Section 4).
>>
>>    Example 4: SIP user sends presence notification:
>>
>>    |  NOTIFY sip:192.0.2.1 SIP/2.0
>>    |  Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk
>>    |  From: <sip:romeo@example.net>;tag=yt66
>>    |  To: <sip:juliet@example.com>;tag=bi54
>>    |  Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C
>>    |  Event: presence
>>    |  Subscription-State: active;expires=499
>>    |  Max-Forwards: 70
>>    |  CSeq: 8775 NOTIFY
>>    |  Contact: <sip:simple.example.net;transport=tcp>
>>    |  Content-Type: application/pidf+xml
>>    |  Content-Length: 193
>>    |
>>    |  <?xml version='1.0' encoding='UTF-8'?>
>>    |  <presence xmlns='urn:ietf:params:xml:ns:pidf'
>>    |            entity='pres:romeo@example.net'>
>>    |    <tuple id='ID-orchard'>
>>    |      <status>
>>    |        <basic>open</basic>
>>    |        <show xmlns='jabber:client'>away</show>
>>    |      </status>
>>    |    </tuple>
>>    |  </presence>
> 
> Where is the xmpp translation of this?

That is Example 6.

>>    In response, the SIMPLE-XMPP gateway would send a 200 OK (not shown
> 
> Sent it to whom?  (I probably know the answer, but the reader shouldn't
> have to guess; this is a spec.)

The gateways sends it to the SIP user agent. Will clarify.

>>    here since it is not translated into an XMPP stanza).
>>
>>    Upon receiving the first NOTIFY with a subscription state of active,
>>    the XMPP-SIMPLE gateway MUST generate a presence stanza of type
>>    "subscribed":
>>
>>    Example 5: XMPP user receives acknowledgement from SIP contact:
>>
>>    |  <presence from='romeo@example.net'
>>    |            to='juliet@example.com'
>>    |            type='subscribed'/>
>>
>>    As described under Section 4, the gateway MUST also generate a
>>    presence notification to the XMPP user:
>>
>>
>> Saint-Andre, et al.      Expires April 21, 2014                 [Page 6]
>> 
>> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>>
>>
>>    Example 6: XMPP user receives presence notification from SIP contact:
>>
>>    |  <presence from='romeo@example.net/orchard'
>>    |            to='juliet@example.com'/>
> 
> 
> This sequence feels like it should have a protocol sequence diagram, of
> the type used in rfc5263.

Yes, some "swim lanes" are in order here and throughout.

>> 3.2.3.  Cancelling a Presence Subscription
>>
>>    At any time after subscribing, the XMPP user can unsubscribe from the
>>    contact's presence.  This is done by sending a presence stanza of
>>    type "unsubscribe":
>>
>>    Example 7: XMPP user unsubscribes from SIP contact:
>>
>>    |  <presence from='juliet@example.com'
>>    |            to='romeo@example.net'
>>    |            type='unsubscribe'/>
>>
>>    The XMPP-SIMPLE gateway is responsible for translating the
>>    unsubscribe command into a SIP SUBSCRIBE request with the "Expires"
>>    header set to a value of zero:
>>
>>    Example 8: XMPP user unsubscribes from SIP contact (SIP
>>    transformation):
>>
>>    |  SUBSCRIBE sip:romeo@example.net SIP/2.0
>>    |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>>    |  From: <sip:juliet@example.com>;tag=j89d
>>    |  Call-ID: 9D9F00DF-FCA9-4E7E-B970-80B638D5218A
>>    |  Event: presence
>>    |  Max-Forwards: 70
>>    |  CSeq: 789 SUBSCRIBE
>>    |  Contact: <sip:x2s.example.com;transport=tcp>
>>    |  Accept: application/pidf+xml
>>    |  Expires: 0
>>    |  Content-Length: 0
>>
>>
>>
>> Saint-Andre, et al.      Expires April 21, 2014                 [Page 7]
>> 
>> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>>
>>
>>    Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway
>>    SHOULD send a presence stanza of type "unsubscribed" to the XMPP
>>    user:
>>
>>    Example 9: XMPP user receives unsubscribed notification:
>>
>>    |  <presence from='romeo@example.net'
>>    |            to='juliet@example.com'
>>    |            type='unsubscribed'/>
> 
> 
> One of the advantages of showing sequences like these in a protocol
> sequence diagram is that it concisely shows which of the 4 actors does
> what and when.  Being able to see visual summaries like that will make
> the life of an implementer /much/ easier.

Agreed.

>> 3.3.  SIP to XMPP
>>
>> 3.3.1.  Establishing a Presence Subscription
>>
>>    A SIP user initiates a subscription to a contact's presence
>>    information by sending a SIP SUBSCRIBE request to the contact.  The
>>    following is an example of such a request:
>>
>>    Example 10: SIP user subscribes to XMPP contact:
>>
>>    |  SUBSCRIBE sip:juliet@example.com SIP/2.0
>>    |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>>    |  From: <sip:romeo@example.net>;tag=xfg9
>>    |  Call-ID: AA5A8BE5-CBB7-42B9-8181-6230012B1E11
>>    |  Event: presence
>>    |  Max-Forwards: 70
>>    |  CSeq: 263 SUBSCRIBE
>>    |  Contact: <sip:simple.example.net;transport=tcp>
>>    |  Accept: application/pidf+xml
>>    |  Content-Length: 0
>>
>>    Notice that the "Expires" header was not included in the SUBSCRIBE
>>    request; this means that the default value of 3600 (i.e., 3600
>>    seconds = 1 hour) applies.
>>
>>    Upon receiving the SUBSCRIBE, the SIP server needs to determine the
>>    identity of the domain portion of the Request-URI or To header, which
>>    it does by following the procedures discussed in
>>    [I-D.ietf-stox-core].  Here we assume that the SIP server has
>>    determined that the domain is serviced by an XMPP server, that it
> 
> 
> This seems to mean that a regular SIP server needs to be familiar with
> technical details in a gatewaying specification??

Well, it is (IMHO) really the responsibility of a core "server" to
implement this kind of routing functionality, but the "gateway" might
make the determination that the remote domain uses SIP or XMPP and if
SIP then pass it on to the SIP "server" and if not handle delivery to
the remote XMPP domain. To some extent it's a matter of implementation
where exactly the code lives to complete these functions, which is why
draft-ietf-stox-core talks about a "SIP service" consisting of both a
SIP "server" and a "gateway". In XMPP this translation function is often
handled by what we call a "connection manager", but that depends a bit
on the internal architecture of the overall "service".

>>    Example 11: SIP user subscribes to XMPP contact (XMPP
>>    transformation):
>>
>>    |  <presence from='romeo@example.net'
>>    |            to='juliet@example.com'
>>    |            type='subscribe'/>
>>
>>    In accordance with [RFC6121], the XMPP user's server MUST deliver the
>>    presence subscription request to the XMPP user (or, if a subscription
>>    already exists in the XMPP user's roster, send a presence stanza of
>>    type 'subscribed').
>>
>>    If the XMPP user approves the subscription request, the XMPP server
>>    then MUST return a presence stanza of type "subscribed" from the XMPP
>>    user to the SIP user; if a subscription already exists, the XMPP
> 
> The XMPP server does not communicate (directly) with the SIP user.  It
> has to go through one or both gateways.  (From the architectural
> diagram, I assume the sequence is through both.)  This spec needs to be
> very careful to identify what entity is talking with what entity
> directly and who is mediating, when it isn't direct.

Yes, we need more clarity about "service", "server", and "gateway".

>> 3.3.2.  Refreshing a Presence Subscription
>>
>>    For as long as a SIP user is online and interested in receiving
>>    presence notifications from the XMPP users, the user's SIP user agent
>>    is responsible for periodically refreshing the subscription by
>>    sending an updated SUBSCRIBE request with an appropriate value for
> 
> sending it to which actor directly?

To the XMPP user (although the SIP user wouldn't know that the user is
on the XMPP side of the wormhole, since the gateway masks that fact).

>>    the Expires header.  In response, the SIMPLE-XMPP gateway MUST send a
>>
>>
>>
>> Saint-Andre, et al.      Expires April 21, 2014                 [Page 9]
>> 
>> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>>
>>
>>    SIP NOTIFY to the user agent (per [RFC6665]; if the gateway has
>>    meaningful information about the availability state of the XMPP user
> 
> This prompts the thought that early in the document, there should
> probably be some discussion about what state information needs to be
> maintained in the gateways.

Good point.

>>    then the NOTIFY MUST communicate that information (e.g., by including
>>    a PIDF body [RFC3863] with the relevant data), whereas if the gateway
>>    does not have meaningful information about the availability state of
>>    the XMPP user then the NOTIFY MUST be empty as allowed by [RFC6665].
>>
>>    Once the SIP user goes offline at the end of a presence session, it
> 
> "goes offline" seems odd phrasing here; I'm not entirely sure what it
> means.  isn't the simple point that the SIP user terminates the presence
> session (for whatever reason)?  If the point is that the SIP user
> literally disappears from the session -- again, there are lots of
> possible reasons, where 'going offline' is only one -- some language
> like that might work better.

We can just say "ends its presence session".

>> 4.1.  Overview
> 
> In general, this overview (4.1) section seems odd to have appear so late
> in the document.  Everything in it feels like stuff that should be in
> Section 1, not Section 4.

It's an overview of how notifications work, but you might be right that
some of it belongs earlier in the document. I'll review the section with
your feedback in mind.

>>    Both XMPP and presence-aware SIP systems enable entities (often but
>>    not necessarily human users) to send presence notifications to other
>>    entities.  At a minimum, the term "presence" refers to information
>>    about an entity's availability for communication on a network (on/
>>    off), often supplemented by information that further specifies the
>>    entity's communications context (e.g., "do not disturb").  Some
>>    systems and protocols extend this notion even further and refer to
>>    any relatively ephemeral information about an entity as a kind of
>>    presence; categories of such "extended presence" include geographical
> 
> The above text seems a bit confusing.  First it distinguishes between
> presence and status, and then describes something which is both as
> 'extended status.'
> 
> Here's my guess about what is needed:
> 
> 1. Very narrow and precise use of the term presence; I think that means
> it only mean "connected to a presence service", or somesuch.

It's best not to conflate presence with a physical or virtual
connection, because one can be present even if disconnected (usually for
a short period of time).

Citing RFC 2778 might be sensible here.

> 2. Consistent distinction of presence-related attributes, like do not
> disturb.  What's missing here is a simple term for it.

In XMPP we refer to "presence" (online/offline) and "availability
states" when an entity is online (away, do not disturb, etc.). We also
have human-readable descriptions for such states (e.g., "in a meeting").

> 3. Clarity that "ephemeral information about an entity" is probably a
> form of #2, rather than #1.  That is, I think it's a presence attribute,
> rather than "a presence".

Such ephemeral information might include things like the user's mood,
what tune is playing on their music player, etc.

> And if I've gotten this entirely confused, then that means the text
> needs a different kind of fixing...
> 
> 
>>    location (e.g., GPS coordinates), user mood (e.g., grumpy), user
>>    activity (e.g., walking), and ambient environment (e.g., noisy).  In
>>    this document, we focus on the "least common denominator" of network
>>    availability only, although future documents might address broader
>>    notions of presence, including extended presence.
>>
>>
>>
>>
>> Saint-Andre, et al.      Expires April 21, 2014                [Page 12]
>> 
>> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>>
>>
>>    [RFC6121] defines how XMPP presence stanzas can indicate availability
>>    (via absence of a 'type' attribute) or lack of availability (via a
>>    'type' attribute with a value of "unavailable").  SIP presence using
>>    a SIP event package for presence is specified in [RFC3856].
>>
>>    As described in [RFC6121], presence information about an entity is
> 
>    information -> XMPP information

Right.

>>    communicated by means of an XML <presence/> stanza sent over an XML
>>    stream.  In this document we will assume that such a presence stanza
>>    is sent from an XMPP client to an XMPP server over an XML stream
>>    negotiated between the client and the server, and that the client is
>>    controlled by a human user (again, this is a simplifying assumption
>>    introduced for explanatory purposes only).  In general, XMPP presence
>>    is sent by the user to the user's server and then broadcasted to all
>>    entities who are subscribed to the user's presence information.
> 
> http://www.dailywritingtips.com/broadcast-vs-broadcasted-as-past-form/
> 
> In spite of having some formal linguistic legitimacy, I suggest using
> 'broadcast'.

Yep.

>>    As described in [RFC3856], presence information about an entity is
>>    communicated by means of a SIP NOTIFY event sent from a SIP user
>>    agent to an intended recipient who is most generally referenced by an
>>    Presence URI of the form <pres:user@domain> but who might be
>>    referenced by a SIP or SIPS URI of the form <sip:user@domain> or
>>    <sips:user@domain>.  Here again we introduce the simplifying
>>    assumption that the user agent is controlled by a human user.
> 
> I guess I'm not understanding how the nature of what is controlling the
> agent affects anything in this document.  Might be worth explaining that.

A "presentity" doesn't have to be a human -- it could be a bot, a
device, or some other automated entity. People related more to human users.

>> 4.2.  XMPP to SIP
>>
>>    When Juliet interacts with her XMPP client to modify her presence
>>    information (or when her client automatically updates her presence
>>    information, e.g. via an "auto-away" feature), her client generates
>>    an XMPP <presence/> stanza.  The syntax of the <presence/> stanza,
>>    including required and optional elements and attributes, is defined
>>    in [RFC6121].  The following is an example of such a stanza:
>>
>>    Example 17: XMPP user sends presence notification:
>>
>>    |  <presence from='juliet@example.com/balcony'/>
>>
>>    Upon receiving such a stanza, the XMPP server to which Juliet has
>>    connected broadcasts it to all subscribers who are authorized to
>>    receive presence notifications from Juliet (this is similar to the
>>    SIP NOTIFY method).  For each subscriber, broadcasting the presence
>>    notification involves either delivering it to a local recipient (if
>>    the hostname in the subscriber's address matches one of the hostnames
>>    serviced by the XMPP server) or attempting to route it to the foreign
>>    domain that services the hostname in the subscriber's address.  Thus
>>
>>
>>
>> Saint-Andre, et al.      Expires April 21, 2014                [Page 13]
>> 
>> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>>
>>
>>    the XMPP server needs to determine the identity of the domainpart in
>>    the 'to' address, which it does by following the procedures discussed
>>    in [I-D.ietf-stox-core].  Here we assume that the XMPP server has
>>    determined the domain is serviced by a SIMPLE server, that it
> 
> again, the idea that a pure xmpp server can 'know' about a simple
> destination doesn't make sense to me.  (And by that way, is it simple or
> is it sip...? Note that the term 'simple' hasn't been getting used in
> this document.)
> 
> at a minimum, this is a good place to repeat the pointer to text that
> explains how gateways are operational fit into two native networks,
> where their nature is transparent -- that is, with the native entities
> thinking they are merely talking to other native entities.

Yes. See above.

>>    contains or has available to it an XMPP-SIMPLE gateway or connection
>>    manager (which enables it to speak natively to SIMPLE servers), and
>>    that it hands off the presence stanza to the XMPP-SIMPLE gateway.
>>
>>    The XMPP-SIMPLE gateway is then responsible for translating the XMPP
>>    presence stanza into a SIP NOTIFY request and included PIDF document
>>    from the XMPP user to the SIP user.
>>
>>    Example 18: XMPP user sends presence notification (SIP
>>    transformation):
>>
>>    |  NOTIFY sip:192.0.2.2 SIP/2.0
>>    |  Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk
>>    |  From: <sip:juliet@example.com>;tag=gh19
>>    |  To: <sip:romeo@example.net>;tag=yt66
>>    |  Contact: <sip:juliet@example.com>;gr=balcony
>>    |  Call-ID: 2B44E147-3B53-45E4-9D48-C051F3216D14
>>    |  Event: presence
>>    |  Subscription-State: active;expires=599
>>    |  Max-Forwards: 70
>>    |  CSeq: 157 NOTIFY
>>    |  Contact: <sip:x2s.example.com;transport=tcp>
>>    |  Content-Type: application/pidf+xml
>>    |  Content-Length: 192
>>    |
>>    |  <?xml version='1.0' encoding='UTF-8'?>
>>    |  <presence xmlns='urn:ietf:params:xml:ns:pidf'
>>    |            entity='pres:juliet@example.com'>
>>    |    <tuple id='ID-balcony'>
>>    |      <status>
>>    |        <basic>open</basic>
>>    |        <show xmlns='jabber:client'>away</show>
>>    |      </status>
>>    |    </tuple>
>>    |  </presence>
>>
>>    The mapping of XMPP syntax elements to SIP syntax elements SHOULD be
>>    as shown in the following table.  (Mappings for elements not
>>    mentioned are undefined.)
>>
>>
>>
>>
>>
>>
>>
>>
>> Saint-Andre, et al.      Expires April 21, 2014                [Page 14]
>> 
>> Internet-Draft       SIP-XMPP Interworking: Presence        October 2013
>>
>>
>>    Table 1: Presence syntax mapping from XMPP to SIP
>>
>>       +-----------------------------+---------------------------+
>>       |  XMPP Element or Attribute  |  SIP Header or PIDF Data  |
>>       +-----------------------------+---------------------------+
>>       |  <presence/> stanza         |  "Event: presence" (1)    |
>>       |  XMPP resource identifer    |  tuple 'id' attribute (2) |
>>       |  from                       |  From                     |
>>       |  id                         |  CSeq (3)                 |
>>       |  to                         |  To                       |
>>       |  type                       |  basic status (4) (5)     |
>>       |  xml:lang                   |  Content-Language         |
>>       |  <priority/>                |  priority for tuple (6)   |
>>       |  <show/>                    |  no mapping (7)           |
>>       |  <status/>                  |  <note/>                  |
>>       +-----------------------------+---------------------------+
> 
> The format of this makes the table reads as two (unsynchronized)
> columns, rather than a series of rows.
> 
> I suggest different formatting, such as (in spite of it's being longer:
> 
> 
>         +-----------------------------+---------------------------+
>         |  XMPP Element or Attribute  |  SIP Header or PIDF Data  |
>         +-----------------------------+---------------------------+
>         |  <presence/  stanza            "Event: presence" (1)    |
>         +-----------------------------+---------------------------+
>         |  XMPP resource identifer       tuple 'id' attribute (2) |
>         +-----------------------------+---------------------------+
>         |  from                          From                     |
>         +-----------------------------+---------------------------+
>         |  id                            CSeq (3)                 |
>         +-----------------------------+---------------------------+
>         |  to                            To                       |
>         +-----------------------------+---------------------------+
>         |  type                          basic status (4) (5)     |
>         +-----------------------------+---------------------------+
>         |  xml:lang                      Content-Language         |
>         +-----------------------------+---------------------------+
>         |  <priority/>                   priority for tuple (6)   |
>         +-----------------------------+---------------------------+
>         |  <show/>                       no mapping (7)           |
>         +-----------------------------+---------------------------+
>         |  <status/>                     <note/>                  |
>         +-----------------------------+---------------------------+

Agreed.

>>    Note the following regarding these mappings:
>>
>>    1.  Only a presence stanza that lacks a 'type' attribute or whose
> 
>    presence -> XMPP presence

Stanzas are an XMPP artifact. But yes.

>>        'type' attribute has a value of "unavailable" SHOULD be mapped by
>>        an XMPP-SIMPLE gateway to a SIP NOTIFY request, since those are
>>        the only presence stanzas that represent notifications.
>>    2.  The PIDF schema defines the tuple 'id' attribute as having a
>>        datatype of "xs:ID"; because this datatype is more restrictive
>>        than the "xs:string" datatype for XMPP resourceparts (in
>>        particular, a number is not allowed as the first character of an
>>        ID), it is RECOMMENDED to prepend the resourcepart with "ID-" or
>>        some other alphabetic string when mapping from XMPP to SIP.
>>    3.  This mapping is OPTIONAL.
> 
> What does that mean?  This sort of mapping is usually the essence of
> gatewaying semantics.  How can interoperability tolerate it's being
> optional?

In XMPP, the 'id' attribute is not usually included in presence stanzas,
and nothing is lost if it's ignored. But I'll give it a bit more thought.

>> 4.3.  SIP to XMPP
>>
>>    When Romeo changes his presence, his SIP user agent generates a SIP
> 
> Romeo is doing SIP?  And Juliet does XMPP?

You noticed, eh? "Juliet does Jabber" makes it easy to remember, at
least for me.

> So, SIP is more macho than XMPP???

Have you configured a SIP client lately? ;-)

But seriously, the Romeo and Juliet scenarios enable me to use a male
character and a female character for diversity purposes, with message
text that is in the public domain and widely translated into something
other than English for internationalization examples.

Thanks for the thorough review. I'll work to address your feedback and
submit a revised I-D.

Peter

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




From yana@sip-communicator.org  Mon Dec 16 06:44:46 2013
Return-Path: <yana@sip-communicator.org>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534DB1AE33C for <stox@ietfa.amsl.com>; Mon, 16 Dec 2013 06:44:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.591
X-Spam-Level: 
X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxXSDJem2sWs for <stox@ietfa.amsl.com>; Mon, 16 Dec 2013 06:44:43 -0800 (PST)
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) by ietfa.amsl.com (Postfix) with ESMTP id 34F651ADFFA for <stox@ietf.org>; Mon, 16 Dec 2013 06:44:42 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id q58so4663166wes.19 for <stox@ietf.org>; Mon, 16 Dec 2013 06:44:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=/mkaQiDPD0N3PkIn0YgO+x22srusGOhFXMAgl/LQbe4=; b=BgwzPaiDcLVRQIOhFZ2KAizvxVm+AmUsD4oQ4uB2JJ2MgAQprCQs7DDHpyVD1ZbHC2 LqE/vxmmQin1A5BxjJw32iBJfKhvgoMILbw2aoExbSLJlf06G+OnJWW5gwcjxo9pIQMe 8OurWTp8E0akchlggkuI8+ReraZfnpxQHyh8Y4Zp4KYjR8sHj4xiZNIuoPbojv5EUFJ0 NH43JjlPzgKlkw9jk8d/sElI969q+Lqto1AhTISvp3A1o8VdrKMvh4QUS+h1oEWZiTZE oR2+N9pUdUES3DZCHlQj/zg3J/B3tXDwao14xLZ14rGFbqEj/YZ6jiQz1d4Feplm7EFD lVwQ==
X-Gm-Message-State: ALoCoQmM6dNfB4zzrUPBFFozi5gu+A3yZ2LuqYJcIgV6ONVm1P8+2E9tLtg9h2kX3sbFzsLPn2DP
X-Received: by 10.194.110.138 with SMTP id ia10mr13822953wjb.3.1387205082049;  Mon, 16 Dec 2013 06:44:42 -0800 (PST)
Received: from [192.168.1.31] (neu67-4-88-160-65-79.fbx.proxad.net. [88.160.65.79]) by mx.google.com with ESMTPSA id mz10sm26447107wic.2.2013.12.16.06.44.38 for <stox@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 06:44:39 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Yana Stamcheva <yana@jitsi.org>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620A13923B@008-AM1MPN1-041.mgdnok.nokia.com>
Date: Mon, 16 Dec 2013 15:44:38 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <98C874C8-756C-4509-AD0C-7E1C796D849A@jitsi.org>
References: <E44893DD4E290745BB608EB23FDDB7620A13923B@008-AM1MPN1-041.mgdnok.nokia.com>
To: stox@ietf.org
X-Mailer: Apple Mail (2.1822)
Subject: [Stox] Reminder: Dec 17 virtual interim meeting
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Dec 2013 14:44:46 -0000

Hi,

This is a reminder for the STOX virtual interim meeting to be held =
_tomorrow_ (Dec 17 at 16:00 (4PM) UTC).

Below are the preliminary agenda and the WebEx details.

As stated before, the main topic of the meeting will be the -media =
draft. The draft has been updated from the authors as promised and the =
current version is -02 ( =
http://tools.ietf.org/html/draft-ietf-stox-media-02 ).

Regards,
Yana

On 27 Nov 2013, at 10:28, Markus.Isomaki@nokia.com wrote:

> Hi,
>=20
> Here are the details of the STOX virtual interim to be held on Dec 17.
>=20
> The current version of draft-ietf-stox-media is -01, but the authors =
have promised an update latest one week before the meeting.=20
>=20
> ---
>=20
> IP-to-XMPP (STOX) WG virtual interim
>=20
> Date: December 17, 2013
> Time: 16:00 (4PM) UTC
> Maximum length: 1.5 hours
>=20
> Chairs:
> Markus Isom=E4ki, markus.isomaki@nokia.com
> Yana Stamcheva, yana@jitsi.org
>=20
> The meeting will focus on the "Media Sessions" draft:
> http://datatracker.ietf.org/doc/draft-ietf-stox-media/
>=20
> Agenda
>=20
> (Subject to updates)
>=20
> 1. Opening (chairs, 5 min.)
>  - Minutes, agenda bash
> 2. STOX WG status (chairs, 5 min.)
>   - Where we are with core, presence, im, chat and groupchat 3. Media =
signaling walkthrough (Co-authors, 20 min.)
>  - Explain how it is supposed to work
>  - Clarifying questions allowed
> 4. Media signaling open issues and discussion (Co-authors, max. 50 =
min.)
>  - Resolve issues if possible, Assign actions, Plan next revisions=20
> 5. Summary and closing (chairs)
>=20
> Overall time max. 90 minutes.
>=20
> ---
>=20
> WebEx info
>=20
> Topic: STOX=20
> Date: Tuesday, December 17, 2013=20
> Time: 3:45 pm, GMT Time (London, GMT)=20
> Meeting Number: 640 253 699=20
> Meeting Password: 1234=20
>=20
>=20
> -------------------------------------------------------=20
> To join the online meeting (Now from mobile devices!)=20
> -------------------------------------------------------=20
> 1. Go to =
https://ietf.webex.com/ietf/j.php?ED=3D255438447&UID=3D1705818657&PW=3DNMW=
E5Y2VkNDlk&RT=3DMiMyMQ%3D%3D
> 2. If requested, enter your name and email address.=20
> 3. If a password is required, enter the meeting password: 1234=20
> 4. Click "Join".=20
>=20
> To view in other time zones or languages, please click the link:=20
> =
https://ietf.webex.com/ietf/j.php?ED=3D255438447&UID=3D1705818657&PW=3DNMW=
E5Y2VkNDlk&ORT=3DMiMyMQ%3D%3D
>=20
> -------------------------------------------------------=20
> To join the audio conference only=20
> -------------------------------------------------------=20
> Call-in toll number (US/Canada): 1-650-479-3208=20
>=20
> Access code:640 253 699=20
>=20
> -------------------------------------------------------=20
> For assistance=20
> -------------------------------------------------------=20
> 1. Go to https://ietf.webex.com/ietf/mc
> 2. On the left navigation bar, click "Support".=20
>=20
> You can contact me at:=20
> cmorgan@amsl.com
> 1-510-492-4085=20
>=20
> To add this meeting to your calendar program (for example Microsoft =
Outlook), click this link:=20
> =
https://ietf.webex.com/ietf/j.php?ED=3D255438447&UID=3D1705818657&ICS=3DMI=
&LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAgoDDRu-EEpTt7AnfETJtAMkYVk-agl8tiR29/c7C=
m/U&RT=3DMiMyMQ%3D%3D
>=20
> The playback of UCF (Universal Communications Format) rich media files =
requires appropriate players. To view this type of rich media files in =
the meeting, please check whether you have the players installed on your =
computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.=20
>=20
> Sign up for a free trial of WebEx=20
> http://www.webex.com/go/mcemfreetrial
>=20
> http://www.webex.com
>=20
> CCP:+16504793208x640253699#=20
>=20
> IMPORTANT NOTICE: This WebEx service includes a feature that allows =
audio and any documents and other materials exchanged or viewed during =
the session to be recorded. By joining this session, you automatically =
consent to such recordings. If you do not consent to the recording, =
discuss your concerns with the meeting host prior to the start of the =
recording or do not join the session. Please note that any such =
recordings may be subject to discovery in the event of litigation.=20
>=20
>=20
>=20
>=20
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox


From Markus.Isomaki@nokia.com  Mon Dec 16 09:09:27 2013
Return-Path: <Markus.Isomaki@nokia.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5904F1AE079 for <stox@ietfa.amsl.com>; Mon, 16 Dec 2013 09:09:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.739
X-Spam-Level: 
X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqQ8nA5eFxm3 for <stox@ietfa.amsl.com>; Mon, 16 Dec 2013 09:09:22 -0800 (PST)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 78F8E1AE078 for <stox@ietf.org>; Mon, 16 Dec 2013 09:09:21 -0800 (PST)
Received: from smtp.mgd.nokia.com ([65.54.30.24]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rBGH1MME025351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 16 Dec 2013 19:01:23 +0200
Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.242]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.03.0158.002;  Mon, 16 Dec 2013 17:01:22 +0000
From: <Markus.Isomaki@nokia.com>
To: <yana@jitsi.org>, <stox@ietf.org>
Thread-Topic: STOX interim: materials
Thread-Index: Ac76gD6C7sTEz6nbT0GuQUDlg2ygLg==
Date: Mon, 16 Dec 2013 17:01:21 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7620A17473A@008-AM1MPN1-043.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;
x-titus-version: 3.5.9.3
x-headerinfofordlp: 
x-tituslabs-classificationhash-30: 2PrCjJ7f5poVv9TjWbkmkjljR0efKi/c/lA/Qiox0YMwT25VcFrgje1KTJM0L5wIeh2rjLlfNEE+2cKx+3UjDgcrpQSSE6i3MXdRQBIMOho9wiHE4wDvBAT+8y89PXlEsoIlpe01uWj6IUHUpWXnQpb2+1ivVm0MzojmYb0ocSvr9kWbyjQZAf40T88lUHfv6rv7h+0uB0aIXtKAW3YyCQ==
x-originating-ip: [10.163.19.199]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
Subject: [Stox] STOX interim: materials
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Dec 2013 17:09:27 -0000

Hi all,

The meeting materials will be available here:
http://www.ietf.org/proceedings/interim/2013/12/17/stox/proceedings.html

The agenda and chairs' status slides are already there. We hope to get the =
'media signaling' slides up there as well before the meeting.

Regards,
	Markus


> -----Original Message-----
> From: stox [mailto:stox-bounces@ietf.org] On Behalf Of ext Yana Stamcheva
> Sent: 16 December, 2013 16:45
> To: stox@ietf.org
> Subject: [Stox] Reminder: Dec 17 virtual interim meeting
>=20
> Hi,
>=20
> This is a reminder for the STOX virtual interim meeting to be held
> _tomorrow_ (Dec 17 at 16:00 (4PM) UTC).
>=20
> Below are the preliminary agenda and the WebEx details.
>=20
> As stated before, the main topic of the meeting will be the -media draft.=
 The
> draft has been updated from the authors as promised and the current
> version is -02 ( http://tools.ietf.org/html/draft-ietf-stox-media-02 ).
>=20
> Regards,
> Yana
>=20
> On 27 Nov 2013, at 10:28, Markus.Isomaki@nokia.com wrote:
>=20
> > Hi,
> >
> > Here are the details of the STOX virtual interim to be held on Dec 17.
> >
> > The current version of draft-ietf-stox-media is -01, but the authors ha=
ve
> promised an update latest one week before the meeting.
> >
> > ---
> >
> > IP-to-XMPP (STOX) WG virtual interim
> >
> > Date: December 17, 2013
> > Time: 16:00 (4PM) UTC
> > Maximum length: 1.5 hours
> >
> > Chairs:
> > Markus Isom=E4ki, markus.isomaki@nokia.com Yana Stamcheva,
> > yana@jitsi.org
> >
> > The meeting will focus on the "Media Sessions" draft:
> > http://datatracker.ietf.org/doc/draft-ietf-stox-media/
> >
> > Agenda
> >
> > (Subject to updates)
> >
> > 1. Opening (chairs, 5 min.)
> >  - Minutes, agenda bash
> > 2. STOX WG status (chairs, 5 min.)
> >   - Where we are with core, presence, im, chat and groupchat 3. Media
> > signaling walkthrough (Co-authors, 20 min.)
> >  - Explain how it is supposed to work
> >  - Clarifying questions allowed
> > 4. Media signaling open issues and discussion (Co-authors, max. 50
> > min.)
> >  - Resolve issues if possible, Assign actions, Plan next revisions 5.
> > Summary and closing (chairs)
> >
> > Overall time max. 90 minutes.
> >
> > ---
> >
> > WebEx info
> >
> > Topic: STOX
> > Date: Tuesday, December 17, 2013
> > Time: 3:45 pm, GMT Time (London, GMT) Meeting Number: 640 253 699
> > Meeting Password: 1234
> >
> >
> > -------------------------------------------------------
> > To join the online meeting (Now from mobile devices!)
> > -------------------------------------------------------
> > 1. Go to
> >
> https://ietf.webex.com/ietf/j.php?ED=3D255438447&UID=3D1705818657&PW=3DN
> MWE5
> > Y2VkNDlk&RT=3DMiMyMQ%3D%3D 2. If requested, enter your name and
> email
> > address.
> > 3. If a password is required, enter the meeting password: 1234 4.
> > Click "Join".
> >
> > To view in other time zones or languages, please click the link:
> >
> https://ietf.webex.com/ietf/j.php?ED=3D255438447&UID=3D1705818657&PW=3DN
> MWE5
> > Y2VkNDlk&ORT=3DMiMyMQ%3D%3D
> >
> > -------------------------------------------------------
> > To join the audio conference only
> > -------------------------------------------------------
> > Call-in toll number (US/Canada): 1-650-479-3208
> >
> > Access code:640 253 699
> >
> > -------------------------------------------------------
> > For assistance
> > -------------------------------------------------------
> > 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar,
> > click "Support".
> >
> > You can contact me at:
> > cmorgan@amsl.com
> > 1-510-492-4085
> >
> > To add this meeting to your calendar program (for example Microsoft
> Outlook), click this link:
> >
> https://ietf.webex.com/ietf/j.php?ED=3D255438447&UID=3D1705818657&ICS=3DM=
I
> &L
> > D=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAgoDDRu-EEpTt7AnfETJtAMkYVk-
> agl8tiR29/c7Cm/U&RT
> > =3DMiMyMQ%3D%3D
> >
> > The playback of UCF (Universal Communications Format) rich media files
> requires appropriate players. To view this type of rich media files in th=
e
> meeting, please check whether you have the players installed on your
> computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.
> >
> > Sign up for a free trial of WebEx
> > http://www.webex.com/go/mcemfreetrial
> >
> > http://www.webex.com
> >
> > CCP:+16504793208x640253699#
> >
> > IMPORTANT NOTICE: This WebEx service includes a feature that allows
> audio and any documents and other materials exchanged or viewed during
> the session to be recorded. By joining this session, you automatically co=
nsent
> to such recordings. If you do not consent to the recording, discuss your
> concerns with the meeting host prior to the start of the recording or do =
not
> join the session. Please note that any such recordings may be subject to
> discovery in the event of litigation.
> >
> >
> >
> >
> > _______________________________________________
> > stox mailing list
> > stox@ietf.org
> > https://www.ietf.org/mailman/listinfo/stox
>=20
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox

From dhc@dcrocker.net  Tue Dec 17 07:40:52 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2C91ADF73; Tue, 17 Dec 2013 07:40:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jR7YvxAIAAMr; Tue, 17 Dec 2013 07:40:50 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9C61ADEBA; Tue, 17 Dec 2013 07:40:50 -0800 (PST)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rBHFeZBQ021603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Dec 2013 07:40:43 -0800
Message-ID: <52B07028.4020609@dcrocker.net>
Date: Tue, 17 Dec 2013 07:39:20 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>, Apps Discuss <apps-discuss@ietf.org>, draft-ietf-stox-presence.all@tools.ietf.org, stox@ietf.org
References: <52A94AF6.8090702@dcrocker.net> <52AB8E69.7070906@stpeter.im>
In-Reply-To: <52AB8E69.7070906@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 17 Dec 2013 07:40:49 -0800 (PST)
Cc: iesg <iesg@ietf.org>
Subject: Re: [Stox] Review of:  draft-ietf-stox-presence-06
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2013 15:40:52 -0000

Only responded where it seems needed or useful...



On 12/13/2013 2:47 PM, Peter Saint-Andre wrote:

>>     1.  When citing the earlier efforts, there should be something to
>> explain why the current work is expected to be more successful.
>
> Not "expected", but "is". :-) AFAIK there are no implementations of the

I'd missed that this is based on deployed work.  That is a point that 
always makes writing text justifying/motivating the document quite easy: 
  just say that.


> approach taken by RFC 3922 and draft-ietf-simple-cpim-mapping (i.e.,
> mapping to the abstract semantics of RFC 3860), whereas there are
> multiple implementations of the approach described here (i.e., direct
> mapping between SIP and XMPP).
>
>> That is,
>> what makes the current approach notably tractable for implementation and
>> deployment?
>
> Do you think that explaining why would improve the document? IMHO this

I'm a fan of context and systems views, because I think it orients the 
reader usefully, so the simple answer is yes.

Whenever there is a lengthy history with alternative efforts, readers 
can benefit from some context that distinguishes the current work.  Not 
in qualitative terms like better or worse, but in technical and 
operational terms.

Hence I think language like what's already in the document, that 
distinguishes the 'architectural' difference from earlier work, but also 
one that says that the current work is based on deployed industry choice.


> verges into developer psychology (I've got this SIP thing here and this


>>     5.  When showing protocol examples, usually only one side of the
>> sequence is shown.  For gatewaying that does interesting transforms,
>> such as this one, an example should show both the before and after
>> versions.  That is, the 'native' protocol unit that was created and then
>> the one that results from the translation.
>
> I thought we'd already done that. For instance, Example 2 is the SIP
> transformation of the XMPP stanza shown in Example 1.

Either the document didn't do it as diligently as I'm suggesting, or I 
didn't understand this aspect of the document, which might be remedied 
by better labeling.

For any example that is done in a gateway and is a translation between 
sip presence and xmpp presence, something simple and rigorous, such as 
"before" and "after" labels to source and transformed versions, ought to 
remedy this.




>> This probably raises a larger issue:  How much expertise is expected of
>> someone who is implementing this or otherwise reading for deep
>> comprehension?  In the extreme, they will need to have serious expertise
>> on both protocol sets.  The other extreme would be a cookbook inside
>> this document, with no outside knowledge required.  The document needs
>> to specify the nature and extent of the expertise required.  (In fact,
>> the document seems pretty clean, in terms of explaining things, so I
>> suspect that 'fair' knowledge of one suite will suffice.  But the author
>> and wg beliefs about the requirement should be made explicit.)
>
> See above. Perhaps not expert level, but significant familiarity with
> one "side" or the other.

Just to emphasize, whatever the knowledge-level of reader that's 
required, the document should make that explicit.

I'm always a fan of making documents more accessible to wider 
readership, but it's not practical to make all documents fully 
accessible, especially within a suite of docs that build on each other.


>>>     |  SUBSCRIBE sip:romeo@example.net SIP/2.0
>>
>> Later text (section 4.1) equates the label pres: with sip: and sips:.
>> Why choose sip: here?
>
> In practice, we don't see 'pres' URIs in the wild.

Hmmm.  While 'statistics' of use is a relatively fragile basis for 
putting things into a spec -- since a doc can last for decades and 
statistics can change -- it might be worth mentioning as the basis for 
the choice in the doc.  I suppose that's in the realm of giving the 
reader a bit of operational insight.  But definitely not an important point.



>>>     Example 3: SIP accepts subscription request:
>>>
>>>     |  SIP/2.0 200 OK
>>>     |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>>>     |  From: <sip:romeo@example.net>;tag=ffd2
>>>     |  To: <sip:juliet@example.com>;tag=j89d
>>>     |  Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C
>>>     |  CSeq: 234 SUBSCRIBE
>>>     |  Contact: <sip:simple.example.net;transport=tcp>
>>>     |  Expires: 3600
>>>     |  Content-Length: 0
>>
>> Hmmm.  This appears to be the original SIP acceptance, but with no
>> separate display of it's being translated into XMPP.
>
> That is Example 5.

Oh. It's worth making that explicit.  (My tendency to get confused 
reading specs is a useful canary in the tunnel, for what needs 
clarifying for other readers, IMO...)



>>>     Example 10: SIP user subscribes to XMPP contact:
>>>
>>>     |  SUBSCRIBE sip:juliet@example.com SIP/2.0
>>>     |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>>>     |  From: <sip:romeo@example.net>;tag=xfg9
>>>     |  Call-ID: AA5A8BE5-CBB7-42B9-8181-6230012B1E11
>>>     |  Event: presence
>>>     |  Max-Forwards: 70
>>>     |  CSeq: 263 SUBSCRIBE
>>>     |  Contact: <sip:simple.example.net;transport=tcp>
>>>     |  Accept: application/pidf+xml
>>>     |  Content-Length: 0
>>>
>>>     Notice that the "Expires" header was not included in the SUBSCRIBE
>>>     request; this means that the default value of 3600 (i.e., 3600
>>>     seconds = 1 hour) applies.
>>>
>>>     Upon receiving the SUBSCRIBE, the SIP server needs to determine the
>>>     identity of the domain portion of the Request-URI or To header, which
>>>     it does by following the procedures discussed in
>>>     [I-D.ietf-stox-core].  Here we assume that the SIP server has
>>>     determined that the domain is serviced by an XMPP server, that it
>>
>>
>> This seems to mean that a regular SIP server needs to be familiar with
>> technical details in a gatewaying specification??
>
> Well, it is (IMHO) really the responsibility of a core "server" to
> implement this kind of routing functionality, but the "gateway" might
> make the determination that the remote domain uses SIP or XMPP and if
> SIP then pass it on to the SIP "server" and if not handle delivery to

I think this matches the usual model:  an unchanged server does routing 
as if all participants were part of its 'native' protocol service.  A 
gateway translates and tries to hide any differences between two services.

The current doc language seems confusing on this point, when it talks 
about a (native) server choosing a server that is part of the other service.

This is a sufficiently basic point to probably warrant going into -core, 
rather than here.  But the language here probably therefore ought to 
just be in terms of originators and recipients (or whatever generic 
terminology works for presence) with an initial, simple note that 
knowledge of the need for translation only resides in the gateway(s).

But I'm not sure I mentioned another point that confused me from -core: 
  It shows the two types of gateways as talking to each other, but I 
suspect that's not reality.  FOr example, when doing SIP-XMPP, I suspect 
the actual flow is:

    SIP User
    SIP Server
    SIP-XMPP Server
    XMPP Server
    XMPP User

whereas the implication from the -core diagram and some of the language 
in the spec(s) is:

    SIP User
    SIP Server
    SIP-XMPP Server
    XMPP-SIP Server
    XMPP Server
    XMPP Use

If it really is the later sequence, I don't understand why.



> the remote XMPP domain. To some extent it's a matter of implementation
> where exactly the code lives to complete these functions, which is why
> draft-ietf-stox-core talks about a "SIP service" consisting of both a
> SIP "server" and a "gateway". In XMPP this translation function is often
> handled by what we call a "connection manager", but that depends a bit
> on the internal architecture of the overall "service".

This point highlights the essential difference between a "networking 
architecture" and an "implementation architecture".

Mapping from the first to the second often permits very wide variations. 
  The former concerns distinct functionality that /can/ be distributed, 
where the latter makes specific choices for what /is/ distributed.




>>>     As described in [RFC3856], presence information about an entity is
>>>     communicated by means of a SIP NOTIFY event sent from a SIP user
>>>     agent to an intended recipient who is most generally referenced by an
>>>     Presence URI of the form <pres:user@domain> but who might be
>>>     referenced by a SIP or SIPS URI of the form <sip:user@domain> or
>>>     <sips:user@domain>.  Here again we introduce the simplifying
>>>     assumption that the user agent is controlled by a human user.
>>
>> I guess I'm not understanding how the nature of what is controlling the
>> agent affects anything in this document.  Might be worth explaining that.
>
> A "presentity" doesn't have to be a human -- it could be a bot, a
> device, or some other automated entity. People related more to human users.

Sure, but when reading the doc, it felt as if the reference to this 
issue was relevant to functionality.  I'd expect the issue to be raised 
once in an Intro and then avoided later by use of a neutral term like 
user or presentity or whatever.



>>>     Note the following regarding these mappings:
>>>
>>>     1.  Only a presence stanza that lacks a 'type' attribute or whose
>>
>>     presence -> XMPP presence
>
> Stanzas are an XMPP artifact. But yes.

Choosing the level of semantic redundancy in the language is always a 
balancing act.  In a gatewaying document that will be reader by folks 
likely to be expert in only one half of the necessary technologies, I'd 
be inclined towards more redundancy, to reduce likelihood of 
misunderstanding...



>>>         'type' attribute has a value of "unavailable" SHOULD be mapped by
>>>         an XMPP-SIMPLE gateway to a SIP NOTIFY request, since those are
>>>         the only presence stanzas that represent notifications.
>>>     2.  The PIDF schema defines the tuple 'id' attribute as having a
>>>         datatype of "xs:ID"; because this datatype is more restrictive
>>>         than the "xs:string" datatype for XMPP resourceparts (in
>>>         particular, a number is not allowed as the first character of an
>>>         ID), it is RECOMMENDED to prepend the resourcepart with "ID-" or
>>>         some other alphabetic string when mapping from XMPP to SIP.
>>>     3.  This mapping is OPTIONAL.
>>
>> What does that mean?  This sort of mapping is usually the essence of
>> gatewaying semantics.  How can interoperability tolerate it's being
>> optional?
>
> In XMPP, the 'id' attribute is not usually included in presence stanzas,
> and nothing is lost if it's ignored. But I'll give it a bit more thought.
>
>>> 4.3.  SIP to XMPP
>>>
>>>     When Romeo changes his presence, his SIP user agent generates a SIP
>>
>> Romeo is doing SIP?  And Juliet does XMPP?
>
> You noticed, eh? "Juliet does Jabber" makes it easy to remember, at
> least for me.

So why isn't the other side Steve or Sid or...

Nevermind...



>> So, SIP is more macho than XMPP???
>
> Have you configured a SIP client lately? ;-)
>
> But seriously, the Romeo and Juliet scenarios enable me to use a male

The word seriously is entirely out of scope for this segment.  Or at 
least, it certainly was when I started it...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

From stpeter@stpeter.im  Tue Dec 17 07:58:15 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4E61AE177 for <stox@ietfa.amsl.com>; Tue, 17 Dec 2013 07:58:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.43
X-Spam-Level: 
X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuHamBVif8pA for <stox@ietfa.amsl.com>; Tue, 17 Dec 2013 07:58:13 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DD1061AE179 for <stox@ietf.org>; Tue, 17 Dec 2013 07:58:12 -0800 (PST)
Received: from sjc-vpn6-418.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3F3504010C; Tue, 17 Dec 2013 08:58:11 -0700 (MST)
Message-ID: <52B07491.8020209@stpeter.im>
Date: Tue, 17 Dec 2013 08:58:09 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Yana Stamcheva <yana@jitsi.org>, stox@ietf.org
References: <E44893DD4E290745BB608EB23FDDB7620A13923B@008-AM1MPN1-041.mgdnok.nokia.com> <98C874C8-756C-4509-AD0C-7E1C796D849A@jitsi.org>
In-Reply-To: <98C874C8-756C-4509-AD0C-7E1C796D849A@jitsi.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [Stox] Reminder: Dec 17 virtual interim meeting
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2013 15:58:15 -0000

Thanks, Yana. I've just joined. :-)

On 12/16/13 7:44 AM, Yana Stamcheva wrote:
> Hi,
> 
> This is a reminder for the STOX virtual interim meeting to be held _tomorrow_ (Dec 17 at 16:00 (4PM) UTC).
> 
> Below are the preliminary agenda and the WebEx details.
> 
> As stated before, the main topic of the meeting will be the -media draft. The draft has been updated from the authors as promised and the current version is -02 ( http://tools.ietf.org/html/draft-ietf-stox-media-02 ).
> 
> Regards,
> Yana
> 
> On 27 Nov 2013, at 10:28, Markus.Isomaki@nokia.com wrote:
> 
>> Hi,
>>
>> Here are the details of the STOX virtual interim to be held on Dec 17.
>>
>> The current version of draft-ietf-stox-media is -01, but the authors have promised an update latest one week before the meeting. 
>>
>> ---
>>
>> IP-to-XMPP (STOX) WG virtual interim
>>
>> Date: December 17, 2013
>> Time: 16:00 (4PM) UTC
>> Maximum length: 1.5 hours
>>
>> Chairs:
>> Markus Isomäki, markus.isomaki@nokia.com
>> Yana Stamcheva, yana@jitsi.org
>>
>> The meeting will focus on the "Media Sessions" draft:
>> http://datatracker.ietf.org/doc/draft-ietf-stox-media/
>>
>> Agenda
>>
>> (Subject to updates)
>>
>> 1. Opening (chairs, 5 min.)
>>  - Minutes, agenda bash
>> 2. STOX WG status (chairs, 5 min.)
>>   - Where we are with core, presence, im, chat and groupchat 3. Media signaling walkthrough (Co-authors, 20 min.)
>>  - Explain how it is supposed to work
>>  - Clarifying questions allowed
>> 4. Media signaling open issues and discussion (Co-authors, max. 50 min.)
>>  - Resolve issues if possible, Assign actions, Plan next revisions 
>> 5. Summary and closing (chairs)
>>
>> Overall time max. 90 minutes.
>>
>> ---
>>
>> WebEx info
>>
>> Topic: STOX 
>> Date: Tuesday, December 17, 2013 
>> Time: 3:45 pm, GMT Time (London, GMT) 
>> Meeting Number: 640 253 699 
>> Meeting Password: 1234 
>>
>>
>> ------------------------------------------------------- 
>> To join the online meeting (Now from mobile devices!) 
>> ------------------------------------------------------- 
>> 1. Go to https://ietf.webex.com/ietf/j.php?ED=255438447&UID=1705818657&PW=NMWE5Y2VkNDlk&RT=MiMyMQ%3D%3D
>> 2. If requested, enter your name and email address. 
>> 3. If a password is required, enter the meeting password: 1234 
>> 4. Click "Join". 
>>
>> To view in other time zones or languages, please click the link: 
>> https://ietf.webex.com/ietf/j.php?ED=255438447&UID=1705818657&PW=NMWE5Y2VkNDlk&ORT=MiMyMQ%3D%3D
>>
>> ------------------------------------------------------- 
>> To join the audio conference only 
>> ------------------------------------------------------- 
>> Call-in toll number (US/Canada): 1-650-479-3208 
>>
>> Access code:640 253 699 
>>
>> ------------------------------------------------------- 
>> For assistance 
>> ------------------------------------------------------- 
>> 1. Go to https://ietf.webex.com/ietf/mc
>> 2. On the left navigation bar, click "Support". 
>>
>> You can contact me at: 
>> cmorgan@amsl.com
>> 1-510-492-4085 
>>
>> To add this meeting to your calendar program (for example Microsoft Outlook), click this link: 
>> https://ietf.webex.com/ietf/j.php?ED=255438447&UID=1705818657&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAgoDDRu-EEpTt7AnfETJtAMkYVk-agl8tiR29/c7Cm/U&RT=MiMyMQ%3D%3D
>>
>> The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. 
>>
>> Sign up for a free trial of WebEx 
>> http://www.webex.com/go/mcemfreetrial
>>
>> http://www.webex.com
>>
>> CCP:+16504793208x640253699# 
>>
>> IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. 
>>

From fippo@goodadvice.pages.de  Tue Dec 17 10:55:54 2013
Return-Path: <fippo@goodadvice.pages.de>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E7A1AE2BC for <stox@ietfa.amsl.com>; Tue, 17 Dec 2013 10:55:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYxkVSYIV2X1 for <stox@ietfa.amsl.com>; Tue, 17 Dec 2013 10:55:52 -0800 (PST)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 6329A1AE25C for <stox@ietf.org>; Tue, 17 Dec 2013 10:55:27 -0800 (PST)
Received: from [192.168.2.101] (p5497395E.dip0.t-ipconnect.de [84.151.57.94]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id rBHItOpF026929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <stox@ietf.org>; Tue, 17 Dec 2013 19:55:25 +0100
Message-ID: <52B09E17.3030707@goodadvice.pages.de>
Date: Tue, 17 Dec 2013 19:55:19 +0100
From: Philipp Hancke <fippo@goodadvice.pages.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: stox@ietf.org
References: <20131212182625.7247.96401.idtracker@ietfa.amsl.com>
In-Reply-To: <20131212182625.7247.96401.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Stox] I-D Action: draft-ietf-stox-media-02.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2013 18:55:54 -0000

> Abstract:
>     This document defines a bi-directional protocol mapping for use by
>     gateways that enable the exchange of media signalling messages
>     between systems that implement the Jingle extensions to the
>     Extensible Messaging and Presence Protocol (XMPP) and those that
>     implement the Session Initiation Protocol (SIP).
>

A couple of comments, I just had some time (90 minutes :-)) to review this:

Section 5.1:
	the syntax and semantics of <description/> element are defined
	in [XEP-0167]

nit: 0167 defines the semantics of <description/> elements in the 
urn:xmpp:...:rtp:1 namespace. Giving 0167 again as an example for other 
description types in the next sentence is somewhat odd.

	<content/> 'name'
maps to a=mid: from RFC 5888 -- not sure if that is required for the 
basic usecase.
	<content/> 'profile'
0167 does (in it's current version) not have a profile. This was removed 
in Version 0.23 (2008-07-31).

	the 'action'  attribute [...] nine allowable values
No, it's 15. The missing ones are content-reject, description-info, 
security-info, transport-reject, transport-replace, transport-accept.

All the transport- are unused. description-info is for suggested 
application parameters (width, height), so we dont need it either. 
security-info is only used for xtls, so unused, too. I am not sure about 
content-reject.

Section 6:
senders can also have a value of "none" which maps to a=inactive. That 
is only in XEP-0166 and not in 0167.
Actually, Jingle has a cool message for hold which is content-modify 
(which only modifies senders). Why bother with two hold mechanisms when 
you can have three :-)

Section 9:
s/comas/commas/

XEP-0177 doesn't define <format/>. 0167 defines <parameter/> which is 
what you describe (and it does so in a wrong way, spec bug).

I think DTMF is the relevant example for bullet #3 (example from RFC 4733)
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Saul : I think I disagree with your comment about name being required by 
the xep's schema (which isn't normative anyway), both are required.
My take (after some discussions in jingle@) is that 'name' should be 
left empty and you should put the stuff to 'value'.


Section 10:
This section actually concerns me. Jingle is based on full jids 
typically. So in order to forward a call from a SIP entity to an xmpp 
entity, the gateway needs to determine which full jid to send to.
So it either has to have a presence subscription or can use presence 
decloaking (XEP-0276; deferred because of inactivity but works nicely).
If there are multiple possible resources, the gateway needs to decide, 
where to route the call.
As Emil mentioned, some people (i.e. me) are considering using 
<message/> for the session-initiate which would allow an xmppish way of 
forking (Jonathan: want to help out? :-)), but that is not ready yet.



Section 11.1:
the candidate in the example should probably have an id (at least where 
the 0177 schema is concerned which is not normative).
It might be worth noting (elsewhere?) that Jingle and SIP do ice 
restarts differently WRT to the generation parameter.

The last example contains a reasoncode='no-error'. I am not sure what 
old version of jingle this comes from, these days it's done with
<reason><success/></reason>


other issues:
routing of <iq/> (for the jingle->sip call-a-telephone-number usecase) 
that was raised at the end of the meeting:
this should go to the bare JID. Semantically, this means "don't route it 
to a client, server handles it". Here, the 'server' is handling it.


Peter: during the call I made a note "more disco#info examples", I think 
this was based on a comment by Markus about capability negotiation. I 
hope I remember the actual context when seeing the minutes.

From yana@sip-communicator.org  Wed Dec 18 06:56:48 2013
Return-Path: <yana@sip-communicator.org>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DF81AE16A for <stox@ietfa.amsl.com>; Wed, 18 Dec 2013 06:56:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.25
X-Spam-Level: 
X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYk1E55ZBsux for <stox@ietfa.amsl.com>; Wed, 18 Dec 2013 06:56:47 -0800 (PST)
Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 165C51AE250 for <stox@ietf.org>; Wed, 18 Dec 2013 06:56:46 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id m15so7459184wgh.1 for <stox@ietf.org>; Wed, 18 Dec 2013 06:56:45 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to; bh=lKL3F7cYXU1TMUq7/rel3DElnx6uovbu3HYdLUSvR3Y=; b=nK/Moc99RtsKldn5rLElsuufC6rvjBw6HhoIlMsYobPijdxR4lrLUmXBZyRJPHUzJY y93na2uYRwAmq9NJt2W3zNb/8OHijZMNyT/+g5aIgqJ28va6LNtQTn0OOTOxh/3jjorH qFMn1jaUHGO/Y+aLy+dSv30HY49e4L+W7dy3aqdZG24Diik6ngDao/o9FRCXJuH9yo8Z CP236k8Pao/WRhfmN9k2q9NAF7eYAdqiNl6qxEMmJpyVeu6sfNbt1p7hi/3o5biK+rMx PSJCo7lD3SuZKDSXFp6U95ZXEK+14NhChfPn7l+bzgz1dfBdqtyUCka9KQjJGiG5iIYO JASg==
X-Gm-Message-State: ALoCoQl7RX/kUM7J0dSXVbK7wmvMrBCtwpToRwYKNMO08t6ZLNcMbqhHnlI099UXoRxq1/xlFqa7
X-Received: by 10.194.237.99 with SMTP id vb3mr25080852wjc.28.1387378605115; Wed, 18 Dec 2013 06:56:45 -0800 (PST)
Received: from reserve-yana.u-strasbg.fr (reserve-yana.u-strasbg.fr. [130.79.90.241]) by mx.google.com with ESMTPSA id bc5sm1647234wib.4.2013.12.18.06.56.42 for <stox@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Dec 2013 06:56:44 -0800 (PST)
From: Yana Stamcheva <yana@jitsi.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_23ED128E-DD3B-4062-AA1F-7BCB6CEF6155"
Message-Id: <D940F7CB-995E-423C-B9E8-938627A35269@jitsi.org>
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Priority: 3
Date: Wed, 18 Dec 2013 15:56:40 +0100
References: <946598303.441581387375983490.JavaMail.nobody@rva2rmd001.webex.com>
To: stox@ietf.org
X-Mailer: Apple Mail (2.1827)
Subject: [Stox] STOX Virtual Interim Meeting 2013-12-17 Recording
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Dec 2013 14:56:49 -0000

--Apple-Mail=_23ED128E-DD3B-4062-AA1F-7BCB6CEF6155
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Thanks to all the participants in the interim meeting!

Below you'll find the WebEx recording of the meeting.

Begin forwarded message:

> From: Cindy Morgan <messenger@webex.com>
> Subject: Invitation to view WebEx recording "STOX-20131217 1603-1"
> Date: 18 Dec 2013 15:13:03 GMT+1
> To: yana@jitsi.org
> Reply-To: cmorgan@amsl.com
>=20
> I want to share the following WebEx recording with you. Click the link =
below to play it:=20
>=20
> =
https://ietf.webex.com/ietf/ldr.php?AT=3Dpb&SP=3DMC&rID=3D19788772&rKey=3D=
bf9fb06ac41c884e=20
>=20
> STOX-20131217 1603-1=20
> December 17, 2013, 9:34 am San Francisco Time=20
> 1 hour 28 mins=20
>=20
>=20
>=20
> If you need assistance, you can contact me at cmorgan@amsl.com.=20
>=20
> http://www.webex.com=20


--Apple-Mail=_23ED128E-DD3B-4062-AA1F-7BCB6CEF6155
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Thanks =
to all the participants in the interim meeting!<div><br></div><div>Below =
you'll find the WebEx recording of the =
meeting.</div><div><div><br><div>Begin forwarded message:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; color:rgba(0, =
0, 0, 1.0);"><b>From: </b></span><span =
style=3D"font-family:'Helvetica';">Cindy Morgan &lt;<a =
href=3D"mailto:messenger@webex.com">messenger@webex.com</a>&gt;<br></span>=
</div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px;"><span style=3D"font-family:'Helvetica'; =
color:rgba(0, 0, 0, 1.0);"><b>Subject: </b></span><span =
style=3D"font-family:'Helvetica';"><b>Invitation to view WebEx recording =
"STOX-20131217 1603-1"</b><br></span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Date: =
</b></span><span style=3D"font-family:'Helvetica';">18 Dec 2013 15:13:03 =
GMT+1<br></span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>To: =
</b></span><span style=3D"font-family:'Helvetica';"><a =
href=3D"mailto:yana@jitsi.org">yana@jitsi.org</a><br></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; color:rgba(0, =
0, 0, 1.0);"><b>Reply-To: </b></span><span =
style=3D"font-family:'Helvetica';"><a =
href=3D"mailto:cmorgan@amsl.com">cmorgan@amsl.com</a><br></span></div><br>=
<div><font face=3D"Tahoma, Arial, sans-serif, Helvetica, Geneva" =
size=3D"2">I want to share the following WebEx recording with you. Click =
the link below to play it: <br> <br> <a =
href=3D"https://ietf.webex.com/ietf/ldr.php?AT=3Dpb&amp;SP=3DMC&amp;rID=3D=
19788772&amp;rKey=3Dbf9fb06ac41c884e" =
target=3D"_blank">https://ietf.webex.com/ietf/ldr.php?AT=3Dpb&amp;SP=3DMC&=
amp;rID=3D19788772&amp;rKey=3Dbf9fb06ac41c884e</a> <br> <br> =
STOX-20131217 1603-1 <br> December 17, 2013, 9:34 am San Francisco Time =
<br> 1 hour 28 mins <br> <br> <br> <br> If you need assistance, you can =
contact me at  <a href=3D"mailto:cmorgan@amsl.com">cmorgan@amsl.com</a>. =
<br> <br> <a href=3D"http://www.webex.com/" =
target=3D"_blank">http://www.webex.com</a> =
<br></font></div></blockquote></div><br></div></body></html>=

--Apple-Mail=_23ED128E-DD3B-4062-AA1F-7BCB6CEF6155--

From internet-drafts@ietf.org  Thu Dec 19 15:11:19 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1361AEBFD; Thu, 19 Dec 2013 15:11:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf6-ogo92Xzn; Thu, 19 Dec 2013 15:11:18 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D641AC7F3; Thu, 19 Dec 2013 15:11:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.84
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131219231118.8714.29043.idtracker@ietfa.amsl.com>
Date: Thu, 19 Dec 2013 15:11:18 -0800
Cc: stox@ietf.org
Subject: [Stox] I-D Action: draft-ietf-stox-core-09.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2013 23:11:20 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.

	Title           : Interworking between the Session Initiation Protocol (SI=
P) and the Extensible Messaging and Presence Protocol (XMPP): Architecture,=
 Addresses, and Error Handling
	Author(s)       : Peter Saint-Andre
                          Avshalom Houri
                          Joe Hildebrand
	Filename        : draft-ietf-stox-core-09.txt
	Pages           : 20
	Date            : 2013-12-19

Abstract:
   As a foundation for the definition of bidirectional protocol mappings
   between the Session Initiation Protocol (SIP) and the Extensible
   Messaging and Presence Protocol (XMPP), this document specifies the
   architectural assumptions underlying such mappings as well as the
   mapping of addresses and error conditions.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-stox-core

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-stox-core-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-core-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From mary.ietf.barnes@gmail.com  Tue Dec 24 12:22:11 2013
Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8551AE07E for <stox@ietfa.amsl.com>; Tue, 24 Dec 2013 12:22:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Level: 
X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCIpDvdpzmx3 for <stox@ietfa.amsl.com>; Tue, 24 Dec 2013 12:22:10 -0800 (PST)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id AD01C1AE041 for <stox@ietf.org>; Tue, 24 Dec 2013 12:22:09 -0800 (PST)
Received: by mail-wi0-f176.google.com with SMTP id hq4so12313186wib.3 for <stox@ietf.org>; Tue, 24 Dec 2013 12:22:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5/8oFdHCxSr+g++DljFcCuyrDEfhbHpWiIuadGEBe/Y=; b=W2aSjKlXxNxsWv0ZTRByizHCyXlKeMd1auotT0HjqGjzptOBWxWBM78i3VIgxSNrQJ OOI6hiKYvST8ob6N224On+7jpyA9xEj9TA+FlphuymPlSCejxdqdnPOrwzB7PPwwjpJL kcQgBNmbo3JQ7cYHb89FBLcRhlILBmiAB7BaVGiueUxE9NooCk7HcdHbP5qANrYISCBm Sd5DlmyTn7fcK6ws3n7vlm/4aWjEgzuvcHblwhWpNspL6KdoKRa+F3seyMLY7OzkY2dj gohuEV0L9VK7x2ljW6ryH9Pn0z+ejyzGOHb67EEdw9Tf2jdoIgJbnVF1ZLax6OdgKbMG w/Uw==
MIME-Version: 1.0
X-Received: by 10.194.161.233 with SMTP id xv9mr55108wjb.79.1387916525474; Tue, 24 Dec 2013 12:22:05 -0800 (PST)
Received: by 10.216.172.9 with HTTP; Tue, 24 Dec 2013 12:22:05 -0800 (PST)
Date: Tue, 24 Dec 2013 14:22:05 -0600
Message-ID: <CAHBDyN6YOZeFQ4RnOXNKkgeE1Tov9E08VAN0-Vi4USJ8j64BmA@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: stox@ietf.org, draft-ietf-stox-im@tools.ietf.org
Content-Type: multipart/alternative; boundary=089e013d1f9e7a97ee04ee4d7f48
Subject: [Stox] Post-WGLC review: draft-ietf-stox-im-06
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Dec 2013 20:22:11 -0000

--089e013d1f9e7a97ee04ee4d7f48
Content-Type: text/plain; charset=ISO-8859-1

HI all,

I've reviewed the document and believe it's ready to progress with a couple
of minor clarification/nit fixes required.

- Section 1, 1st bullet.  RFC 3428 was not developed in the SIMPLE WG.  It
was a product of the old SIP WG.  I would suggest to reword that bullet as
follows:
      Various extensions to the Session Initiation Protocol ([RFC3261])
      for instant messaging,  including the MESSAGE method extension
[RFC3428].

- Related to my previous comment,  there shouldn't be any references to a
SIMPLE-XMPP Gateway, which is used widely in the document, although there
are some places where SIP-XMPP is used, which is more correct.

- All  occurrences of "SIMPLE Server" should be changed to "SIP Server"

Regards,
Mary.

--089e013d1f9e7a97ee04ee4d7f48
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">HI all,<div><br></div><div>I&#39;ve reviewed the document =
and believe it&#39;s ready to progress with a couple of minor clarification=
/nit fixes required.=A0</div><div><br></div><div>- Section 1, 1st bullet. =
=A0RFC 3428 was not developed in the SIMPLE WG. =A0It was a product of the =
old SIP WG. =A0I would suggest to reword that bullet as follows:</div>
<div><div>=A0 =A0 =A0 Various extensions to the Session Initiation Protocol=
 ([RFC3261])</div><div>=A0 =A0 =A0 for instant messaging, =A0including the =
MESSAGE method extension [RFC3428].</div></div><div><br></div><div>- Relate=
d to my previous comment, =A0there shouldn&#39;t be any references to a SIM=
PLE-XMPP Gateway, which is used widely in the document, although there are =
some places where SIP-XMPP is used, which is more correct.</div>
<div><br></div><div>- All =A0occurrences of &quot;SIMPLE Server&quot; shoul=
d be changed to &quot;SIP Server&quot;=A0</div><div><br></div><div>Regards,=
</div><div>Mary.</div><div><br></div><div><br></div></div>

--089e013d1f9e7a97ee04ee4d7f48--

From mary.ietf.barnes@gmail.com  Tue Dec 24 12:57:05 2013
Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF02A1AE090 for <stox@ietfa.amsl.com>; Tue, 24 Dec 2013 12:57:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePmhuJRlx_aj for <stox@ietfa.amsl.com>; Tue, 24 Dec 2013 12:57:04 -0800 (PST)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7261AE08F for <stox@ietf.org>; Tue, 24 Dec 2013 12:57:04 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id hq4so11775967wib.5 for <stox@ietf.org>; Tue, 24 Dec 2013 12:57:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=T30sBS5o9/oAldW2Fjd85q4eco+b3kc+A3Ic9cZIKYc=; b=j+1CBUYNeVCAL18bFpterQ1Xs2RJRqW5YXrOeonTZptuCaZ5CdsecjZuaBeZQ2jjpa tytTtl5WKIcD52IN5V1RTAoLB0jHsOLoeMxqMgIXzs4Yxeo/JAA0JcIMsH2xJ/53h6HC qNqE7g8EfN5hcBQNY2osKTtDRgQaO51jk9d528yM7rksm36tXFgHRE8aON6FtYug3o7H 69iNAP0jWncUzzeL1GypyZ+mj0GV4yLfbNfV56wCyGPwKwSYZ7a/JwS+FCsBnA9AHgO4 iIsVV4WgpOcMewctPwiuhzNyx1k/OKDceaWR1n27+j6koFNtTg9qB3yVa7cYsTtH0fs9 e02Q==
MIME-Version: 1.0
X-Received: by 10.180.206.41 with SMTP id ll9mr23620017wic.7.1387918620217; Tue, 24 Dec 2013 12:57:00 -0800 (PST)
Received: by 10.216.172.9 with HTTP; Tue, 24 Dec 2013 12:57:00 -0800 (PST)
Date: Tue, 24 Dec 2013 14:57:00 -0600
Message-ID: <CAHBDyN5B3ktS+HozmMz9=1ggXpE=EexWbwJemj2YQ6TX2xmB8g@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: stox@ietf.org, draft-ietf-stox-chat@tools.ietf.org
Content-Type: multipart/alternative; boundary=001a11c3888255d85004ee4dfca6
Subject: [Stox] Post-WGLC Review: draft-ietf-stox-chat
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Dec 2013 20:57:05 -0000

--001a11c3888255d85004ee4dfca6
Content-Type: text/plain; charset=ISO-8859-1

HI all,

I've reviewed the document and believe it's ready to progress with a few
changes/minor nits fixed:

1) Section 3.    The text related to F6 uses the term MSRP user agent. That
term isn't used at all in RFC 4975, in particular since an MSRP user
doesn't have to be a SIP User agent.  I would suggest to just reword as
follows:
OLD
   Romeo can then send a reply using his MSRP user agent.
NEW
   Romeo can then send a reply using his MSRP client.

2) Section 4.  The numbered references to Fx are off by one starting with
Example 16:, which should be F7 and not F8.  F9 should be F8 and F10 should
be F9.

3) Section 9.  RFC 4975 should be referenced for security for MSRP rather
than RFC 3428.

4) References.  RFC 3428 should be removed as a reference as MSRP/RFC 4975
is entirely independent of the MESSAGE/RFC 3428.

Regards,
Mary.

--001a11c3888255d85004ee4dfca6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">HI all,<div><br></div><div>I&#39;ve reviewed the document =
and believe it&#39;s ready to progress with a few changes/minor nits fixed:=
</div><div><br></div><div>1) Section 3. =A0 =A0The text related to F6 uses =
the term MSRP user agent. That term isn&#39;t used at all in RFC 4975, in p=
articular since an MSRP user doesn&#39;t have to be a SIP User agent. =A0I =
would suggest to just reword as follows:</div>
<div>OLD</div><div>=A0 =A0Romeo can then send a reply using his MSRP user a=
gent.</div><div>NEW</div><div>=A0 =A0Romeo can then send a reply using his =
MSRP client.</div><div><br></div><div>2) Section 4. =A0The numbered referen=
ces to Fx are off by one starting with Example 16:, which should be F7 and =
not F8. =A0F9 should be F8 and F10 should be F9.=A0</div>
<div><br></div><div>3) Section 9. =A0RFC 4975 should be referenced for secu=
rity for MSRP rather than RFC 3428. =A0=A0</div><div><br></div><div>4) Refe=
rences. =A0RFC 3428 should be removed as a reference as MSRP/RFC 4975 is en=
tirely independent of the MESSAGE/RFC 3428. =A0=A0</div>
<div><br></div><div>Regards,</div><div>Mary.=A0</div>















</div>

--001a11c3888255d85004ee4dfca6--