From fippo@goodadvice.pages.de  Tue Feb  4 12:56:50 2014
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 EE0181A011E for <stox@ietfa.amsl.com>; Tue,  4 Feb 2014 12:56:49 -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_15=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 xmvEQaWD5pk2 for <stox@ietfa.amsl.com>; Tue,  4 Feb 2014 12:56:47 -0800 (PST)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF541A010F for <stox@ietf.org>; Tue,  4 Feb 2014 12:56:46 -0800 (PST)
Received: from [192.168.2.101] (p54973908.dip0.t-ipconnect.de [84.151.57.8]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id s14Kuikm021128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <stox@ietf.org>; Tue, 4 Feb 2014 21:56:46 +0100
Message-ID: <52F15406.9090008@goodadvice.pages.de>
Date: Tue, 04 Feb 2014 21:56:38 +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> <52B09E17.3030707@goodadvice.pages.de> <52EC22E4.5040700@stpeter.im>
In-Reply-To: <52EC22E4.5040700@stpeter.im>
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, 04 Feb 2014 20:56:50 -0000

Am 31.01.2014 23:25, schrieb Peter Saint-Andre:
> On 12/17/13, 10:55 AM, Philipp Hancke wrote:
>>> 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:
>
> Thanks, Philipp. Sorry about the delay in replying - as you might be
> aware I've had quite a bit happening since the interim meeting. ;-)

heh :-)

[... snipping where +1]


> As you know, that's used by the recipient to decline the addition of a
> new content type to the session (e.g., the other party wants to add
> video to an audio-only session). Potentially we could map this to a SIP
> 415 Unsupported Media Type response. However, this wouldn't round-trip
> very well because the stox-core document says to map SIP 415 to XMPP
> <not-acceptable/> whereas Jingle content-reject is not an stanza-level
> error but a Jingle-level response.

Tricky... the xmppish way to do this would be to discover support via 
disco/caps.
[...]
>> 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 :-)
>
> Sure, the more the merrier. :P
>
> Is senders='none' implemented for hold functionality? We've been trying
> to define only what is in general use.

Emil?

[...]
>> XEP-0177 doesn't define <format/>. 0167 defines <parameter/> which is
>> what you describe (and it does so in a wrong way, spec bug).
>
> Are you saying there is a spec bug in XEP-0167 or in the stox-media I-D?

stox-media should use <parameter/>. We need to fix the spec bug in 0167 
at some point, but that's an XSF activity.

> Naturally, this <parameter/> element works only for RTP communications,
> not other Jingle applications (say, file transfer). So we'll mention
> that in the text.

well, the general pattern is reused in some specs (0293 + 0294 IIRC), 
but those are RTP-related, so yeah.

>> 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'.
>
> Yes, that seems better. Notice how RFC 4733 says the following things
> represent the same information:
>
> (1)
>
>        audio/telephone-event;events="0-15,66,70";rate="8000"
>
> and
>
> (2)
>
>        m=audio 12346 RTP/AVP 100
>        a=rtpmap:100 telephone-event/8000
>        a=fmtp:100 0-15,66,70
>
> Although (1) says events='', the events name doesn't appear in (2). So
> putting the stuff in the <parameter value=''/> (and empty name) seems
> reasonable.

uhm... no. This would be
<parameter name='' value='0-15,66,70'/>
Just show me your draft before submitting ;-)

>> 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.
>
> The text here talks about the XMPP 'from' address that the gateway will
> place on provisional responses received from the SIP side. Since there
> might be multiple responses, we're saying to ignore the GRUU and make
> believe that the JID-equivalent of the SIP sender is a bare JID, not a
> full JID.
>
> I'm not yet convinced that this is the best we can do in the SIP to XMPP
> direction, but it might be...

Some things I discussed with Lance Stout at the recent XMPP summit about 
jingle+Forking+Push might be useful here. But those are probably too 
vague and untested yet, so we might need to invest some work into 
getting 0276 into a formally better state. It works quite well in 
practice, so...

[...]
>> 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 needs to have a 'component' attribute too, per XEP-0177.

good catch.

[...]
>> 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.
>
> I'll need to listen to the audio recording in order to know the context
> here.

the discussion starts around 01:16, specifically Emil's comment at 
01:17:30 about sending from bare jids. IMO it's semantically ok to use 
bare jids on the XMPP side. But a hardcoded resource like "foo" doesn't 
hurt either and is likely to break less assumptions from client developers.

>> 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.
>
> As in all of these mapping specs, we try not to reply too much on
> discovering the capabilities of other entities, since SIP doesn't have
> any reliable facilities for that. But if you remember the context, let
> us know. :-)

need to listen to the full recording again... more soon.

thanks peter!

From stpeter@stpeter.im  Tue Feb  4 18:42:56 2014
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 349A31A01B7 for <stox@ietfa.amsl.com>; Tue,  4 Feb 2014 18:42:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.837
X-Spam-Level: 
X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.535, 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 G1Yqi2hfJacH for <stox@ietfa.amsl.com>; Tue,  4 Feb 2014 18:42:53 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D51F01A01A6 for <stox@ietf.org>; Tue,  4 Feb 2014 18:42:52 -0800 (PST)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2E431403AE; Tue,  4 Feb 2014 19:42:52 -0700 (MST)
Message-ID: <52F1A52A.1030603@stpeter.im>
Date: Tue, 04 Feb 2014 19:42:50 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Philipp Hancke <fippo@goodadvice.pages.de>, stox@ietf.org
References: <20131212182625.7247.96401.idtracker@ietfa.amsl.com> <52B09E17.3030707@goodadvice.pages.de> <52EC22E4.5040700@stpeter.im> <52F15406.9090008@goodadvice.pages.de>
In-Reply-To: <52F15406.9090008@goodadvice.pages.de>
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: Wed, 05 Feb 2014 02:42:56 -0000

On 2/4/14, 1:56 PM, Philipp Hancke wrote:
> Am 31.01.2014 23:25, schrieb Peter Saint-Andre:
>> On 12/17/13, 10:55 AM, Philipp Hancke wrote:

> [... snipping where +1]

Same.

>> As you know, that's used by the recipient to decline the addition of a
>> new content type to the session (e.g., the other party wants to add
>> video to an audio-only session). Potentially we could map this to a SIP
>> 415 Unsupported Media Type response. However, this wouldn't round-trip
>> very well because the stox-core document says to map SIP 415 to XMPP
>> <not-acceptable/> whereas Jingle content-reject is not an stanza-level
>> error but a Jingle-level response.
>
> Tricky... the xmppish way to do this would be to discover support via
> disco/caps.

Right. Given that we don't have such methods on the SIP side, I don't 
think we can make a strong recommendation here.

>>> XEP-0177 doesn't define <format/>. 0167 defines <parameter/> which is
>>> what you describe (and it does so in a wrong way, spec bug).
>>
>> Are you saying there is a spec bug in XEP-0167 or in the stox-media I-D?
>
> stox-media should use <parameter/>. We need to fix the spec bug in 0167
> at some point, but that's an XSF activity.

Hmm, XEP-0167 has lots of things like this:

<parameter name='foo' value='bar'/>

But if there's a spec bug in XEP-0167, let's discuss it on the 
jingle@xmpp.org list. :-)

>>> 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'.
>>
>> Yes, that seems better. Notice how RFC 4733 says the following things
>> represent the same information:
>>
>> (1)
>>
>>        audio/telephone-event;events="0-15,66,70";rate="8000"
>>
>> and
>>
>> (2)
>>
>>        m=audio 12346 RTP/AVP 100
>>        a=rtpmap:100 telephone-event/8000
>>        a=fmtp:100 0-15,66,70
>>
>> Although (1) says events='', the events name doesn't appear in (2). So
>> putting the stuff in the <parameter value=''/> (and empty name) seems
>> reasonable.
>
> uhm... no. This would be
> <parameter name='' value='0-15,66,70'/>

Right, exactly. I was just being too terse in what I wrote.

> Just show me your draft before submitting ;-)

Keeping it updated in SVN for sure:

http://svn.tools.ietf.org/svn/wg/stox/

>>> 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.
>>
>> The text here talks about the XMPP 'from' address that the gateway will
>> place on provisional responses received from the SIP side. Since there
>> might be multiple responses, we're saying to ignore the GRUU and make
>> believe that the JID-equivalent of the SIP sender is a bare JID, not a
>> full JID.
>>
>> I'm not yet convinced that this is the best we can do in the SIP to XMPP
>> direction, but it might be...
>
> Some things I discussed with Lance Stout at the recent XMPP summit about
> jingle+Forking+Push might be useful here. But those are probably too
> vague and untested yet, so we might need to invest some work into
> getting 0276 into a formally better state. It works quite well in
> practice, so...

I've always liked that Presence Decloaking stuff in XEP-0276, but it's 
not implemented widely if at all, so I don't think it's correct for us 
to recommend it in draft-ietf-stox-media.

>>> 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.
>>
>> I'll need to listen to the audio recording in order to know the context
>> here.
>
> the discussion starts around 01:16, specifically Emil's comment at
> 01:17:30 about sending from bare jids. IMO it's semantically ok to use
> bare jids on the XMPP side. But a hardcoded resource like "foo" doesn't
> hurt either and is likely to break less assumptions from client developers.

Ick, hardcoding. :(

But I'll listen to the recording soon and think about the issue more fully.

Peter

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

From internet-drafts@ietf.org  Fri Feb  7 08:20:35 2014
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 0307D1A04F5; Fri,  7 Feb 2014 08:20:35 -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 ZeS0jcathgbs; Fri,  7 Feb 2014 08:20:33 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A951A01F0; Fri,  7 Feb 2014 08:20:33 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140207162033.25749.11153.idtracker@ietfa.amsl.com>
Date: Fri, 07 Feb 2014 08:20:33 -0800
Cc: stox@ietf.org
Subject: [Stox] I-D Action: draft-ietf-stox-presence-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: Fri, 07 Feb 2014 16:20:35 -0000

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

        Title           : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence
        Authors         : Peter Saint-Andre
                          Avshalom Houri
                          Joe Hildebrand
	Filename        : draft-ietf-stox-presence-08.txt
	Pages           : 28
	Date            : 2014-02-07

Abstract:
   This document defines a bi-directional protocol mapping for the
   exchange of presence information 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-presence/

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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-presence-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 stpeter@stpeter.im  Fri Feb  7 08:22:23 2014
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 AFBF91A0594 for <stox@ietfa.amsl.com>; Fri,  7 Feb 2014 08:22:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 GV4gjuGF0XcC for <stox@ietfa.amsl.com>; Fri,  7 Feb 2014 08:22:22 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 604861A0585 for <stox@ietf.org>; Fri,  7 Feb 2014 08:22:22 -0800 (PST)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 597244010C; Fri,  7 Feb 2014 09:22:22 -0700 (MST)
Message-ID: <52F5083D.9060106@stpeter.im>
Date: Fri, 07 Feb 2014 09:22:21 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: stox@ietf.org
References: <20140207162033.25749.11153.idtracker@ietfa.amsl.com>
In-Reply-To: <20140207162033.25749.11153.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-presence-08.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: Fri, 07 Feb 2014 16:22:23 -0000

Changes to address IESG and SecDir feedback...

On 2/7/14, 9:20 AM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.
>
>          Title           : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence
>          Authors         : Peter Saint-Andre
>                            Avshalom Houri
>                            Joe Hildebrand
> 	Filename        : draft-ietf-stox-presence-08.txt
> 	Pages           : 28
> 	Date            : 2014-02-07
>
> Abstract:
>     This document defines a bi-directional protocol mapping for the
>     exchange of presence information 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-presence/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-stox-presence-08
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-presence-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/
>
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox
>


From internet-drafts@ietf.org  Sun Feb  9 18:38:31 2014
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 465C71A06F7; Sun,  9 Feb 2014 18:38:31 -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 Ey1ZhFRnMOzf; Sun,  9 Feb 2014 18:38:29 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0821A05D9; Sun,  9 Feb 2014 18:38:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140210023829.6466.31703.idtracker@ietfa.amsl.com>
Date: Sun, 09 Feb 2014 18:38:29 -0800
Cc: stox@ietf.org
Subject: [Stox] I-D Action: draft-ietf-stox-presence-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: Mon, 10 Feb 2014 02:38:31 -0000

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

        Title           : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence
        Authors         : Peter Saint-Andre
                          Avshalom Houri
                          Joe Hildebrand
	Filename        : draft-ietf-stox-presence-09.txt
	Pages           : 28
	Date            : 2014-02-09

Abstract:
   This document defines a bi-directional protocol mapping for the
   exchange of presence information 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-presence/

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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-presence-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 stpeter@stpeter.im  Sun Feb  9 18:39:47 2014
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 B88DF1A05D9 for <stox@ietfa.amsl.com>; Sun,  9 Feb 2014 18:39:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 ifPLaQkOXSqb for <stox@ietfa.amsl.com>; Sun,  9 Feb 2014 18:39:45 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3DD1A062A for <stox@ietf.org>; Sun,  9 Feb 2014 18:39:45 -0800 (PST)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A062E4032A; Sun,  9 Feb 2014 19:39:38 -0700 (MST)
Message-ID: <52F83BE7.8010700@stpeter.im>
Date: Sun, 09 Feb 2014 19:39:35 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: stox@ietf.org
References: <20140210023829.6466.31703.idtracker@ietfa.amsl.com>
In-Reply-To: <20140210023829.6466.31703.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Pete Resnick <presnick@qti.qualcomm.com>
Subject: Re: [Stox] I-D Action: draft-ietf-stox-presence-09.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: Mon, 10 Feb 2014 02:39:47 -0000

Pete Resnick caught several more errors, which are corrected in this 
version.

On 2/9/14, 7:38 PM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.
>
>          Title           : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence
>          Authors         : Peter Saint-Andre
>                            Avshalom Houri
>                            Joe Hildebrand
> 	Filename        : draft-ietf-stox-presence-09.txt
> 	Pages           : 28
> 	Date            : 2014-02-09
>
> Abstract:
>     This document defines a bi-directional protocol mapping for the
>     exchange of presence information 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-presence/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-stox-presence-09
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-presence-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/
>
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox
>



From stpeter@stpeter.im  Mon Feb 10 10:24:22 2014
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 593A71A031B; Mon, 10 Feb 2014 10:24:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 GtQUG9d1weZX; Mon, 10 Feb 2014 10:24:20 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A97EE1A01F1; Mon, 10 Feb 2014 10:24:20 -0800 (PST)
Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3F668403BB; Mon, 10 Feb 2014 11:24:20 -0700 (MST)
Message-ID: <52F91953.8010604@stpeter.im>
Date: Mon, 10 Feb 2014 11:24:19 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: The IESG <iesg@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
Subject: [Stox] Stephen Farrell's IESG feedback on draft-ietf-stox-core
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, 10 Feb 2014 18:24:22 -0000

( + STOX WG since one of the issues might deserve broader discussion )

Hi Stephen, thanks for your review:

https://datatracker.ietf.org/doc/draft-ietf-stox-core/ballot/

You wrote in part:

    - I wondered why you didn't just say that (D)TLS SHOULD
    be used/supported between gateways. Given that all the
    relevant bits of code are likely to support that, wouldn't
    it be a good thing?

Yes, that seems eminently reasonable.

    - Has anyone thought about confusability in the name
    mappings? I expected to see a bit of text in the
    security considerations but didn't see it.

Confusion is always possible. :-) Were you thinking about confusable 
characters from Unicode, or something else?

    - It seems a shame to not be able to gateway when the To is
    a sips URI at all but I understand that some loss of
    security is inevitable for cases like this. Is there any
    work planned for an update that would allow gatewaying for
    such cases, e.g. if the 1st XMPP server is the one to which
    the user is connected and the user is connected using
    XMPP/TLS?

Hmm. I cannot say that I am aware of planning for updates to provide 
more secure gatewaying, although folks active in the STOX WG might be 
thinking along those lines.

Depending on the deployment architecture, I think there are cases where 
it is *possible* to TLS-protect all the hops. For instance, if 
sip.example.org has a direct server-to-server connection to 
xmpp.example.com (no intermediate hops) and both organizations agree to 
force the use of TLS for client connections (e.g., via SLA), then I 
suppose that sip.example.com could honor 'sips' URIs when sending 
traffic to xmpp.example.com. However, such an arrangement is rare enough 
right now that I don't know if it is worth mentioning.

Peter

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

From stpeter@stpeter.im  Mon Feb 10 14:08:52 2014
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 3C10E1A0447; Mon, 10 Feb 2014 14:08:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 8oEImfb2ND7C; Mon, 10 Feb 2014 14:08:49 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 77CA91A089E; Mon, 10 Feb 2014 14:08:49 -0800 (PST)
Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DD2E3403BB; Mon, 10 Feb 2014 15:08:48 -0700 (MST)
Message-ID: <52F94DF0.1030505@stpeter.im>
Date: Mon, 10 Feb 2014 15:08:48 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: The IESG <iesg@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
Subject: [Stox] Pete Resnick's IESG feedback on draft-ietf-stox-core
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, 10 Feb 2014 22:08:52 -0000

Pete, you wrote:

   Section 4 is (nicely) clear on the document architecturally
   describing a gateway. However, traditionally a gateway is
   transparent to the entity that communicates with it: When we
   had SMTP-to-X.400 gateways, the gateway appeared as just another
   SMTP system that noticed special qualities of the address and
   then routed the messages appropriately.

Your "traditionally" sounds like an SMTP phenomenon. In XMPP, we don't 
have intermediate transfer agents, and XMPP servers are designed to use 
add-on modules for additional functionality. So in the XMPP universe it 
makes sense for the operator of an XMPP service to install a module (in 
addition to the XMPP server) that performs the gateway function (we 
often call this a connection manager).

   Section 5 describes
   something a bit different. It's not clear that what section 5
   describes actually is part of the gateway, but rather sounds
   like a combined server which does failover between the
   protocols. I don't think this is a showstopper, but it might
   help implementers significantly if you described in section 5
   *where* in the model this function occurs. Right now, it
   sounds like the server itself does the addressing failover,
   not the gateway.

Yes, I see your point. This kind of thing is quite likely implementation 
specific (e.g., when the add-on XMPP-to-SIP gateway module gets 
configured into and trusted by the core XMPP server, it might get added 
into an event listener for core stanza delivery if an XMPP lookup fails 
for the remote domain). Let me look at what text might be useful here.

Peter

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


From stephen.farrell@cs.tcd.ie  Mon Feb 10 14:20:43 2014
Return-Path: <stephen.farrell@cs.tcd.ie>
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 39BA61A08A8; Mon, 10 Feb 2014 14:20:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 4hlNwvD2W78s; Mon, 10 Feb 2014 14:20:37 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDD61A08A1; Mon, 10 Feb 2014 14:20:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 463DEBE39; Mon, 10 Feb 2014 22:20:36 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOqRtpAfRzpz; Mon, 10 Feb 2014 22:20:34 +0000 (GMT)
Received: from [10.87.48.4] (unknown [86.46.19.178]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 829D1BE25; Mon, 10 Feb 2014 22:20:34 +0000 (GMT)
Message-ID: <52F950B2.2050107@cs.tcd.ie>
Date: Mon, 10 Feb 2014 22:20:34 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>, The IESG <iesg@ietf.org>
References: <52F91953.8010604@stpeter.im>
In-Reply-To: <52F91953.8010604@stpeter.im>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
Subject: Re: [Stox] Stephen Farrell's IESG feedback on draft-ietf-stox-core
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, 10 Feb 2014 22:20:43 -0000

Hi Peter,

On 02/10/2014 06:24 PM, Peter Saint-Andre wrote:
> ( + STOX WG since one of the issues might deserve broader discussion )
> 
> Hi Stephen, thanks for your review:
> 
> https://datatracker.ietf.org/doc/draft-ietf-stox-core/ballot/
> 
> You wrote in part:
> 
>    - I wondered why you didn't just say that (D)TLS SHOULD
>    be used/supported between gateways. Given that all the
>    relevant bits of code are likely to support that, wouldn't
>    it be a good thing?
> 
> Yes, that seems eminently reasonable.

Just to be clear - the above is the only DISCUSS point.

> 
>    - Has anyone thought about confusability in the name
>    mappings? I expected to see a bit of text in the
>    security considerations but didn't see it.
> 
> Confusion is always possible. :-) Were you thinking about confusable
> characters from Unicode, or something else?

Right. Maybe its all there already and I just didn't see
if in the mapping stuff, or maybe not. I'm not sure.

> 
>    - It seems a shame to not be able to gateway when the To is
>    a sips URI at all but I understand that some loss of
>    security is inevitable for cases like this. Is there any
>    work planned for an update that would allow gatewaying for
>    such cases, e.g. if the 1st XMPP server is the one to which
>    the user is connected and the user is connected using
>    XMPP/TLS?
> 
> Hmm. I cannot say that I am aware of planning for updates to provide
> more secure gatewaying, although folks active in the STOX WG might be
> thinking along those lines.
> 
> Depending on the deployment architecture, I think there are cases where
> it is *possible* to TLS-protect all the hops. For instance, if
> sip.example.org has a direct server-to-server connection to
> xmpp.example.com (no intermediate hops) and both organizations agree to
> force the use of TLS for client connections (e.g., via SLA), then I
> suppose that sip.example.com could honor 'sips' URIs when sending
> traffic to xmpp.example.com. However, such an arrangement is rare enough
> right now that I don't know if it is worth mentioning.

Fair enough. I can see that detecting that you (probably) have
all (D)TLS hops might be tricky and error prone.

Cheers,
S.


> 
> Peter
> 


From stpeter@stpeter.im  Mon Feb 10 14:52:34 2014
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 8A01F1A08A8; Mon, 10 Feb 2014 14:52:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 JnXoVvwH4QVE; Mon, 10 Feb 2014 14:52:29 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF601A08AA; Mon, 10 Feb 2014 14:52:12 -0800 (PST)
Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F2536403BB; Mon, 10 Feb 2014 15:52:11 -0700 (MST)
Message-ID: <52F9581B.9060008@stpeter.im>
Date: Mon, 10 Feb 2014 15:52:11 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
References: <52F91953.8010604@stpeter.im> <52F950B2.2050107@cs.tcd.ie>
In-Reply-To: <52F950B2.2050107@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
Subject: Re: [Stox] Stephen Farrell's IESG feedback on draft-ietf-stox-core
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, 10 Feb 2014 22:52:34 -0000

On 2/10/14, 3:20 PM, Stephen Farrell wrote:
>
> Hi Peter,
>
> On 02/10/2014 06:24 PM, Peter Saint-Andre wrote:
>> ( + STOX WG since one of the issues might deserve broader discussion )
>>
>> Hi Stephen, thanks for your review:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-stox-core/ballot/
>>
>> You wrote in part:
>>
>>     - I wondered why you didn't just say that (D)TLS SHOULD
>>     be used/supported between gateways. Given that all the
>>     relevant bits of code are likely to support that, wouldn't
>>     it be a good thing?
>>
>> Yes, that seems eminently reasonable.
>
> Just to be clear - the above is the only DISCUSS point.

Yep.

>>     - Has anyone thought about confusability in the name
>>     mappings? I expected to see a bit of text in the
>>     security considerations but didn't see it.
>>
>> Confusion is always possible. :-) Were you thinking about confusable
>> characters from Unicode, or something else?
>
> Right. Maybe its all there already and I just didn't see
> if in the mapping stuff, or maybe not. I'm not sure.

Section 10.5 of draft-ietf-precis-framework has some very nice text 
about visually similar characters. We could borrow from that.

>>     - It seems a shame to not be able to gateway when the To is
>>     a sips URI at all but I understand that some loss of
>>     security is inevitable for cases like this. Is there any
>>     work planned for an update that would allow gatewaying for
>>     such cases, e.g. if the 1st XMPP server is the one to which
>>     the user is connected and the user is connected using
>>     XMPP/TLS?
>>
>> Hmm. I cannot say that I am aware of planning for updates to provide
>> more secure gatewaying, although folks active in the STOX WG might be
>> thinking along those lines.
>>
>> Depending on the deployment architecture, I think there are cases where
>> it is *possible* to TLS-protect all the hops. For instance, if
>> sip.example.org has a direct server-to-server connection to
>> xmpp.example.com (no intermediate hops) and both organizations agree to
>> force the use of TLS for client connections (e.g., via SLA), then I
>> suppose that sip.example.com could honor 'sips' URIs when sending
>> traffic to xmpp.example.com. However, such an arrangement is rare enough
>> right now that I don't know if it is worth mentioning.
>
> Fair enough. I can see that detecting that you (probably) have
> all (D)TLS hops might be tricky and error prone.

That's how I see it.

Oh, and we at least need to mention DTLS for the UDP cases, though (see 
Section 5 of draft-ietf-stox-core).

Peter

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


From stpeter@stpeter.im  Mon Feb 10 16:11:30 2014
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 E9EAB1A060E; Mon, 10 Feb 2014 16:11:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 YYWjF2pIzAM4; Mon, 10 Feb 2014 16:11:23 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 29C0C1A0626; Mon, 10 Feb 2014 16:11:22 -0800 (PST)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 42ED3403BB; Mon, 10 Feb 2014 17:11:22 -0700 (MST)
Message-ID: <52F96AA8.2010408@stpeter.im>
Date: Mon, 10 Feb 2014 17:11:20 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: The IESG <iesg@ietf.org>
References: <52F94DF0.1030505@stpeter.im>
In-Reply-To: <52F94DF0.1030505@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
Subject: Re: [Stox] Pete Resnick's IESG feedback on draft-ietf-stox-core
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, 11 Feb 2014 00:11:31 -0000

On 2/10/14, 3:08 PM, Peter Saint-Andre wrote:
> Pete, you wrote:
>
>    Section 4 is (nicely) clear on the document architecturally
>    describing a gateway. However, traditionally a gateway is
>    transparent to the entity that communicates with it: When we
>    had SMTP-to-X.400 gateways, the gateway appeared as just another
>    SMTP system that noticed special qualities of the address and
>    then routed the messages appropriately.
>
> Your "traditionally" sounds like an SMTP phenomenon. In XMPP, we don't
> have intermediate transfer agents, and XMPP servers are designed to use
> add-on modules for additional functionality. So in the XMPP universe it
> makes sense for the operator of an XMPP service to install a module (in
> addition to the XMPP server) that performs the gateway function (we
> often call this a connection manager).
>
>    Section 5 describes
>    something a bit different. It's not clear that what section 5
>    describes actually is part of the gateway, but rather sounds
>    like a combined server which does failover between the
>    protocols. I don't think this is a showstopper, but it might
>    help implementers significantly if you described in section 5
>    *where* in the model this function occurs. Right now, it
>    sounds like the server itself does the addressing failover,
>    not the gateway.
>
> Yes, I see your point. This kind of thing is quite likely implementation
> specific (e.g., when the add-on XMPP-to-SIP gateway module gets
> configured into and trusted by the core XMPP server, it might get added
> into an event listener for core stanza delivery if an XMPP lookup fails
> for the remote domain). Let me look at what text might be useful here.

How is this for proposed text?

    Existing SIP and XMPP server implementations do not typically include
    the ability to communicate using the other technology (XMPP for SIP
    implementations, SIP for XMPP implementations).  One common
    architectural pattern is to associate a gateway with the core server
    implementation (e.g., in XMPP such a gateway might be called a
    "connection manager").  How exactly such a gateway interacts with the
    core server to complete tasks such as address lookups and
    communication with systems that use the other technology is a matter
    of implementation (e.g., the gateway might be an add-on module that
    is trusted by the core server to act as a fallback delivery mechanism
    if the remote domain does not support the server's native
    communication technology).

Peter

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


From internet-drafts@ietf.org  Mon Feb 10 20:48:51 2014
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 6E73F1A07A3; Mon, 10 Feb 2014 20:48:51 -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 xu-IpmW04ArW; Mon, 10 Feb 2014 20:48:49 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5481A079C; Mon, 10 Feb 2014 20:48:49 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140211044849.25090.12298.idtracker@ietfa.amsl.com>
Date: Mon, 10 Feb 2014 20:48:49 -0800
Cc: stox@ietf.org
Subject: [Stox] I-D Action: draft-ietf-stox-core-10.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, 11 Feb 2014 04:48:51 -0000

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

        Title           : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling
        Authors         : Peter Saint-Andre
                          Avshalom Houri
                          Joe Hildebrand
	Filename        : draft-ietf-stox-core-10.txt
	Pages           : 23
	Date            : 2014-02-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-10

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


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 Feb 11 06:11:45 2014
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 0C8B61A0325 for <stox@ietfa.amsl.com>; Tue, 11 Feb 2014 06:11:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 q0co4NQkSR_V for <stox@ietfa.amsl.com>; Tue, 11 Feb 2014 06:11:38 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 174971A032D for <stox@ietf.org>; Tue, 11 Feb 2014 06:11:38 -0800 (PST)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 786FC4032A; Tue, 11 Feb 2014 07:11:37 -0700 (MST)
Message-ID: <52FA2F99.40803@stpeter.im>
Date: Tue, 11 Feb 2014 07:11:37 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: stox@ietf.org
References: <20140211044849.25090.12298.idtracker@ietfa.amsl.com>
In-Reply-To: <20140211044849.25090.12298.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-core-10.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, 11 Feb 2014 14:11:45 -0000

Some adjustments to address IESG feedback.

On 2/10/14, 9:48 PM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.
>
>          Title           : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling
>          Authors         : Peter Saint-Andre
>                            Avshalom Houri
>                            Joe Hildebrand
> 	Filename        : draft-ietf-stox-core-10.txt
> 	Pages           : 23
> 	Date            : 2014-02-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-10
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-core-10
>
>
> 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/
>
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox
>


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


From iesg-secretary@ietf.org  Tue Feb 11 07:31:15 2014
Return-Path: <iesg-secretary@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 197601A0376; Tue, 11 Feb 2014 07:31:15 -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 8qk01fyRAkjx; Tue, 11 Feb 2014 07:31:13 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A17E1A0548; Tue, 11 Feb 2014 07:31:10 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140211153110.4224.770.idtracker@ietfa.amsl.com>
Date: Tue, 11 Feb 2014 07:31:10 -0800
Cc: stox mailing list <stox@ietf.org>, stox chair <stox-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Stox] Protocol Action: 'Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence' to Proposed Standard (draft-ietf-stox-presence-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: Tue, 11 Feb 2014 15:31:15 -0000

The IESG has approved the following document:
- 'Interworking between the Session Initiation Protocol (SIP) and the
   Extensible Messaging and Presence Protocol (XMPP): Presence'
  (draft-ietf-stox-presence-09.txt) as Proposed Standard

This document is the product of the SIP-TO-XMPP Working Group.

The IESG contact persons are Gonzalo Camarillo and Richard Barnes.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-stox-presence/




Technical Summary

  Relevant content can frequently be found in the abstract 
  and/or introduction of the document. If not, this may be 
  an indication that there are deficiencies in the abstract 
  or introduction.

This document defines a bi-directional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).

Working Group Summary

  Was there anything in WG process that is worth noting? For 
  example, was there controversy about particular points or 
  were there decisions where the consensus was particularly 
  rough?

This document has been initially reviewed in the DISPATCH WG as per the RAI area process for new work. The STOX WG has been chartered as a result of the submission of this and other documents that aim to define specifications for interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) based systems. This document has been subjected to a number of thorough reviews initially in the DISPATCH WG and in the STOX WG after its creation. There were no controversial points regarding it.

Document Quality

  Are there existing implementations of the protocol? Have a 
  significant number of vendors indicated their plan to 
  implement the specification? Are there any reviewers that 
  merit special mention as having done a thorough review, 
  e.g., one that resulted in important changes or a 
  conclusion that the document had no substantive issues? If 
  there was a MIB Doctor, Media Type or other expert review, 
  what was its course (briefly)? In the case of a Media Type 
  review, on what date was the request posted?

There are already several vendors having full or partial implementations of the specification, among which Jabber/Cisco, Kamailio (OpenSER), AG Projects (Silk Server). Some of the people behind these implementations have actively participated in the discussions in the WG.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Yana Stamcheva is the document shepherd. The responsible area director is Gonzalo Camarillo.


From stpeter@stpeter.im  Tue Feb 11 07:49:52 2014
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 9438C1A0502; Tue, 11 Feb 2014 07:49:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 zXOAGY8RJKwU; Tue, 11 Feb 2014 07:49:50 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BA45B1A0583; Tue, 11 Feb 2014 07:49:48 -0800 (PST)
Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3DF6D4032A; Tue, 11 Feb 2014 08:49:48 -0700 (MST)
Message-ID: <52FA469B.40203@stpeter.im>
Date: Tue, 11 Feb 2014 08:49:47 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
References: <52F91953.8010604@stpeter.im> <52F950B2.2050107@cs.tcd.ie> <52F9581B.9060008@stpeter.im>
In-Reply-To: <52F9581B.9060008@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
Subject: Re: [Stox] Stephen Farrell's IESG feedback on draft-ietf-stox-core
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, 11 Feb 2014 15:49:52 -0000

On 2/10/14, 3:52 PM, Peter Saint-Andre wrote:
> On 2/10/14, 3:20 PM, Stephen Farrell wrote:
>>
>> Hi Peter,
>>
>> On 02/10/2014 06:24 PM, Peter Saint-Andre wrote:
>>> ( + STOX WG since one of the issues might deserve broader discussion )
>>>
>>> Hi Stephen, thanks for your review:
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-stox-core/ballot/
>>>
>>> You wrote in part:
>>>
>>>     - I wondered why you didn't just say that (D)TLS SHOULD
>>>     be used/supported between gateways. Given that all the
>>>     relevant bits of code are likely to support that, wouldn't
>>>     it be a good thing?
>>>
>>> Yes, that seems eminently reasonable.
>>
>> Just to be clear - the above is the only DISCUSS point.
>
> Yep.
>
>>>     - Has anyone thought about confusability in the name
>>>     mappings? I expected to see a bit of text in the
>>>     security considerations but didn't see it.
>>>
>>> Confusion is always possible. :-) Were you thinking about confusable
>>> characters from Unicode, or something else?
>>
>> Right. Maybe its all there already and I just didn't see
>> if in the mapping stuff, or maybe not. I'm not sure.
>
> Section 10.5 of draft-ietf-precis-framework has some very nice text
> about visually similar characters. We could borrow from that.
>
>>>     - It seems a shame to not be able to gateway when the To is
>>>     a sips URI at all but I understand that some loss of
>>>     security is inevitable for cases like this. Is there any
>>>     work planned for an update that would allow gatewaying for
>>>     such cases, e.g. if the 1st XMPP server is the one to which
>>>     the user is connected and the user is connected using
>>>     XMPP/TLS?
>>>
>>> Hmm. I cannot say that I am aware of planning for updates to provide
>>> more secure gatewaying, although folks active in the STOX WG might be
>>> thinking along those lines.
>>>
>>> Depending on the deployment architecture, I think there are cases where
>>> it is *possible* to TLS-protect all the hops. For instance, if
>>> sip.example.org has a direct server-to-server connection to
>>> xmpp.example.com (no intermediate hops) and both organizations agree to
>>> force the use of TLS for client connections (e.g., via SLA), then I
>>> suppose that sip.example.com could honor 'sips' URIs when sending
>>> traffic to xmpp.example.com. However, such an arrangement is rare enough
>>> right now that I don't know if it is worth mentioning.
>>
>> Fair enough. I can see that detecting that you (probably) have
>> all (D)TLS hops might be tricky and error prone.
>
> That's how I see it.
>
> Oh, and we at least need to mention DTLS for the UDP cases, though (see
> Section 5 of draft-ietf-stox-core).

Hi Stephen,

We've posted an updated version:

https://datatracker.ietf.org/doc/draft-ietf-stox-core/

http://tools.ietf.org/rfcdiff?url2=draft-ietf-stox-core-10.txt

We haven't yet added any text about visually similar characters, though. 
Let me know what you think of the rest.

Peter

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


From stpeter@stpeter.im  Tue Feb 11 07:51:39 2014
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 5BAC81A050B; Tue, 11 Feb 2014 07:51:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 W_c4gYjwSYu3; Tue, 11 Feb 2014 07:51:36 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DCE451A0308; Tue, 11 Feb 2014 07:51:35 -0800 (PST)
Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7B77C4032A; Tue, 11 Feb 2014 08:51:35 -0700 (MST)
Message-ID: <52FA4707.30808@stpeter.im>
Date: Tue, 11 Feb 2014 08:51:35 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: The IESG <iesg@ietf.org>
References: <52F94DF0.1030505@stpeter.im> <52F96AA8.2010408@stpeter.im>
In-Reply-To: <52F96AA8.2010408@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
Subject: Re: [Stox] Pete Resnick's IESG feedback on draft-ietf-stox-core
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, 11 Feb 2014 15:51:39 -0000

On 2/10/14, 5:11 PM, Peter Saint-Andre wrote:
> On 2/10/14, 3:08 PM, Peter Saint-Andre wrote:
>> Pete, you wrote:
>>
>>    Section 4 is (nicely) clear on the document architecturally
>>    describing a gateway. However, traditionally a gateway is
>>    transparent to the entity that communicates with it: When we
>>    had SMTP-to-X.400 gateways, the gateway appeared as just another
>>    SMTP system that noticed special qualities of the address and
>>    then routed the messages appropriately.
>>
>> Your "traditionally" sounds like an SMTP phenomenon. In XMPP, we don't
>> have intermediate transfer agents, and XMPP servers are designed to use
>> add-on modules for additional functionality. So in the XMPP universe it
>> makes sense for the operator of an XMPP service to install a module (in
>> addition to the XMPP server) that performs the gateway function (we
>> often call this a connection manager).
>>
>>    Section 5 describes
>>    something a bit different. It's not clear that what section 5
>>    describes actually is part of the gateway, but rather sounds
>>    like a combined server which does failover between the
>>    protocols. I don't think this is a showstopper, but it might
>>    help implementers significantly if you described in section 5
>>    *where* in the model this function occurs. Right now, it
>>    sounds like the server itself does the addressing failover,
>>    not the gateway.
>>
>> Yes, I see your point. This kind of thing is quite likely implementation
>> specific (e.g., when the add-on XMPP-to-SIP gateway module gets
>> configured into and trusted by the core XMPP server, it might get added
>> into an event listener for core stanza delivery if an XMPP lookup fails
>> for the remote domain). Let me look at what text might be useful here.
>
> How is this for proposed text?
>
>     Existing SIP and XMPP server implementations do not typically include
>     the ability to communicate using the other technology (XMPP for SIP
>     implementations, SIP for XMPP implementations).  One common
>     architectural pattern is to associate a gateway with the core server
>     implementation (e.g., in XMPP such a gateway might be called a
>     "connection manager").  How exactly such a gateway interacts with the
>     core server to complete tasks such as address lookups and
>     communication with systems that use the other technology is a matter
>     of implementation (e.g., the gateway might be an add-on module that
>     is trusted by the core server to act as a fallback delivery mechanism
>     if the remote domain does not support the server's native
>     communication technology).

Pete, that text is now in draft-ietf-stox-core-10.

Peter

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


From stephen.farrell@cs.tcd.ie  Tue Feb 11 07:54:57 2014
Return-Path: <stephen.farrell@cs.tcd.ie>
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 D76031A01A8; Tue, 11 Feb 2014 07:54:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 r5HTzJfolu6w; Tue, 11 Feb 2014 07:54:55 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5021A01FD; Tue, 11 Feb 2014 07:54:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4308FBE59; Tue, 11 Feb 2014 15:54:54 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qX2lQj0a4kE; Tue, 11 Feb 2014 15:54:54 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D0EE0BE55; Tue, 11 Feb 2014 15:54:53 +0000 (GMT)
Message-ID: <52FA47CD.1000107@cs.tcd.ie>
Date: Tue, 11 Feb 2014 15:54:53 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>, The IESG <iesg@ietf.org>
References: <52F91953.8010604@stpeter.im> <52F950B2.2050107@cs.tcd.ie> <52F9581B.9060008@stpeter.im> <52FA469B.40203@stpeter.im>
In-Reply-To: <52FA469B.40203@stpeter.im>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
Subject: Re: [Stox] Stephen Farrell's IESG feedback on draft-ietf-stox-core
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, 11 Feb 2014 15:54:58 -0000

On 02/11/2014 03:49 PM, Peter Saint-Andre wrote:
> 
> Hi Stephen,
> 
> We've posted an updated version:
> 
> https://datatracker.ietf.org/doc/draft-ietf-stox-core/
> 
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-stox-core-10.txt
> 
> We haven't yet added any text about visually similar characters, though.
> Let me know what you think of the rest.

Its lovely:-)

I've cleared the discuss, happy to chat more about
confusability stuff though I'm pretty sure you and
the WG know lots more about that than I do so I'll
be almost certainly be fine with whatever you think
is right. (Incl. if doing nothing is right.)

Thanks,
S.


From stpeter@stpeter.im  Tue Feb 11 08:05:10 2014
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 BAB781A0609; Tue, 11 Feb 2014 08:05:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 BNW6kxzJY_ct; Tue, 11 Feb 2014 08:05:09 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 44C9A1A0605; Tue, 11 Feb 2014 08:05:09 -0800 (PST)
Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3CFF34032A; Tue, 11 Feb 2014 09:05:08 -0700 (MST)
Message-ID: <52FA4A33.2030206@stpeter.im>
Date: Tue, 11 Feb 2014 09:05:07 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
References: <52F91953.8010604@stpeter.im> <52F950B2.2050107@cs.tcd.ie> <52F9581B.9060008@stpeter.im> <52FA469B.40203@stpeter.im> <52FA47CD.1000107@cs.tcd.ie>
In-Reply-To: <52FA47CD.1000107@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
Subject: Re: [Stox] Stephen Farrell's IESG feedback on draft-ietf-stox-core
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, 11 Feb 2014 16:05:10 -0000

On 2/11/14, 8:54 AM, Stephen Farrell wrote:
>
>
> On 02/11/2014 03:49 PM, Peter Saint-Andre wrote:
>>
>> Hi Stephen,
>>
>> We've posted an updated version:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-stox-core/
>>
>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-stox-core-10.txt
>>
>> We haven't yet added any text about visually similar characters, though.
>> Let me know what you think of the rest.
>
> Its lovely:-)
>
> I've cleared the discuss, happy to chat more about
> confusability stuff though I'm pretty sure you and
> the WG know lots more about that than I do so I'll
> be almost certainly be fine with whatever you think
> is right. (Incl. if doing nothing is right.)

Having just re-read Section 10.5 of draft-ietf-precis-framework, I think 
we might point to that for a helpful treatment of the issues.

Peter

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


From stephen.farrell@cs.tcd.ie  Tue Feb 11 08:06:18 2014
Return-Path: <stephen.farrell@cs.tcd.ie>
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 E2FFD1A0548; Tue, 11 Feb 2014 08:06:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 CxXzMiUKRuY6; Tue, 11 Feb 2014 08:06:17 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 98FD61A0612; Tue, 11 Feb 2014 08:06:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E2462BE59; Tue, 11 Feb 2014 16:06:16 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMI4usRV8zlA; Tue, 11 Feb 2014 16:06:16 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BDCB8BE57; Tue, 11 Feb 2014 16:06:16 +0000 (GMT)
Message-ID: <52FA4A78.6080604@cs.tcd.ie>
Date: Tue, 11 Feb 2014 16:06:16 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>, The IESG <iesg@ietf.org>
References: <52F91953.8010604@stpeter.im> <52F950B2.2050107@cs.tcd.ie> <52F9581B.9060008@stpeter.im> <52FA469B.40203@stpeter.im> <52FA47CD.1000107@cs.tcd.ie> <52FA4A33.2030206@stpeter.im>
In-Reply-To: <52FA4A33.2030206@stpeter.im>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
Subject: Re: [Stox] Stephen Farrell's IESG feedback on draft-ietf-stox-core
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, 11 Feb 2014 16:06:19 -0000

On 02/11/2014 04:05 PM, Peter Saint-Andre wrote:
>>
> 
> Having just re-read Section 10.5 of draft-ietf-precis-framework, I think
> we might point to that for a helpful treatment of the issues.

WFM,
Thanks,
S.


From presnick@qti.qualcomm.com  Tue Feb 11 08:43:41 2014
Return-Path: <presnick@qti.qualcomm.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 798CE1A0548; Tue, 11 Feb 2014 08:43:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level: 
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, 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 o1ke0qzmWLcB; Tue, 11 Feb 2014 08:43:39 -0800 (PST)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2639C1A01FD; Tue, 11 Feb 2014 08:43:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1392137018; x=1423673018; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XQnfIx/nJXe6PDjLb+SYZmpsCPymfxAcbEjWwruJEW8=; b=N7WX1FAcDn+XEOPZZSN70Cy7RBtjloWv+ZmOEYle7I4eXuPYlSaoU/OC hLZ3pFgT2v1cUIwmCaZExkpfiI8EKm5LFanJA8+MZ6EEz7qZQpIPYpjWv edRvUtuKBwOHCKDgMGHVqgsT8EN13budzu9jtv186na9PE+OCsS8HbCwl Y=;
X-IronPort-AV: E=McAfee;i="5400,1158,7345"; a="59222728"
Received: from unknown (HELO Ironmsg03-L.qualcomm.com) ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP; 11 Feb 2014 08:43:38 -0800
X-IronPort-AV: E=McAfee;i="5400,1158,7345"; a="616324885"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Feb 2014 08:43:38 -0800
Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 08:43:38 -0800
Message-ID: <52FA5352.6010401@qti.qualcomm.com>
Date: Tue, 11 Feb 2014 10:44:02 -0600
From: Pete Resnick <presnick@qti.qualcomm.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <52F94DF0.1030505@stpeter.im> <52F96AA8.2010408@stpeter.im> <52FA4707.30808@stpeter.im>
In-Reply-To: <52FA4707.30808@stpeter.im>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.48.1]
Cc: stox@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [Stox] Pete Resnick's IESG feedback on draft-ietf-stox-core
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, 11 Feb 2014 16:43:41 -0000

That's fine.

pr

On 2/11/14 9:51 AM, Peter Saint-Andre wrote:
> On 2/10/14, 5:11 PM, Peter Saint-Andre wrote:
>> On 2/10/14, 3:08 PM, Peter Saint-Andre wrote:
>>> Pete, you wrote:
>>>
>>>    Section 4 is (nicely) clear on the document architecturally
>>>    describing a gateway. However, traditionally a gateway is
>>>    transparent to the entity that communicates with it: When we
>>>    had SMTP-to-X.400 gateways, the gateway appeared as just another
>>>    SMTP system that noticed special qualities of the address and
>>>    then routed the messages appropriately.
>>>
>>> Your "traditionally" sounds like an SMTP phenomenon. In XMPP, we don't
>>> have intermediate transfer agents, and XMPP servers are designed to use
>>> add-on modules for additional functionality. So in the XMPP universe it
>>> makes sense for the operator of an XMPP service to install a module (in
>>> addition to the XMPP server) that performs the gateway function (we
>>> often call this a connection manager).
>>>
>>>    Section 5 describes
>>>    something a bit different. It's not clear that what section 5
>>>    describes actually is part of the gateway, but rather sounds
>>>    like a combined server which does failover between the
>>>    protocols. I don't think this is a showstopper, but it might
>>>    help implementers significantly if you described in section 5
>>>    *where* in the model this function occurs. Right now, it
>>>    sounds like the server itself does the addressing failover,
>>>    not the gateway.
>>>
>>> Yes, I see your point. This kind of thing is quite likely 
>>> implementation
>>> specific (e.g., when the add-on XMPP-to-SIP gateway module gets
>>> configured into and trusted by the core XMPP server, it might get added
>>> into an event listener for core stanza delivery if an XMPP lookup fails
>>> for the remote domain). Let me look at what text might be useful here.
>>
>> How is this for proposed text?
>>
>>     Existing SIP and XMPP server implementations do not typically 
>> include
>>     the ability to communicate using the other technology (XMPP for SIP
>>     implementations, SIP for XMPP implementations).  One common
>>     architectural pattern is to associate a gateway with the core server
>>     implementation (e.g., in XMPP such a gateway might be called a
>>     "connection manager").  How exactly such a gateway interacts with 
>> the
>>     core server to complete tasks such as address lookups and
>>     communication with systems that use the other technology is a matter
>>     of implementation (e.g., the gateway might be an add-on module that
>>     is trusted by the core server to act as a fallback delivery 
>> mechanism
>>     if the remote domain does not support the server's native
>>     communication technology).
>
> Pete, that text is now in draft-ietf-stox-core-10.
>
> Peter
>

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478


From stpeter@stpeter.im  Tue Feb 11 10:33:18 2014
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 8F7241A06E0; Tue, 11 Feb 2014 10:33:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 xYXO5GTIecYL; Tue, 11 Feb 2014 10:33:16 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CF14C1A05E6; Tue, 11 Feb 2014 10:33:16 -0800 (PST)
Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 626BE403C4; Tue, 11 Feb 2014 11:33:15 -0700 (MST)
Message-ID: <52FA6CEA.3030005@stpeter.im>
Date: Tue, 11 Feb 2014 11:33:14 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
References: <52F91953.8010604@stpeter.im> <52F950B2.2050107@cs.tcd.ie> <52F9581B.9060008@stpeter.im> <52FA469B.40203@stpeter.im> <52FA47CD.1000107@cs.tcd.ie> <52FA4A33.2030206@stpeter.im> <52FA4A78.6080604@cs.tcd.ie>
In-Reply-To: <52FA4A78.6080604@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
Subject: Re: [Stox] Stephen Farrell's IESG feedback on draft-ietf-stox-core
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, 11 Feb 2014 18:33:18 -0000

On 2/11/14, 9:06 AM, Stephen Farrell wrote:
>
>
> On 02/11/2014 04:05 PM, Peter Saint-Andre wrote:
>>>
>>
>> Having just re-read Section 10.5 of draft-ietf-precis-framework, I think
>> we might point to that for a helpful treatment of the issues.
>
> WFM,
> Thanks,
> S.

OK, I'll quickly spin a new version that contains the pointer.

Peter

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


From internet-drafts@ietf.org  Tue Feb 11 10:38:35 2014
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 132AB1A06F0; Tue, 11 Feb 2014 10:38:35 -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 EYqgHjjdnCoQ; Tue, 11 Feb 2014 10:38:33 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C681A0657; Tue, 11 Feb 2014 10:38:33 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140211183833.17775.50069.idtracker@ietfa.amsl.com>
Date: Tue, 11 Feb 2014 10:38:33 -0800
Cc: stox@ietf.org
Subject: [Stox] I-D Action: draft-ietf-stox-core-11.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, 11 Feb 2014 18:38:35 -0000

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

        Title           : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling
        Authors         : Peter Saint-Andre
                          Avshalom Houri
                          Joe Hildebrand
	Filename        : draft-ietf-stox-core-11.txt
	Pages           : 23
	Date            : 2014-02-11

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

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


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 Feb 13 06:32:30 2014
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 5A9281A02A4; Thu, 13 Feb 2014 06:32:30 -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 mLoDKuaC5lYB; Thu, 13 Feb 2014 06:32:28 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A40521A0293; Thu, 13 Feb 2014 06:32:28 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140213143228.25479.42416.idtracker@ietfa.amsl.com>
Date: Thu, 13 Feb 2014 06:32:28 -0800
Cc: stox@ietf.org
Subject: [Stox] I-D Action: draft-ietf-stox-media-03.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, 13 Feb 2014 14:32:30 -0000

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

        Title           : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions
        Authors         : Peter Saint-Andre
                          Saul Ibarra
                          Emil Ivov
	Filename        : draft-ietf-stox-media-03.txt
	Pages           : 22
	Date            : 2014-02-13

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

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


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  Thu Feb 13 07:37:53 2014
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 355941A02B4 for <stox@ietfa.amsl.com>; Thu, 13 Feb 2014 07:37:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 jcprIEk1VxX3 for <stox@ietfa.amsl.com>; Thu, 13 Feb 2014 07:37:51 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7F22B1A02DE for <stox@ietf.org>; Thu, 13 Feb 2014 07:37:51 -0800 (PST)
Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 723AD4010C; Thu, 13 Feb 2014 08:37:50 -0700 (MST)
Message-ID: <52FCE6CE.60203@stpeter.im>
Date: Thu, 13 Feb 2014 08:37:50 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: stox@ietf.org
References: <20140213143228.25479.42416.idtracker@ietfa.amsl.com>
In-Reply-To: <20140213143228.25479.42416.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-03.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: Thu, 13 Feb 2014 15:37:53 -0000

This version addresses the feedback from Philipp Hancke. We still need 
to follow up on the feedback from Jonathan Lennox and Paul Kyzivat, add 
more examples, etc. We will do that over the next few weeks, and submit 
the next version soon after IETF 89.

Peter

On 2/13/14, 7:32 AM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.
>
>          Title           : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions
>          Authors         : Peter Saint-Andre
>                            Saul Ibarra
>                            Emil Ivov
> 	Filename        : draft-ietf-stox-media-03.txt
> 	Pages           : 22
> 	Date            : 2014-02-13
>
> 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-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-media-03
>
>
> 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/
>
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox
>


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


From nobody Wed Feb 26 03:59:18 2014
Return-Path: <iesg-secretary@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 D7ED91A02A1; Wed, 26 Feb 2014 03:59:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 iuHGx42Zi_Cc; Wed, 26 Feb 2014 03:59:01 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C981A02C1; Wed, 26 Feb 2014 03:58:57 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140226115857.9426.63528.idtracker@ietfa.amsl.com>
Date: Wed, 26 Feb 2014 03:58:57 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/cAxq8PxiGfeoshMMeFLatfmskSM
Cc: stox mailing list <stox@ietf.org>, stox chair <stox-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Stox] Protocol Action: 'Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling' to Proposed Standard (draft-ietf-stox-core-11.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: Wed, 26 Feb 2014 11:59:08 -0000

The IESG has approved 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-11.txt) as Proposed Standard

This document is the product of the SIP-TO-XMPP Working Group.

The IESG contact persons are Gonzalo Camarillo and Richard Barnes.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-stox-core/




Technical Summary

  Relevant content can frequently be found in the abstract 
  and/or introduction of the document. If not, this may be 
  an indication that there are deficiencies in the abstract 
  or introduction.

This document specifies the fondation underlying the bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). Because of the wide deployment of both technologies it is important to clearly define mappings between them for the sake of interworking. This document inaugurates a series of SIP-XMPP interworking specifications by defining the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.

Working Group Summary

  Was there anything in WG process that is worth noting? For 
  example, was there controversy about particular points or 
  were there decisions where the consensus was particularly 
  rough?

This document has been initially reviewed in the DISPATCH WG as per the RAI area process for new work. The STOX WG has been chartered as a result of the submission of this and other documents that aim to define specifications for interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) based systems. This document has been subjected to a number of thorough reviews initially in the DISPATCH WG and in the STOX WG after its creation. There were no controversial points regarding it.

Document Quality

  Are there existing implementations of the protocol? Have a 
  significant number of vendors indicated their plan to 
  implement the specification? Are there any reviewers that 
  merit special mention as having done a thorough review, 
  e.g., one that resulted in important changes or a 
  conclusion that the document had no substantive issues? If 
  there was a MIB Doctor, Media Type or other expert review, 
  what was its course (briefly)? In the case of a Media Type 
  review, on what date was the request posted?

There are already several vendors having full or partial implementations of the specification, among which Jabber/Cisco, Kamailio (OpenSER), AG Projects (Silk Server). Some of the people behind these implementations have actively participated in the discussions in the WG.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Yana Stamcheva is the document shepherd. The responsible area director is Gonzalo Camarillo.