From mary.ietf.barnes@gmail.com Mon Apr 1 08:48:42 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3839311E80C5 for ; Mon, 1 Apr 2013 08:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqfEA4imOxo2 for ; Mon, 1 Apr 2013 08:48:41 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7637311E80AE for ; Mon, 1 Apr 2013 08:48:41 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id k19so1093847qcs.41 for ; Mon, 01 Apr 2013 08:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pFLSYi7F34K3bKnLneaOiqP8psRea2j0X5QxJLt6s2U=; b=fATed2jnA9e6X+aTx2WnLME5Vn3a7d9FClAnzpiLmTA6JUDPuZFUw+byanM0T0af6C TE7NtIhgq1RMVslUGky8prNaUSUfyLOpvne8HAbD9DybrSDvoVrMCo1Qt8yxEaKJiEp/ aZR3rPk7FSlmILFQBo84bunixIm+/NLYatJLc6NvtJ8D1mdBwCB13FUbklqZll8vzK0Z gqE48b56FPcjejfTyNUFS7fn3prFAt8gJ6Ida3+JwwEXIQ2zH1TU4S7CSQsnX1WuvygI gLdlSJCnzdTAMiFPdon70RM/3cdIBFdaof9rCmsPWTwSwlyHfiHBPitNYJD5WOXxS6ue oBXA== MIME-Version: 1.0 X-Received: by 10.229.136.69 with SMTP id q5mr5050025qct.108.1364831320620; Mon, 01 Apr 2013 08:48:40 -0700 (PDT) Received: by 10.49.94.166 with HTTP; Mon, 1 Apr 2013 08:48:40 -0700 (PDT) In-Reply-To: <004301ce2e30$2317e700$6947b500$@co.in> References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <004301ce2e30$2317e700$6947b500$@co.in> Date: Mon, 1 Apr 2013 10:48:40 -0500 Message-ID: From: Mary Barnes To: Parthasarathi R Content-Type: text/plain; charset=ISO-8859-1 Cc: DISPATCH Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 15:48:42 -0000 Partha, It's not entirely clear to me that RTCWEB is the "compelling" use case for MSRP over websockets. I'd be interested to hear who might think that is the case. I can envision other Real Time applications using web servers to make use of this, as well. I don't see any requirements in the RTCWEB WG (charter or requirements) that indicate this is a compelling use case: http://www.ietf.org/id/draft-ietf-rtcweb-use-cases-and-requirements-10.txt There are no use cases for IM, Chat or MSRP specifically that I could find and I couldn't find anything in the RTCWEB archives: http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10 If there has been discussion, please provide a pointer. The discussion of MSRP over websockets should continue on this mailing list. Per the dispatching of IETF-86 topics, the current proposal is to AD sponsor this document unless there are very compelling reasons not to publish. http://tools.ietf.org/wg/dispatch/trac/wiki The proposal had been for the general discussion of "foo" over websockets to happen on the RAI list. The last I looked there are at least 200 people subscribed to DISPATCH that are not on the RAI area mailing list. I strongly encourage folks with an interest in the topic to make sure they are subscribe to the RAI area mailing list: https://www.ietf.org/mailman/listinfo/rai Regards, Mary. On Sun, Mar 31, 2013 at 11:52 AM, Parthasarathi R wrote: > The compelling reason for this draft is RTCWeb. In case of non-RTCWeb, > TCP Shall be used which avoids the overhead introduced due to > WebSocket. Please clarify in case WebSocket has some specific > advantage over TCP in non-RTCWeb environment. > > In case dispatch or BFCPbis are not the right WG to make recommendation, > then let us discuss in RTCWeb WG itself. Also, Please suggest if any > other mailing list like (rai@ietf.org) is the right place to discuss. > > Thanks > Partha > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Mary Barnes >> Sent: Thursday, March 28, 2013 8:28 PM >> To: DRAGE, Keith (Keith) >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or >> websocket >> >> I don't think it's the job of dispatch or BFCPbis WG to define or even >> make recommendations for RTCWEB. That choice is up to the RTCWEB WG >> and it shouldn't be influencing this work. There are applications >> other than RTCWEB that can and will make use of BFCPbis over >> websockets. I really don't understand why we are getting so hung up >> on this - it's the BFCP messages themselves that are important - how >> one chooses to transport is up to the application. >> >> Mary. >> >> On Thu, Mar 28, 2013 at 7:35 AM, DRAGE, Keith (Keith) >> wrote: >> > From what I have seen of the discussion so far, there appears to be a >> body of support that there is a use case for both BFCP and MSRP over >> websocket, for use in a non-rtcweb environment. >> > >> > If when we get to the rtcweb environment we allow this, and also >> allow a usage over datachannel version, we essentially have two >> solutions in the market place. >> > >> > If that occurs, what guidance will we give to a rtcweb developer as >> to which to implement? >> > >> > Or do we envisage that only one will be allowed (and if so which) in >> an rtcweb environment? >> > >> > >> > >> > Regards >> > >> > Keith >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > From partha@parthasarathi.co.in Mon Apr 1 10:12:05 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7776021E80A5 for ; Mon, 1 Apr 2013 10:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+aelZjgTmMb for ; Mon, 1 Apr 2013 10:12:04 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.238]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC9021E80A0 for ; Mon, 1 Apr 2013 10:12:03 -0700 (PDT) Received: from userPC (unknown [122.179.87.85]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id D12AC3E1C20; Mon, 1 Apr 2013 17:11:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1364836322; bh=j92VBUEI5iw1u1fjBGgzLLzHORu/2YCPA7Z2UrUMdTU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=CYSK0bU4EE78HHxetjCRDjkddMa71dGUMbdOtOxlHRk8oFIhvULpoXLMQhL35NxCU Y55ugTSchb+RpctX5Um79fn/WqPUzwAg4EsNYh4goR3WQg7DUlIEz6VsJhLldRMpe2 eRazd239jdNmG8OCCDQrOmdXBgB1q1SCDoem0oIs= From: "Parthasarathi R" To: "'Mary Barnes'" References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <004301ce2e30$2317e700$6947b500$@co.in> In-Reply-To: Date: Mon, 1 Apr 2013 22:41:55 +0530 Message-ID: <001201ce2efc$0695a5f0$13c0f1d0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4u8GHok4K19FEWSLOxDmNJs4mLDAAA/19Q Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0208.5159BFE2.009C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: 'DISPATCH' Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 17:12:05 -0000 Mary, I think that my point on RTCWEB does not come out well. Browser has the limitation of including TCP applications (like BFCP over TCP) directly. To achieve this Datachannel or WebSocket Shall be used which is under discussion here. As you mentioned, RTCWeb WG does not cover these usecases. The discussion required in RTCWeb WG whether BFCP and MSRP usecase are qualified as usecase or as the additional usecase (sec 8 of draft-ietf-rtcweb-use-cases-and-requirements-10) as other conference related usecases exist in additional usecase already. Please note that browser limitation does not apply for the generic Web (HTTP) client. In your envisioned Real time applications using web servers, web client shall use TCP for BFCP & MSRP as web client MUST support TCP protocol. It is not clear to me why websocket is required for those real time applications. As you suggest, Let us discuss in RAI for further discussion on "foo" over WebSocket or Datachannel. Thanks Partha > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > Sent: Monday, April 01, 2013 9:19 PM > To: Parthasarathi R > Cc: DRAGE, Keith (Keith); DISPATCH > Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or > websocket > > Partha, > > It's not entirely clear to me that RTCWEB is the "compelling" use case > for MSRP over websockets. I'd be interested to hear who might think > that is the case. I can envision other Real Time applications using > web servers to make use of this, as well. > > I don't see any requirements in the RTCWEB WG (charter or > requirements) that indicate this is a compelling use case: > http://www.ietf.org/id/draft-ietf-rtcweb-use-cases-and-requirements- > 10.txt > There are no use cases for IM, Chat or MSRP specifically that I could > find and I couldn't find anything in the RTCWEB archives: > http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and- > requirements-10 > If there has been discussion, please provide a pointer. > > The discussion of MSRP over websockets should continue on this mailing > list. Per the dispatching of IETF-86 topics, the current proposal is > to AD sponsor this document unless there are very compelling reasons > not to publish. > http://tools.ietf.org/wg/dispatch/trac/wiki > > The proposal had been for the general discussion of "foo" over > websockets to happen on the RAI list. The last I looked there are > at least 200 people subscribed to DISPATCH that are not on the RAI > area mailing list. I strongly encourage folks with an interest in the > topic to make sure they are subscribe to the RAI area mailing list: > https://www.ietf.org/mailman/listinfo/rai > > Regards, > Mary. > > On Sun, Mar 31, 2013 at 11:52 AM, Parthasarathi R > wrote: > > The compelling reason for this draft is RTCWeb. In case of non- > RTCWeb, > > TCP Shall be used which avoids the overhead introduced due to > > WebSocket. Please clarify in case WebSocket has some specific > > advantage over TCP in non-RTCWeb environment. > > > > In case dispatch or BFCPbis are not the right WG to make > recommendation, > > then let us discuss in RTCWeb WG itself. Also, Please suggest if any > > other mailing list like (rai@ietf.org) is the right place to discuss. > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On > >> Behalf Of Mary Barnes > >> Sent: Thursday, March 28, 2013 8:28 PM > >> To: DRAGE, Keith (Keith) > >> Cc: dispatch@ietf.org > >> Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or > >> websocket > >> > >> I don't think it's the job of dispatch or BFCPbis WG to define or > even > >> make recommendations for RTCWEB. That choice is up to the RTCWEB WG > >> and it shouldn't be influencing this work. There are applications > >> other than RTCWEB that can and will make use of BFCPbis over > >> websockets. I really don't understand why we are getting so hung up > >> on this - it's the BFCP messages themselves that are important - how > >> one chooses to transport is up to the application. > >> > >> Mary. > >> > >> On Thu, Mar 28, 2013 at 7:35 AM, DRAGE, Keith (Keith) > >> wrote: > >> > From what I have seen of the discussion so far, there appears to > be a > >> body of support that there is a use case for both BFCP and MSRP over > >> websocket, for use in a non-rtcweb environment. > >> > > >> > If when we get to the rtcweb environment we allow this, and also > >> allow a usage over datachannel version, we essentially have two > >> solutions in the market place. > >> > > >> > If that occurs, what guidance will we give to a rtcweb developer > as > >> to which to implement? > >> > > >> > Or do we envisage that only one will be allowed (and if so which) > in > >> an rtcweb environment? > >> > > >> > > >> > > >> > Regards > >> > > >> > Keith > >> > _______________________________________________ > >> > dispatch mailing list > >> > dispatch@ietf.org > >> > https://www.ietf.org/mailman/listinfo/dispatch > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > From ibc@aliax.net Tue Apr 2 04:50:52 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D24F21F97FC for ; Tue, 2 Apr 2013 04:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQTWrNI2y41J for ; Tue, 2 Apr 2013 04:50:52 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id D19D921F97E0 for ; Tue, 2 Apr 2013 04:50:51 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id b4so134338qen.18 for ; Tue, 02 Apr 2013 04:50:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=+AfVCFKNhVraoTDvXStR3yVqThNl5CTNLCOJJ3URXl4=; b=jClaDpcte6ZpbOm8mVV5RnPdTvsRqpkAPpUDDUiJAYQsq8fyqFr0BsrvC1VsiTQvNw tTTNEFkQ/HuUqwVOdhCXVCuNYZFtkkCNLG8b6eLw88bC3M0A+Ck2Fcwvrs2LzSBB/gyc 9Qd0DyY5XVA+VS3MK9Cw/ah/0ati5zN4EbYsUCOnxlE9CoEgV0XlUre2dD5K19yWhjyU YXZDXKfj4AYaNk4FnYBEeRRQZwLJ+mX++PUqHUiVv+kb6zGnCen5nz2tGmOS2W2nYaFP H/Xrr7aualHECgik8Mj4K1EY2B/URAvtD4Ll6nlRgrZqOAFg1qcD8KfX5jsyYpxjyrjG UqCQ== X-Received: by 10.224.173.65 with SMTP id o1mr15566363qaz.83.1364903451191; Tue, 02 Apr 2013 04:50:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.64.138 with HTTP; Tue, 2 Apr 2013 04:50:31 -0700 (PDT) In-Reply-To: <004301ce2e30$2317e700$6947b500$@co.in> References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <004301ce2e30$2317e700$6947b500$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 2 Apr 2013 13:50:31 +0200 Message-ID: To: Parthasarathi R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnBKFNrSE2j9FlgHlmORZcrVvU0d+AhRFPaEBFhXES+SlxLqLc8V5PW9zi1gBLmwiVnJ3Os Cc: dispatch@ietf.org Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 11:50:52 -0000 2013/3/31 Parthasarathi R : > The compelling reason for this draft is RTCWeb. Why? where did you get such a conclusion from? > In case of non-RTCWeb, > TCP Shall be used which avoids the overhead introduced due to > WebSocket. Please clarify in case WebSocket has some specific > advantage over TCP in non-RTCWeb environment. > > In case dispatch or BFCPbis are not the right WG to make recommendation, > then let us discuss in RTCWeb WG itself. The RTCWeb WG has nothing to do with *what* is sent over a DataChannel communication. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Apr 2 05:02:22 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6319821F97CD for ; Tue, 2 Apr 2013 05:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzJ4GIG94Z4p for ; Tue, 2 Apr 2013 05:02:22 -0700 (PDT) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id CA1EC21F9777 for ; Tue, 2 Apr 2013 05:02:21 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id nd7so142191qeb.10 for ; Tue, 02 Apr 2013 05:02:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=QkIYH+Efo2doBXR5803CPu2gwsoZXcJdW1mfdTbnevg=; b=CYtTxdjqwkNnJ30USVn7VUWGnOKw8exemwGYUkX5jmeQZSopEHhYf3nvyMzi72c7r3 WYZ7Kvu+sG+9BqWs6SlrGFD59cwndZhgIiF5i/J1z7dr51mKG2ZD5sPHprp4yKuoXCuq I7e530MSXV6FvznluavWCWex6eiSrBpArA8Y2A/599ewgtaQaSG2WKYMQtYmxGRXhpT3 xlSnFV3EXRwnyKirzsPq4/3r1FS3oRFutL+Ki2xMnGQSG+T7dCtmwzm6UKbEyzB79ucL 7hDci2sPgkj1R+c7RDnT9HIhBKfZb8gf1UWwUgxusTImSiiK6JjU4yiuZaC+tFiEwYHV 8fsQ== X-Received: by 10.229.57.9 with SMTP id a9mr5937514qch.113.1364904141275; Tue, 02 Apr 2013 05:02:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.64.138 with HTTP; Tue, 2 Apr 2013 05:02:01 -0700 (PDT) In-Reply-To: <001201ce2efc$0695a5f0$13c0f1d0$@co.in> References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <004301ce2e30$2317e700$6947b500$@co.in> <001201ce2efc$0695a5f0$13c0f1d0$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 2 Apr 2013 14:02:01 +0200 Message-ID: To: Parthasarathi R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmcoR3CLin7YI1aQhLzfqfZamG+7rSojiuU2mEdYwX5R6iS1HdNPc2X62gPSql6djfbka7D Cc: DISPATCH Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 12:02:22 -0000 2013/4/1 Parthasarathi R : > > I think that my point on RTCWEB does not come out well. > Browser has the limitation of including TCP applications (like > BFCP over TCP) directly. To achieve this Datachannel or WebSocket > Shall be used which is under discussion here. As you mentioned, > RTCWeb WG does not cover these usecases. The discussion > required in RTCWeb WG whether BFCP and MSRP usecase are qualified > as usecase or as the additional usecase (sec 8 of > draft-ietf-rtcweb-use-cases-and-requirements-10) as other > conference related usecases exist in additional usecase already. You can send BFCP messages over WebSocket and you can also send them over a WebRTC DataChannel "connection". So this is not a "WebRTC use case" that should be defined in draft-ietf-rtcweb-use-cases-and-requirements because anyone can send *whatever* he wants over a DataChannel connection or over a WebSocket connection. Please don't disturb the RTCWEB WG with BFCP stuff. > In your envisioned Real time applications using > web servers, web client shall use TCP for BFCP & MSRP as web client > MUST support TCP protocol. "web client MUST support TCP protocol" ?? Sorry but, is that a joke? It's obvious that a web browser cannot open a raw TCP connection, that's why we need WebSocket as the *standard* realtime and bidirectional communication mechanism for applications running in web browsers. > It is not clear to me why websocket is > required for those real time applications. Realtime bidirectional communication from browser to server and vice versa. What other *standard* mechanism you know for realtime bidirectional communication in web applications? Please let me know (reply please). Regards. --=20 I=C3=B1aki Baz Castillo From stpeter@stpeter.im Tue Apr 2 21:02:28 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C731521E8054 for ; Tue, 2 Apr 2013 21:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRxvDXRB+NCM for ; Tue, 2 Apr 2013 21:02:28 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F0CD721E804E for ; Tue, 2 Apr 2013 21:02:22 -0700 (PDT) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C966E406A8 for ; Tue, 2 Apr 2013 22:12:05 -0600 (MDT) Message-ID: <515BA9C5.90303@stpeter.im> Date: Tue, 02 Apr 2013 22:02:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: DISPATCH References: <20130403040020.6409.43694.idtracker@ietfa.amsl.com> In-Reply-To: <20130403040020.6409.43694.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130403040020.6409.43694.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-core-04.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 04:02:28 -0000 FYI. -------- Original Message -------- Subject: I-D Action: draft-saintandre-sip-xmpp-core-04.txt Date: Tue, 02 Apr 2013 21:00:20 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Addresses and Error Conditions Author(s) : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-saintandre-sip-xmpp-core-04.txt Pages : 14 Date : 2013-04-02 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-saintandre-sip-xmpp-core There's also a htmlized version available at: http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-saintandre-sip-xmpp-core-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From stpeter@stpeter.im Tue Apr 2 21:03:43 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF97221F8624 for ; Tue, 2 Apr 2013 21:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deWmHjMcwabZ for ; Tue, 2 Apr 2013 21:03:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5083221F85C4 for ; Tue, 2 Apr 2013 21:03:43 -0700 (PDT) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3C01A406A8 for ; Tue, 2 Apr 2013 22:13:26 -0600 (MDT) Message-ID: <515BAA15.9050704@stpeter.im> Date: Tue, 02 Apr 2013 22:03:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: DISPATCH References: <20130403040257.13025.99948.idtracker@ietfa.amsl.com> In-Reply-To: <20130403040257.13025.99948.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130403040257.13025.99948.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-presence-05.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 04:03:44 -0000 FYI. -------- Original Message -------- Subject: I-D Action: draft-saintandre-sip-xmpp-presence-05.txt Date: Tue, 02 Apr 2013 21:02:57 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence Author(s) : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-saintandre-sip-xmpp-presence-05.txt Pages : 20 Date : 2013-04-02 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-saintandre-sip-xmpp-presence There's also a htmlized version available at: http://tools.ietf.org/html/draft-saintandre-sip-xmpp-presence-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-saintandre-sip-xmpp-presence-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From stpeter@stpeter.im Tue Apr 2 21:07:21 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C26F21E804E for ; Tue, 2 Apr 2013 21:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8b-sR1sOKcX for ; Tue, 2 Apr 2013 21:07:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2205221E805A for ; Tue, 2 Apr 2013 21:07:20 -0700 (PDT) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A1DE5406A8; Tue, 2 Apr 2013 22:17:02 -0600 (MDT) Message-ID: <515BAAEE.2070305@stpeter.im> Date: Tue, 02 Apr 2013 22:07:10 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Michael Lundberg References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on draft-saintandre-sip-xmpp-presence-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 04:07:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael, I think your feedback has been addressed in -05. Please check. On 3/9/13 5:29 PM, Michael Lundberg wrote: > Peter, > > Thanks for resubmitting the SIP-XMPP presence I-D. I think this > and the other documents are important as there are a lot of > interworking issues today with XMPP and SIP/SIMPLE implementations, > and I think these documents can help reduce some of those > interworking challenges. > > In order to help ensure interworking between different > implementations, I think Sections 5.2 and 5.3 need to have some > stronger ‘MUST’ language instead of SHOULDs, MAYs, etc. This will > enforce proper and complete mappings between implementations that > conform to this document. > > While I don’t think the document needs to enforce the use of the > element mapping discussed in 5.2, I think if > implementations are going to use the mapping, this document should > enforce the use of a specific namespace and describe the mapping of > values specified in RFC 6121 (i.e., away, dnd, chat, and > xa). This will at least allow a minimum set of standard mappings > between XMPP and SIP, which can be expanded on in future > document(s). Section 5.3 could then also discuss how this mapping > can be accomplished from SIP to XMPP if the SIP endpoints/devices > support this same namespace. One of the big interworking > challenges with today’s implementations is the use of different > namespaces given the extensibility of XML-based presence standards > (e.g., PIDF, RPID), which allows individuals to create their own > namespace. This flexibility is good for ingenuity, but problematic > for interworking between different implementations. I think > standardizing a basic set of common status information using a > specific namespace is needed, and this document is a good place to > do that. > > In my opinion, I do not think Section 6 should be part of this > base document. While I like the idea of encapsulating the SIP > information into the XMPP message, I think this content > should be a consideration for implementing ‘rich presence’. As > written, this method is only applicable for SIP to XMPP > translation, and if the focus of this document is just ‘basic’ > presence information interworking, the SIP to XMPP mapping in > Section 5.3 already describes a method for how this can be > accomplished. > > Regards, Michael _______________________________________________ > dispatch mailing list dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRW6rtAAoJEOoGpJErxa2pF0sP/0IHN6cPgtVnXRKhYh8SrHi6 8MuBgX/ChhuIGS/OtNuO8b334KnBs65DjMakgVSTYqu+QD6ng/MIgLMtoumSbYv0 EJWgyxKY8uuO5HMUshZ7p70ApK6+DD0PqeVKR7bKtFXPFGaVJ/6+NAzSAVSUAJze 4qVSbEkD8/ZQAzo+Y7IRuDXE8j70ZFhTAZUrK22GH00aw++CiXe6VqPBr0eDpsT+ 6xJt9uTwoEBmJ4r97772VI1lX+wrZkQvuhysHyAyq+XsUGpMliFCT+sra5KqAjo1 FDr0zSgz+zf3zqFolORaSaMxYe3Zfc8uzg7XBti3dhnZY0J1HtRZ+ZcBh49YxJc+ ahMrw2K/MiVq+ZgDAwqp6qL64n1TgaXXToDprnYlxFWItlTH/E7oLAcZdBjc6ebn gRWsA/NuE/u12pggoKb42ifW3Zn5J6rGfx4YYSMPmHbzAqmzbOxntL2jKpfd092i BvoVMG/tS7zRiJTfrx+7fAwkUVBgB6SG1w61xPqupmVBc3KWtQyDsYkizLeRDzNx 5jghVEuuDkb/g27flFX4f5KsjXbpeOqoChEbaI0S9Mfk5QZvMgybFoq0Zbb1bhCu Tzia87u+/MiUPQQjaIde75TI33OMX2RsitAWA5+JoBoDKgTFzfd7BcrQrdY7uExo Cf07OkOWExZN9vonPOWk =Qs0U -----END PGP SIGNATURE----- From partha@parthasarathi.co.in Wed Apr 3 09:29:20 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C10521F8F2C for ; Wed, 3 Apr 2013 09:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpmbdwliIouH for ; Wed, 3 Apr 2013 09:29:19 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.153]) by ietfa.amsl.com (Postfix) with ESMTP id 8C64221F8F2A for ; Wed, 3 Apr 2013 09:29:19 -0700 (PDT) Received: from userPC (unknown [122.172.181.158]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 56EF786854A; Wed, 3 Apr 2013 16:29:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1365006559; bh=WZPBb3yP6XfbLBHPh+HACa6eglnEW9gydLYrS3okpbs=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=WpfLaz+6GICcr5IilvvKRV4Zi25qUvhM/elK7cHyGKpH4O14GarFamgXFxODEcNwd WP3ILEIhOiTUcIbRKB570Lv8sajs1QoHmnHrYT8aqWNtwZOU+raiIFZa+sthODQbwd P3w2SeRiCZ786uaeJsRQjuc91ONZvG26F9hxJIXE= From: "Parthasarathi R" To: =?UTF-8?Q?'I=C3=B1aki_Baz_Castillo'?= References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <004301ce2e30$2317e700$6947b500$@co.in> <001201ce2efc$0695a5f0$13c0f1d0$@co.in> In-Reply-To: Date: Wed, 3 Apr 2013 21:59:08 +0530 Message-ID: <003601ce3088$618e3c00$24aab400$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4vmySNO+3HVLPpSkWqT17cnBbUywA7BOCg Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0204.515C58DE.01D4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.155 Cc: 'DISPATCH' Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 16:29:20 -0000 Inaki, As Mary suggested, Let us discuss data channel vs WebSocket in RAI list. Please look into snip from your earlier mail which answer your=20 own query of Why BFCP over Websocket has to be discussed in RTCWeb=20 WG. anyone can send > *whatever* he wants over a DataChannel connection or over a WebSocket > connection. >=20 > Please don't disturb the RTCWEB WG with BFCP stuff. > It's obvious that a web browser cannot open > a raw TCP connection, that's why we need WebSocket as the *standard* > realtime and bidirectional communication mechanism for applications > running in web browsers. Thanks Partha > -----Original Message----- > From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net] > Sent: Tuesday, April 02, 2013 5:32 PM > To: Parthasarathi R > Cc: Mary Barnes; DISPATCH > Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or > websocket >=20 > 2013/4/1 Parthasarathi R : > > > > I think that my point on RTCWEB does not come out well. > > Browser has the limitation of including TCP applications (like > > BFCP over TCP) directly. To achieve this Datachannel or WebSocket > > Shall be used which is under discussion here. As you mentioned, > > RTCWeb WG does not cover these usecases. The discussion > > required in RTCWeb WG whether BFCP and MSRP usecase are qualified > > as usecase or as the additional usecase (sec 8 of > > draft-ietf-rtcweb-use-cases-and-requirements-10) as other > > conference related usecases exist in additional usecase already. >=20 > You can send BFCP messages over WebSocket and you can also send them > over a WebRTC DataChannel "connection". So this is not a "WebRTC use > case" that should be defined in > draft-ietf-rtcweb-use-cases-and-requirements because anyone can send > *whatever* he wants over a DataChannel connection or over a WebSocket > connection. >=20 > Please don't disturb the RTCWEB WG with BFCP stuff. >=20 >=20 > > In your envisioned Real time applications using > > web servers, web client shall use TCP for BFCP & MSRP as web client > > MUST support TCP protocol. >=20 > "web client MUST support TCP protocol" ?? >=20 > Sorry but, is that a joke? It's obvious that a web browser cannot open > a raw TCP connection, that's why we need WebSocket as the *standard* > realtime and bidirectional communication mechanism for applications > running in web browsers. >=20 >=20 > > It is not clear to me why websocket is > > required for those real time applications. >=20 > Realtime bidirectional communication from browser to server and vice > versa. What other *standard* mechanism you know for realtime > bidirectional communication in web applications? Please let me know > (reply please). >=20 > Regards. >=20 >=20 >=20 >=20 > -- > I=C3=B1aki Baz Castillo > From ibc@aliax.net Wed Apr 3 10:27:53 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A088021F8C6F for ; Wed, 3 Apr 2013 10:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3B9Ilmm7J8D for ; Wed, 3 Apr 2013 10:27:52 -0700 (PDT) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id CD10621F8C04 for ; Wed, 3 Apr 2013 10:27:51 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id a11so990691qen.5 for ; Wed, 03 Apr 2013 10:27:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Q1u4sZ212ljbTOtKayuuO4LUwf6CcHJBdo4aT2vL0uU=; b=HTH9tnWw+RnZ6CiljdhqJzGO1/WVq8eH0+YhGyTqDwnozJ0Wm/wDeJDzrx3vKRwNal 7h2rNsU0JQuC/ARCMkPK/+Fn7dMd4ZzDzT2IQ9D/52bClaM5dGi90ApSl4oyUHfLcq1o TKHZSjP4sJgFcOzKCzQt6p+EMHfeyftd3wWoWCM9QeI9XOwMaIDI+jxz40D9P8nFNcEN LS+Q83kcl2fUYq/jp5MxYR1Fr5JZKPyUEXfXdXTOOMbrmDMcOuqLNCAVBUsas6St24hH FYu44gbJNJ3dotyWre1hVo4fQbg4bn7BtBxK6XixEjyVZqUg6u+dbBnSmeNsIylJXMuj qVAQ== X-Received: by 10.229.180.2 with SMTP id bs2mr828570qcb.52.1365010071259; Wed, 03 Apr 2013 10:27:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.64.138 with HTTP; Wed, 3 Apr 2013 10:27:31 -0700 (PDT) In-Reply-To: <003601ce3088$618e3c00$24aab400$@co.in> References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <004301ce2e30$2317e700$6947b500$@co.in> <001201ce2efc$0695a5f0$13c0f1d0$@co.in> <003601ce3088$618e3c00$24aab400$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 3 Apr 2013 19:27:31 +0200 Message-ID: To: Parthasarathi R Content-Type: multipart/alternative; boundary=001a11c27e3269a3bb04d9782c0c X-Gm-Message-State: ALoCoQlDzMQiEFfDTKCDaouNChCA/Xuu3EZbu2b39bOEXaMDTK2tlMuSdR+zR8dSHUNeQmQ5rqqc Cc: DISPATCH Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:27:53 -0000 --001a11c27e3269a3bb04d9782c0c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Partha. As I expected you don't reply to my question (you never do it). Please let me try it again: > It is not clear to me why websocket is > required for those real time applications. Realtime bidirectional communication from browser to server and vice versa. What other *standard* mechanism you know for realtime bidirectional communication in web applications? Please let me know (reply please). Regards. 2013/4/3 Parthasarathi R > Inaki, > > As Mary suggested, Let us discuss data channel vs WebSocket in > RAI list. > > Please look into snip from your earlier mail which answer your > own query of Why BFCP over Websocket has to be discussed in RTCWeb > WG. > > > anyone can send > > *whatever* he wants over a DataChannel connection or over a WebSocket > > connection. > > > > Please don't disturb the RTCWEB WG with BFCP stuff. > > > > > It's obvious that a web browser cannot open > > a raw TCP connection, that's why we need WebSocket as the *standard* > > realtime and bidirectional communication mechanism for applications > > running in web browsers. > > > Thanks > Partha > > > -----Original Message----- > > From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net] > > Sent: Tuesday, April 02, 2013 5:32 PM > > To: Parthasarathi R > > Cc: Mary Barnes; DISPATCH > > Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or > > websocket > > > > 2013/4/1 Parthasarathi R : > > > > > > I think that my point on RTCWEB does not come out well. > > > Browser has the limitation of including TCP applications (like > > > BFCP over TCP) directly. To achieve this Datachannel or WebSocket > > > Shall be used which is under discussion here. As you mentioned, > > > RTCWeb WG does not cover these usecases. The discussion > > > required in RTCWeb WG whether BFCP and MSRP usecase are qualified > > > as usecase or as the additional usecase (sec 8 of > > > draft-ietf-rtcweb-use-cases-and-requirements-10) as other > > > conference related usecases exist in additional usecase already. > > > > You can send BFCP messages over WebSocket and you can also send them > > over a WebRTC DataChannel "connection". So this is not a "WebRTC use > > case" that should be defined in > > draft-ietf-rtcweb-use-cases-and-requirements because anyone can send > > *whatever* he wants over a DataChannel connection or over a WebSocket > > connection. > > > > Please don't disturb the RTCWEB WG with BFCP stuff. > > > > > > > In your envisioned Real time applications using > > > web servers, web client shall use TCP for BFCP & MSRP as web client > > > MUST support TCP protocol. > > > > "web client MUST support TCP protocol" ?? > > > > Sorry but, is that a joke? It's obvious that a web browser cannot open > > a raw TCP connection, that's why we need WebSocket as the *standard* > > realtime and bidirectional communication mechanism for applications > > running in web browsers. > > > > > > > It is not clear to me why websocket is > > > required for those real time applications. > > > > Realtime bidirectional communication from browser to server and vice > > versa. What other *standard* mechanism you know for realtime > > bidirectional communication in web applications? Please let me know > > (reply please). > > > > Regards. > > > > > > > > > > -- > > I=C3=B1aki Baz Castillo > > > > --=20 I=C3=B1aki Baz Castillo --001a11c27e3269a3bb04d9782c0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Partha. As I expected you don't reply to my que= stion (you never do it). Please let me try it again:

> It is not clear to me why websocket is
> required for those real= time applications.

Realtime bidirectional communication from browser to serv= er and vice
versa. What oth= er *standard* mechanism you know for realtime
bidirectional communication in web applications? Please= let me know
(reply please).=


Regards.



2013/4/3 Parthasarathi R <partha@parthasarathi.co.in>= ;
Inaki,

As Mary suggested, Let us discuss data channel vs WebSocket in
RAI list.

Please look into snip from your earlier mail which answer your
own query of Why BFCP over Websocket has to be discussed in RTCWeb
WG.

<snip1>
anyone can send
> *whatever* he wants over a DataChannel connection or over a WebSocket<= br> > connection.
>
> Please don't disturb the RTCWEB WG with BFCP stuff.
>
</snip1>

<snip2> =C2=A0It's obvious that a web browser cannot open
> a raw TCP connection, that's why we need WebSock= et as the *standard*
> realtime and bidirectional communication mechanism for applications
> running in web browsers. </snip2>


Thanks
Partha

> -----Original Message-----
> From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net]
> Sent: Tuesday, April 02, 2013 5:32 PM
> To: Parthasarathi R
> Cc: Mary Barnes; DISPATCH
> Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or
> websocket
>
> 2013/4/1 Parthasarathi R= <partha@parthasarathi.co.= in>:
> >
> > I think that my point on RTCWEB does not come out well.
> > Browser has the limitation of including TCP applications (like > > BFCP over TCP) directly. To achieve this Datachannel or WebSocket=
> > Shall be used which is under discussion here. As you mentioned, > > RTCWeb WG does not cover these usecases. The discussion
> > required in RTCWeb WG whether BFCP and MSRP usecase are qualified=
> > as usecase or as the additional usecase (sec 8 of
> > draft-ietf-rtcweb-use-cases-and-requirements-10) as other
> > conference related usecases exist in additional usecase already.<= br> >
> You can send BFCP messages over WebSocket and you can also send them > over a WebRTC DataChannel "connection". So this is not a &qu= ot;WebRTC use
> case" that should be defined in
> draft-ietf-rtcweb-use-cases-and-requirements because anyone can send > *whatever* he wants over a DataChannel connection or over a WebSocket<= br> > connection.
>
> Please don't disturb the RTCWEB WG with BFCP stuff.
>
>
> > In your envisioned Real time applications using
> > web servers, web client shall use TCP for BFCP & MSRP as web = client
> > MUST support TCP protocol.
>
> "web client MUST support TCP protocol" ??
>
> Sorry but, is that a joke? It's obvious that a web browser cannot = open
> a raw TCP connection, that's why we need WebSocket as the *standar= d*
> realtime and bidirectional communication mechanism for applications > running in web browsers.
>
>
> > It is not clear to me why websocket is
> > required for those real time applications.
>
> Realtime bidirectional communication from browser to server and vice > versa. What other *standard* mechanism you know for realtime
> bidirectional communication in web applications? Please let me know > (reply please).
>
> Regards.
>
>
>
>
> --
> I=C3=B1aki Baz Castillo
> <ibc@aliax.net>




--
= I=C3=B1aki Baz Castillo
<ibc@aliax.n= et>
--001a11c27e3269a3bb04d9782c0c-- From ibc@aliax.net Wed Apr 3 10:30:29 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52D021F8A55 for ; Wed, 3 Apr 2013 10:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae77J-pmvkZ8 for ; Wed, 3 Apr 2013 10:30:29 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4109121F8A18 for ; Wed, 3 Apr 2013 10:30:29 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id z24so67017qcq.33 for ; Wed, 03 Apr 2013 10:30:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=3iDWN7+WIn6fMAC51gYhQKbjsxWqSHDC8F6aRNz7Nh0=; b=cjkHG91jy7HdxkeEXcgqarvOpSsd0X01JiTJT4uwZhIeGpiJxBODF73gg+k0PDYl3y 4Mq79kOUCEMR6bcecuzMv0IgFqRoZ/A/qckwYK6E2wZZeLKNSpSB59kttbhrO5r+1ML4 K13oUchbBFYZ/OOu20lRJyezyjbbXfp/C9mptrL0Jf+VqhPMnE6rlEwOHct8Kob0YeFB rlQUAw3n3fykdsMpszmvdZFR37ncMBSKLO/NVSRBkNFQabctMbzSYFl2HzCmoGDV1jsz 7HlhaGcN3j8PhCofIoYEtNQ3MvegecyCAVn1STwXvzNWyvaw/H6R5yzNHWsbVRuGKobg Wtkw== X-Received: by 10.49.30.70 with SMTP id q6mr2357490qeh.28.1365010226172; Wed, 03 Apr 2013 10:30:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.64.138 with HTTP; Wed, 3 Apr 2013 10:30:06 -0700 (PDT) In-Reply-To: <003601ce3088$618e3c00$24aab400$@co.in> References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <004301ce2e30$2317e700$6947b500$@co.in> <001201ce2efc$0695a5f0$13c0f1d0$@co.in> <003601ce3088$618e3c00$24aab400$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 3 Apr 2013 19:30:06 +0200 Message-ID: To: Parthasarathi R Content-Type: multipart/alternative; boundary=047d7bdc9612a5bf4104d9783573 X-Gm-Message-State: ALoCoQku32UDLggu7a4LGXPvc/PmQIDlzi1Z5kYJXsXD1gz4FWxLoqJ7P9TImJlr5ym+VHmtjRcC Cc: DISPATCH Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:30:30 -0000 --047d7bdc9612a5bf4104d9783573 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2013/4/3 Parthasarathi R > Please look into snip from your earlier mail which answer your > own query of Why BFCP over Websocket has to be discussed in RTCWeb > WG. > Regardless to this, as you know "SIP over WebSocket" ( http://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket/) is in Last Call status, and we required nothing from RTCWEB WG for that, so the same for "BFCP over WebSocket" or "Anything related to SIP over WebSocket". Best regards. --=20 I=C3=B1aki Baz Castillo --047d7bdc9612a5bf4104d9783573 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2013/4/3 Parthasarathi R <partha@parthasarathi.co.in>
Please look into snip from your earlier mail which answer = your
own query of Why BFCP over Websocket has to be discussed in RTCWeb
WG.

Regardless to this, as you know "SIP o= ver WebSocket" (http://datatracker.ietf.org/doc/draft-ietf-sipcore-= sip-websocket/) is in Last Call status, and we required nothing from RT= CWEB WG for that, so the same for "BFCP over WebSocket" or "= Anything related to SIP over WebSocket".

Best regards.

-- I=C3=B1aki Baz Castillo
<ibc@aliax.= net>
--047d7bdc9612a5bf4104d9783573-- From pkyzivat@alum.mit.edu Wed Apr 3 14:01:35 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2334621F8ED5 for ; Wed, 3 Apr 2013 14:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu9QmDVHfJ9t for ; Wed, 3 Apr 2013 14:01:34 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 5B59121F8ED4 for ; Wed, 3 Apr 2013 14:01:34 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta01.westchester.pa.mail.comcast.net with comcast id KQec1l0021GhbT851Z1Z2z; Wed, 03 Apr 2013 21:01:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id KZ1Y1l0113ZTu2S3TZ1ZBY; Wed, 03 Apr 2013 21:01:33 +0000 Message-ID: <515C98AC.7020600@alum.mit.edu> Date: Thu, 04 Apr 2013 05:01:32 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <004301ce2e30$2317e700$6947b500$@co.in> <001201ce2efc$0695a5f0$13c0f1d0$@co.in> <003601ce3088$618e3c00$24aab400$@co.in> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365022893; bh=Zh1esaO3CdYFdWaNifeFLjqr5YRTuoHd2CLMNfVX1Yo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DdXNOayhnyTgEn7iEZme7Snbc3qR52s6RxxpucPZ0sZgBcCJZlueKhAZM2aDFRyOl jhwACSKmtX0dgOVTU+RDZbg1kQXfzjatLLDWuNcN+COPIphzsehYkFnM5+79xFSPkE ppQnzBNintI1hNjfU9mttg7t50y9ZdygEv54kBXzw6KobckWwyZmEmeQ2zCVn4RaXE g+QHuog/AlmyZMFOQ2zj/Ckf1vX4aBndeqRxaoONh03zx8J5L/r/Ik9kS+ZYji0w9b q6Z3a9JR38UGqjri4AcRF+Xnfa74BGRFEv2YQmthb8lPJHNX4BhhX+rWUrJ+aiKCgr SkR9eF5XN57kQ== Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 21:01:35 -0000 On 4/4/13 1:27 AM, Iñaki Baz Castillo wrote: > Thanks Partha. As I expected you don't reply to my question (you never > do it). Please let me try it again: > > > > It is not clear to me why websocket is > > required for those real time applications. > > Realtime bidirectional communication from browser to server and vice > versa. What other *standard* mechanism you know for realtime > bidirectional communication in web applications? Please let me know > (reply please). I see a significant difference between "media" streams such as msrp and bfcp, and the sip over websocket spec. For sip over websocket there is little expectation that the target of the websocket is the ultimate destination. It is more likely to be an outbound proxy. So interop with peers that aren't web servers is preserved. That may be true for msrp too, since a caller-specific msrp relay can be used to ensure interop. It is more of a problem for bfcp, since AFAIK there is no spec for a bfcp relay. In general you can't know in advance if the peer in your sip call is a web server, so you can't depend on being able to set up a websocket to that peer. I am not decided on what is the right answer for bfcp. But I have succeeded in getting the issue discussed more widely. Thanks, Paul > Regards. > > > > 2013/4/3 Parthasarathi R > > > Inaki, > > As Mary suggested, Let us discuss data channel vs WebSocket in > RAI list. > > Please look into snip from your earlier mail which answer your > own query of Why BFCP over Websocket has to be discussed in RTCWeb > WG. > > > anyone can send > > *whatever* he wants over a DataChannel connection or over a WebSocket > > connection. > > > > Please don't disturb the RTCWEB WG with BFCP stuff. > > > > > It's obvious that a web browser cannot open > > a raw TCP connection, that's why we need WebSocket as the *standard* > > realtime and bidirectional communication mechanism for applications > > running in web browsers. > > > Thanks > Partha > > > -----Original Message----- > > From: Iñaki Baz Castillo [mailto:ibc@aliax.net > ] > > Sent: Tuesday, April 02, 2013 5:32 PM > > To: Parthasarathi R > > Cc: Mary Barnes; DISPATCH > > Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or > > websocket > > > > 2013/4/1 Parthasarathi R >: > > > > > > I think that my point on RTCWEB does not come out well. > > > Browser has the limitation of including TCP applications (like > > > BFCP over TCP) directly. To achieve this Datachannel or WebSocket > > > Shall be used which is under discussion here. As you mentioned, > > > RTCWeb WG does not cover these usecases. The discussion > > > required in RTCWeb WG whether BFCP and MSRP usecase are qualified > > > as usecase or as the additional usecase (sec 8 of > > > draft-ietf-rtcweb-use-cases-and-requirements-10) as other > > > conference related usecases exist in additional usecase already. > > > > You can send BFCP messages over WebSocket and you can also send them > > over a WebRTC DataChannel "connection". So this is not a "WebRTC use > > case" that should be defined in > > draft-ietf-rtcweb-use-cases-and-requirements because anyone can send > > *whatever* he wants over a DataChannel connection or over a WebSocket > > connection. > > > > Please don't disturb the RTCWEB WG with BFCP stuff. > > > > > > > In your envisioned Real time applications using > > > web servers, web client shall use TCP for BFCP & MSRP as web client > > > MUST support TCP protocol. > > > > "web client MUST support TCP protocol" ?? > > > > Sorry but, is that a joke? It's obvious that a web browser cannot > open > > a raw TCP connection, that's why we need WebSocket as the *standard* > > realtime and bidirectional communication mechanism for applications > > running in web browsers. > > > > > > > It is not clear to me why websocket is > > > required for those real time applications. > > > > Realtime bidirectional communication from browser to server and vice > > versa. What other *standard* mechanism you know for realtime > > bidirectional communication in web applications? Please let me know > > (reply please). > > > > Regards. > > > > > > > > > > -- > > Iñaki Baz Castillo > > > > > > > > -- > Iñaki Baz Castillo > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From ibc@aliax.net Wed Apr 3 14:36:52 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D1121F8D2D for ; Wed, 3 Apr 2013 14:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-5tvHZuL1XB for ; Wed, 3 Apr 2013 14:36:51 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E95521F863B for ; Wed, 3 Apr 2013 14:36:51 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id x7so1154686qeu.3 for ; Wed, 03 Apr 2013 14:36:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=psdHYUg0ApG3AMX8WAWVhKOh9je3H3PJui1OHiMS1z4=; b=J5AzuyjN3qpE4mrTjZy7MdFdG52asl61d0ihOV/ej5UFWvkOi6j/G0SMrzTDizx/dY c7hXFcC9/zHSLidFYSdLtjaLylSaYsGgt9ozfnQ09LRBhQwR3ccKt/55n0tiy1hrE1B3 SRh275yHtN0xWuGaRewjGIee/3Ap1zAeXJ9Bh+lnD5X9yBxaFUVGzVU46BRAV1AJXmCI rPo87MeY2ZsCuh+xbbGmsEnATsHdf0qwtl1If4K3YfPMao1wQagIe7iziF/piWwk28Ac tOqsF19uAlK75MZcrHg8wzSzZQI7X4XAmglnBIvvhb2iNaTqGrj9kejhpb6fJjFwkLdq 6MCQ== X-Received: by 10.49.87.40 with SMTP id u8mr3095904qez.62.1365025011140; Wed, 03 Apr 2013 14:36:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.64.138 with HTTP; Wed, 3 Apr 2013 14:36:31 -0700 (PDT) In-Reply-To: <515C98AC.7020600@alum.mit.edu> References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <004301ce2e30$2317e700$6947b500$@co.in> <001201ce2efc$0695a5f0$13c0f1d0$@co.in> <003601ce3088$618e3c00$24aab400$@co.in> <515C98AC.7020600@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 3 Apr 2013 23:36:31 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlorrR//VCyaOMC/LudIpRpVUHk2q7FdWiAShLmz7luVSJHw7tHPgtFv7wlrbXb6H8naWd1 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 21:36:52 -0000 2013/4/3 Paul Kyzivat > > On 4/4/13 1:27 AM, I=C3=B1aki Baz Castillo wrote: >> >> Realtime bidirectional communication from browser to server and vice >> versa. What other *standard* mechanism you know for realtime >> bidirectional communication in web applications? Please let me know >> (reply please). > > > I see a significant difference between "media" streams such as msrp and b= fcp, and the sip over websocket spec. > > For sip over websocket there is little expectation that the target of the= websocket is the ultimate destination. It is more likely to be an outbound= proxy. So interop with peers that aren't web servers is preserved. > > That may be true for msrp too, since a caller-specific msrp relay can be = used to ensure interop. Agreed. > It is more of a problem for bfcp, since AFAIK there is no spec for a bfcp= relay. In general you can't know in advance if the peer in your sip call i= s a web server, so you can't depend on being able to set up a websocket to = that peer. It could be just a WebSocket server (without Web component) but it changes nothing. I agree with your point and, may be what it would make sense is to (also) define the concept of BFCP relay. > I am not decided on what is the right answer for bfcp. But I have succeed= ed in getting the issue discussed more widely. Using BFCP over DataChannel would not help a lot here since, obviously, a WebRTC browser/client would not be able to establish a BFCP session with a non WebRTC client (i.e. a "common" SIP device). So, again, the concept of a BFCP relay seems needed regardless WebSocket or DataChannel is defined for transporting BFCP data. Anyhow, and trying to be realistic: are there *real* use cases in which BFCP is talked directly between SIP endpoints (instead of "SIP endpoint <--> SIP conference server")? I expect (and may be I'm wrong) that the answer is "no" so, in that case, defining BFCP over WebSocket seems a much more appropriate, easy to implement and realistic approach (implementing a WebSocket interface in a server is much more easier than implementing a WebRTC DataChannel client, which involves SCTP over DTLS over UDP). Regards. -- I=C3=B1aki Baz Castillo From lorenzo@meetecho.com Wed Apr 3 14:58:26 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B86621F8B27 for ; Wed, 3 Apr 2013 14:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8Sk+oWyA7ZJ for ; Wed, 3 Apr 2013 14:58:25 -0700 (PDT) Received: from smtpdg4.aruba.it (smtpdg2.aruba.it [62.149.158.232]) by ietfa.amsl.com (Postfix) with ESMTP id 865C021F8A91 for ; Wed, 3 Apr 2013 14:58:24 -0700 (PDT) Received: from rainpc ([79.55.171.149]) by smtpcmd02.ad.aruba.it with bizsmtp id KZyL1l00a3Dl7DK01ZyMzf; Wed, 03 Apr 2013 23:58:21 +0200 Date: Wed, 3 Apr 2013 23:58:21 +0200 From: Lorenzo Miniero To: =?ISO-8859-1?B?SfFha2k=?= Baz Castillo Message-ID: <20130403235821.12f4e8a4@rainpc> In-Reply-To: References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <004301ce2e30$2317e700$6947b500$@co.in> <001201ce2efc$0695a5f0$13c0f1d0$@co.in> <003601ce3088$618e3c00$24aab400$@co.in> <515C98AC.7020600@alum.mit.edu> Organization: Meetecho X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 21:58:26 -0000 On Wed, 3 Apr 2013 23:36:31 +0200 I=F1aki Baz Castillo wrote: > 2013/4/3 Paul Kyzivat > > > > On 4/4/13 1:27 AM, I=F1aki Baz Castillo wrote: > >> > >> Realtime bidirectional communication from browser to server and vice > >> versa. What other *standard* mechanism you know for realtime > >> bidirectional communication in web applications? Please let me know > >> (reply please). > > > > > > I see a significant difference between "media" streams such as msrp and= bfcp, and the sip over websocket spec. > > > > For sip over websocket there is little expectation that the target of t= he websocket is the ultimate destination. It is more likely to be an outbou= nd proxy. So interop with peers that aren't web servers is preserved. > > > > That may be true for msrp too, since a caller-specific msrp relay can b= e used to ensure interop. >=20 > Agreed. >=20 >=20 > > It is more of a problem for bfcp, since AFAIK there is no spec for a bf= cp relay. In general you can't know in advance if the peer in your sip call= is a web server, so you can't depend on being able to set up a websocket t= o that peer. >=20 > It could be just a WebSocket server (without Web component) but it > changes nothing. I agree with your point and, may be what it would > make sense is to (also) define the concept of BFCP relay. >=20 >=20 > > I am not decided on what is the right answer for bfcp. But I have succe= eded in getting the issue discussed more widely. >=20 > Using BFCP over DataChannel would not help a lot here since, > obviously, a WebRTC browser/client would not be able to establish a > BFCP session with a non WebRTC client (i.e. a "common" SIP device). > So, again, the concept of a BFCP relay seems needed regardless > WebSocket or DataChannel is defined for transporting BFCP data. >=20 > Anyhow, and trying to be realistic: are there *real* use cases in > which BFCP is talked directly between SIP endpoints (instead of "SIP > endpoint <--> SIP conference server")? I expect (and may be I'm wrong) > that the answer is "no" so, in that case, defining BFCP over WebSocket > seems a much more appropriate, easy to implement and realistic > approach (implementing a WebSocket interface in a server is much more > easier than implementing a WebRTC DataChannel client, which involves > SCTP over DTLS over UDP). >=20 >=20 I do agree on your realistic view (more on that below), but I also do share= Paul's confusion in part... to digress a little, I remember there was some= debate at the time when BFCP was being specified, about where a floor cont= rol server was to be deployed in a conferencing environment: some (includin= g me) thought it better colocated with the application server (the one hand= ling the application logic), others with the media server (the one enforcin= g the decisions). This new discussion partly seems to take the same way, es= pecially if we rephrase it in slightly a different way: is BFCP more of a "= signalling" protocol, or a media protocol? The very fact that BFCPBIS is co= mpleting the works on a UDP transport for BFCP makes this question less eas= y to answer to. I still think it's closer to the former as, wherever decisions are taken, t= here's application logic enforcing something at the media level (which is h= ow we implemented it as well, by the way). This makes me more keen to view = a websocket approach being used for BFCP, especially if we assume the floor= control server somewhere on the server side and as such not colocated with= any of the WebRTC-compliant browsers: this is similar to how we currently = implement the web based interface to our conferencing platform, where simpl= e HTTP interactions are used to wrap a BFCP participant that is originated = server side, and it seems to work fine for our needs. Besides, as you say, = no change needed on legacy devices as they'd keep on "talking" BFCP with th= e FCS the old way. That said, though, I may have this view because of how, just as you, I'm cu= rrently associating BFCP with the conferencing world (well, it was born in = XCON after all), which may be a wrong assumption: people may be using BFCP = for entirely different scenarios as well, and the example made by someone a= few posts ago (I think it was Victor but I may be wrong) about one of two = peers acting as the floor control server in a call may be a perfectly valid= scenario for it being used differently than what I'm used to. I also remem= ber Adam Roach proposing a Call Completion service based on BFCP a few year= s ago, which is just another scenario that may change the roles a bit. Such a shift in the roles may very well motivate a use of datachannels for = BFCP as well, especially if we think of scenarios where no centralized cont= rol will be needed, or at least no centralized control outside of the WebRT= C peers that are part of the conversation. Of course, if an application DOE= S need some control on the server side, this means that this server would n= eed to implement the backend of a datachannel; and yes, it would make thing= s definitelt harder when interoperating with legacy devices, but as some se= em to advocate, WebRTC should be a fresh start, and should not look back to= o much. Whether this would be a dealbreaker for some I don't know, but I gu= ess that, as there already are non-browser WebRTC implementations for media= out there, it won't be long before datachannels will be handled as well: m= aybe it won't be optimal, but someone will make it work one way or the othe= r. Lorenzo > Regards. >=20 >=20 > -- > I=F1aki Baz Castillo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --=20 Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From stpeter@stpeter.im Wed Apr 3 18:56:05 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8823F21F8EA5 for ; Wed, 3 Apr 2013 18:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQBaw7N1k8du for ; Wed, 3 Apr 2013 18:56:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2C921F8EAD for ; Wed, 3 Apr 2013 18:56:04 -0700 (PDT) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 19F5640DC2 for ; Wed, 3 Apr 2013 20:05:49 -0600 (MDT) Message-ID: <515CDDB1.2010809@stpeter.im> Date: Wed, 03 Apr 2013 19:56:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dispatch] conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 01:56:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 RFC 4575 (Section 5.6.3) defines the concept of a role in a conference, but does not specify or define any roles. 5.6.3. This element MAY contain a set of human-readable strings describing the roles of the user in the conference. Note that this information is applicable for human consumption only. This specification does not define the set of possible conferencing roles or the semantics associated with each. It is expected that future conferencing specifications will define these and the corresponding schema extensions, as appropriate. RFC 6501 (Section 4.6.5.2) specifies a few values for the role element, but does not actually define what those values mean. 4.6.5.2. A provides the context for the set of conference operations that a participant can perform. This element can contain one or more of the following values: "administrator", "moderator", "user", "participant", "observer", and "none". A role of "none" indicates that any role is assigned. The semantic definition is out of the scope of this document and is subject to future policy documents. This element can be extended with new roles in future documents. (As far as I know, those "future policy documents" have not been published.) More recently, draft-groves-clue-capture-attr specifies several additional roles: "manager", "chairman", "secretary", "lecturer", and "audience" (so-called person roles) as well as "speaker" and "controller" (so-called conference roles). Personally, I happen to have an interest in defining a few other roles, such as "host", "presenter", "scribe", and "panelist". Unfortunately there's quite a bit of overlap and confusion here. For instance, one could argue that "host", "manager", and "controller" (perhaps even "chairman") are the same as or very similar to "administrator" or "moderator" from RFC 6501. There might also be overlap between "lecturer", "speaker", and "presenter" (and between "speaker" and "panelist"). Furthermore, I'm concerned that various implementations will define their own roles, blithely unaware that very similar (or even identical but differently named roles) are already in use by other implementations. It strikes me that one solution here would be to establish an IANA registry for conference roles, with a registration policy (cf. RFC 5226) of at least Expert Review and perhaps Specification Required (I think RFC Required is a bit heavy). IMHO this would help to prevent continued confusion and the minting of new roles that overlap with existing roles. Thoughts? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRXN2wAAoJEOoGpJErxa2p98YP/1AtEgnS9T6w9aYc4V66Z0wv AJJ0r4Xk8mKWyqYsovyyqLoXnqnFitOSBrlt1pskDw/pDhI08LZiPkN3G3sMDSdo qhCen5UcSMRaKwDCaddXiIOzMP2IOEqJFltWWj32BX/qgtYVSMac9Vgsw/HJWzUi hjLM5U84W4mLBLGC5XgT7jqwTYA3pb1tqfN0Fn1Ony/kW9Nmy0+fciQhMTLrkOi6 cwplCwdNsmZeGbp4ABlDMLA2WcilqmU7Iu61lKlNmbnizTXGeTznsst51LZvuEO3 c9z0UUQl+g88F4ZxBphdbtxzK9qRFD4l+FSRRwPxM3vggjVUSp829GCHEgdUeyel v3Mxy0aTmsziKOUJ3lTU2mi3RGu9b7lkei0t1EF8rXAz6upMCJcd+90qD29QbP3s z5V6hz7iJCe172XiElmbX29d2u3yt7SbHNX9Ime4SvHMWX9NrJyuoOiSk+7IF73k qX2QIe3JJDPX4Q0KO9Od64m95hjPgM2EiYj7gFbq9K3cAwZ0x3nExWN4+XB2WWyJ Qo4+vSk1eL04dzcy06m7cDrM9snlm4usOA8YrvabItAKryl9E8d0rqNi8Y6PB2sI IcnT73QbPJIvLzP/Z03Pn4n1uhz0K+QjIySJKW3bcs0Nj5qyjyMAQCIt+DvzP8Fq 5PghQ2Ey40XHE3Mp6V35 =i5bw -----END PGP SIGNATURE----- From victor.pascual.avila@gmail.com Wed Apr 3 22:40:06 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17AB21F941D for ; Wed, 3 Apr 2013 22:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+SryFeYlbjn for ; Wed, 3 Apr 2013 22:40:04 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 80E3621F941F for ; Wed, 3 Apr 2013 22:40:04 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id y8so2315135lbh.21 for ; Wed, 03 Apr 2013 22:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=rVO8IPUqa1MEvTga1j/5vESHdo5os1CJXai1XggpV3Q=; b=Aqg5V5LAWJMEgh6GXIr4PhgTApYeFLOer9NBsc19CNwHl1YBR6+EpcUcpRS6NwNZ/1 wY8KP6OaD0hGkX9lEMDgjPiTGXeGKDn5FNS0lbXpdeX9RUVzPvnLPt6yk365bQtuXCNj KoS5NVZmk9wEGGtvFABV8GANOwFgVeYEHG3QRdcpBunJnZoWlsgvVtBqqjTuVlfz3Loi +p3n4SWEGslHYcvUNKE4mHntv7fyH0sTorSMOQMp/Sy8iXTNfxcyQKHeDca/s13xae2r 50XVYLYjG4Bbjxj+wC1JPi7wcBB5sub3jXA5O5RG5aCkv6W6ibrct1Ms6XkgVCgOZYKF tDhw== MIME-Version: 1.0 X-Received: by 10.112.155.100 with SMTP id vv4mr2547360lbb.81.1365054003429; Wed, 03 Apr 2013 22:40:03 -0700 (PDT) Received: by 10.114.29.101 with HTTP; Wed, 3 Apr 2013 22:40:03 -0700 (PDT) In-Reply-To: <20130403235821.12f4e8a4@rainpc> References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <004301ce2e30$2317e700$6947b500$@co.in> <001201ce2efc$0695a5f0$13c0f1d0$@co.in> <003601ce3088$618e3c00$24aab400$@co.in> <515C98AC.7020600@alum.mit.edu> <20130403235821.12f4e8a4@rainpc> Date: Thu, 4 Apr 2013 07:40:03 +0200 Message-ID: From: Victor Pascual Avila To: Lorenzo Miniero Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 05:40:06 -0000 On Wed, Apr 3, 2013 at 11:58 PM, Lorenzo Miniero wro= te: > That said, though, I may have this view because of how, just as you, I'm = currently associating BFCP with the conferencing world (well, it was born i= n XCON after all), which may be a wrong assumption: people may be using BFC= P for entirely different scenarios as well, and the example made by someone= a few posts ago (I think it was Victor but I may be wrong) about one of tw= o peers acting as the floor control server in a call may be a perfectly val= id scenario for it being used differently than what I'm used to. It was not me -- all my use cases include a conf server. On the client side, we have WebRTC and non-WebRTC web endpoints (all of them supporting WebSockets already) as well as "legacy" BFCP devices. Cheers, -Victor From lorenzo@meetecho.com Wed Apr 3 23:18:34 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EDF21F94CC for ; Wed, 3 Apr 2013 23:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xrrYKcwI8F5 for ; Wed, 3 Apr 2013 23:18:33 -0700 (PDT) Received: from smtpdg6.aruba.it (smtpdg224.aruba.it [62.149.158.224]) by ietfa.amsl.com (Postfix) with ESMTP id E10BE21F9436 for ; Wed, 3 Apr 2013 23:18:32 -0700 (PDT) Received: from rainpc ([79.55.171.149]) by smtpcmd02.ad.aruba.it with bizsmtp id KiJV1l00z3Dl7DK01iJWFK; Thu, 04 Apr 2013 08:18:30 +0200 Date: Thu, 4 Apr 2013 08:18:30 +0200 From: Lorenzo Miniero To: Victor Pascual Avila Message-ID: <20130404081830.6a01c45d@rainpc> In-Reply-To: References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <004301ce2e30$2317e700$6947b500$@co.in> <001201ce2efc$0695a5f0$13c0f1d0$@co.in> <003601ce3088$618e3c00$24aab400$@co.in> <515C98AC.7020600@alum.mit.edu> <20130403235821.12f4e8a4@rainpc> Organization: Meetecho X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 06:18:34 -0000 On Thu, 4 Apr 2013 07:40:03 +0200 Victor Pascual Avila wrote: > On Wed, Apr 3, 2013 at 11:58 PM, Lorenzo Miniero wrote: > > That said, though, I may have this view because of how, just as you, I'm currently associating BFCP with the conferencing world (well, it was born in XCON after all), which may be a wrong assumption: people may be using BFCP for entirely different scenarios as well, and the example made by someone a few posts ago (I think it was Victor but I may be wrong) about one of two peers acting as the floor control server in a call may be a perfectly valid scenario for it being used differently than what I'm used to. > > It was not me -- all my use cases include a conf server. On the client > side, we have WebRTC and non-WebRTC web endpoints (all of them > supporting WebSockets already) as well as "legacy" BFCP devices. > > Cheers, > -Victor Ops you're right, sorry about that! As they say here in Napoli, "that's how you send people to jail" :-) I just checked the archives and it was Charles Eckel that referred to the possibility in a couple of posts. Cheers, Lorenzo -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From gonzalo.camarillo@ericsson.com Thu Apr 4 00:07:23 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16BF21F9601 for ; Thu, 4 Apr 2013 00:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.234 X-Spam-Level: X-Spam-Status: No, score=-106.234 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuvJFmsfgul1 for ; Thu, 4 Apr 2013 00:07:23 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BF1DE21F9616 for ; Thu, 4 Apr 2013 00:07:22 -0700 (PDT) X-AuditID: c1b4fb30-b7f0d6d000007e61-ff-515d26a9235a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 4D.78.32353.9A62D515; Thu, 4 Apr 2013 09:07:21 +0200 (CEST) Received: from [131.160.36.146] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Apr 2013 09:07:21 +0200 Message-ID: <515D26A9.5010505@ericsson.com> Date: Thu, 4 Apr 2013 10:07:21 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: DISPATCH References: <515D25BC.8060502@ericsson.com> In-Reply-To: <515D25BC.8060502@ericsson.com> X-Enigmail-Version: 1.4.6 X-Forwarded-Message-Id: <515D25BC.8060502@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplluLIzCtJLcpLzFFi42KZGfG3VnelWmygwdmNxhZLJy1gdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuQTK5kLtnFUrHn1g62B8Q5bFyMnh4SAicThiQdYIWwxiQv3 1oPFhQROMUp8e8vRxcgFZK9mlGh8fp0JJMEroC2x+NdFIJuDg0VAReLTj3SQMJuAhcSWW/dZ QGxRgSiJvRsuM0OUC0qcnPkELC4ioCCx9xLELmGgvVNWLmWH2KUt0T53BVicU0BHYvXDpywQ 90hKLJrWCWWbS5z8tgLMZhbQk5hytYURwpaX2P52DjPMnOXPWlgmMArNQrJ6FpKWWUhaFjAy r2Jkz03MzEkvN9/ECAzKg1t+G+xg3HRf7BCjNAeLkjhvuOuFACGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2MZgsN16z+/LU/6PDOmxfntJR+WGY4Oe/WhE97LiSX+NSvPfBkyeMWHSe7eTyb 54WY51Ts3bVq5oX+lg2Tclg+rJktueRg4/9P3ueY5j3tKbjjd/rdpeDcluf7robECt+TzV1u 3Rt4Qp19a+Mf3mbe/Z+Yza9M6xQ3/HPHw3fDrXtf+axdE7569yqxFGckGmoxFxUnAgDDObkS GAIAAA== Subject: [dispatch] Fwd: [RAI] Call for volunteers to chair WGs X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 07:07:23 -0000 Hi, this email (see below) is also relevant to DISPATCH. Cheers, Gonzalo -------- Original Message -------- Subject: [RAI] Call for volunteers to chair WGs Date: Thu, 4 Apr 2013 10:03:24 +0300 From: Gonzalo Camarillo To: Folks, as you know, every now and then we need to fill chair positions in both new and existing WGs. If you could be interested in chairing a WG in the RAI area at some point, please send us and email. We understand people are typically interested in a specific WG. It is also typical to get management approval to chair a particular WG. Nevertheless, knowing that you may be interested in a chair position and which areas you are mostly working on would be useful to us. Additionally, every time we agree to charter a new WG (in DISPATCH or in a BOF) you are interested in chairing, you should let us know as well. Thanks, Gonzalo _______________________________________________ RAI mailing list RAI@ietf.org https://www.ietf.org/mailman/listinfo/rai From sergio.garcia.murillo@gmail.com Thu Apr 4 02:04:34 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871AF21F95DB for ; Thu, 4 Apr 2013 02:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90FaprxIDKoq for ; Thu, 4 Apr 2013 02:04:33 -0700 (PDT) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8754A21F946B for ; Thu, 4 Apr 2013 02:04:33 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id e50so958469eek.2 for ; Thu, 04 Apr 2013 02:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Q1BOuRGTJNdAZYvIMNyWnI6YTegbuvoovz+MHsSVBlA=; b=vc7Ki009pCwNaGJ46ppcZYCS2e+YhwvZRpuJiG812OMnDtsDARzkUrRRIF2FmhFd98 V+TFgJ5ingbm3AXd+/czz8RtW7qmpkkK01KuE8dNp15PAEmxFwypGZu54yOWZcgoFjVF 62EhTt1owzt1Rfk30uFlQS24wJ4me8+TFvqa15wUcIfDazdXOQCqaNFAZQQEmybQ5/Y2 3Mm0FmuFQoWIaXOHIF5acZlh6T8zafMDvSZ71riKKl3fX3v0YTzq1qHB3wlQdyEAiNDx xr+H22U6QGddmdDrQUyuW9bGAXmqN1eJoovSm0Xmmw+Ht2m2fCgDurSK47GfuBKpGTdR QwMQ== X-Received: by 10.14.219.129 with SMTP id m1mr9338816eep.16.1365066272644; Thu, 04 Apr 2013 02:04:32 -0700 (PDT) Received: from [192.168.1.45] (252.Red-95-122-166.staticIP.rima-tde.net. [95.122.166.252]) by mx.google.com with ESMTPS id q5sm10367854eeo.17.2013.04.04.02.04.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 02:04:31 -0700 (PDT) Message-ID: <515D4220.3030209@gmail.com> Date: Thu, 04 Apr 2013 11:04:32 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: dispatch@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <004301ce2e30$2317e700$6947b500$@co.in> <001201ce2efc$0695a5f0$13c0f1d0$@co.in> <003601ce3088$618e3c00$24aab400$@co.in> <515C98AC.7020600@alum.mit.edu> <20130403235821.12f4e8a4@rainpc> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 09:04:34 -0000 El 04/04/2013 7:40, Victor Pascual Avila escribió: > On Wed, Apr 3, 2013 at 11:58 PM, Lorenzo Miniero wrote: >> That said, though, I may have this view because of how, just as you, I'm currently associating BFCP with the conferencing world (well, it was born in XCON after all), which may be a wrong assumption: people may be using BFCP for entirely different scenarios as well, and the example made by someone a few posts ago (I think it was Victor but I may be wrong) about one of two peers acting as the floor control server in a call may be a perfectly valid scenario for it being used differently than what I'm used to. > It was not me -- all my use cases include a conf server. On the client > side, we have WebRTC and non-WebRTC web endpoints (all of them > supporting WebSockets already) as well as "legacy" BFCP devices. > > Also, there will be use cases for BFCP endpoints not involved in the media flow at all. Best regards Sergio From oej@edvina.net Thu Apr 4 13:13:12 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C33821F862A for ; Thu, 4 Apr 2013 13:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+n5ykCW7nhU for ; Thu, 4 Apr 2013 13:13:12 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C021821F8629 for ; Thu, 4 Apr 2013 13:13:10 -0700 (PDT) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id B050993C1AF; Thu, 4 Apr 2013 20:12:53 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Apr 2013 22:12:20 +0200 Message-Id: <49D7A71B-6D88-42A1-AC8D-9CB300B077EE@edvina.net> To: "dispatch@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [dispatch] SIP SNMP MIB and new transports X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:13:12 -0000 Hi! RFC 4780 defines an OID for transports. If we add new transports = (websockets) we need to expand this table. The RFC in itself doesn't = outline a procedure for extending it.=20 Should the draft for websockets transport extend the MIB? In the Kamailio SNMP implementation, I have used bit 6 for ws and 7 for = wss. /O ------ SipTCTransportProtocol ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "This convention is a bit map. Each bit represents a transport protocol. If a bit has value 1, then that selected transport protocol is in some way dependent on the context of the object using this convention. If a bit has value 0, then that transport protocol is not selected. Combinations of bits can be set when multiple transport protocols are selected. bit 0: a protocol other than those defined here bit 1: User Datagram Protocol bit 2: Transmission Control Protocol bit 3: Stream Control Transmission Protocol bit 4: Transport Layer Security Protocol over TCP bit 5: Transport Layer Security Protocol over SCTP " REFERENCE " RFC 3261, Section 18 and RFC 4168 " SYNTAX BITS { other(0), -- none of the following udp(1), tcp(2), sctp(3), --=20 RFC4168 tlsTcp(4), tlsSctp(5) --=20 RFC 4168 }= From stpeter@stpeter.im Thu Apr 4 19:38:25 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A582121F8F4A for ; Thu, 4 Apr 2013 19:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwgMqyRunVL3 for ; Thu, 4 Apr 2013 19:38:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1A721F8F6F for ; Thu, 4 Apr 2013 19:38:25 -0700 (PDT) Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 022C340DC2 for ; Thu, 4 Apr 2013 20:48:13 -0600 (MDT) Message-ID: <515E391A.3030800@stpeter.im> Date: Thu, 04 Apr 2013 20:38:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: DISPATCH References: <20130405023718.11095.85523.idtracker@ietfa.amsl.com> In-Reply-To: <20130405023718.11095.85523.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130405023718.11095.85523.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-im-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 02:38:25 -0000 FYI. -------- Original Message -------- Subject: I-D Action: draft-saintandre-sip-xmpp-im-03.txt Date: Thu, 04 Apr 2013 19:37:18 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging Author(s) : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-saintandre-sip-xmpp-im-03.txt Pages : 10 Date : 2013-04-04 Abstract: This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-im There's also a htmlized version available at: http://tools.ietf.org/html/draft-saintandre-sip-xmpp-im-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-saintandre-sip-xmpp-im-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From stpeter@stpeter.im Thu Apr 4 20:10:37 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF78321F9690 for ; Thu, 4 Apr 2013 20:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdPmT5ov+he6 for ; Thu, 4 Apr 2013 20:10:37 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 29B2621F9680 for ; Thu, 4 Apr 2013 20:10:37 -0700 (PDT) Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 81D1E40DC2 for ; Thu, 4 Apr 2013 21:20:26 -0600 (MDT) Message-ID: <515E40A6.90508@stpeter.im> Date: Thu, 04 Apr 2013 21:10:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: DISPATCH References: <20130405030911.17780.89055.idtracker@ietfa.amsl.com> In-Reply-To: <20130405030911.17780.89055.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130405030911.17780.89055.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-chat-05.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 03:10:37 -0000 FYI. -------- Original Message -------- Subject: I-D Action: draft-saintandre-sip-xmpp-chat-05.txt Date: Thu, 04 Apr 2013 20:09:11 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Author(s) : Peter Saint-Andre Eddy Gavita Nazin Hossain Salvatore Loreto Filename : draft-saintandre-sip-xmpp-chat-05.txt Pages : 12 Date : 2013-04-04 Abstract: This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-chat There's also a htmlized version available at: http://tools.ietf.org/html/draft-saintandre-sip-xmpp-chat-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-saintandre-sip-xmpp-chat-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From stpeter@stpeter.im Thu Apr 4 20:19:26 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071B121F9691 for ; Thu, 4 Apr 2013 20:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZy+XW+IhK-l for ; Thu, 4 Apr 2013 20:19:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 569F721F9669 for ; Thu, 4 Apr 2013 20:19:25 -0700 (PDT) Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B28A740DC2 for ; Thu, 4 Apr 2013 21:29:14 -0600 (MDT) Message-ID: <515E42B5.6010504@stpeter.im> Date: Thu, 04 Apr 2013 21:19:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: DISPATCH References: <20130405031630.7120.80812.idtracker@ietfa.amsl.com> In-Reply-To: <20130405031630.7120.80812.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130405031630.7120.80812.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dispatch] Fwd: I-D Action: draft-ivov-xmpp-cusax-04.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 03:19:26 -0000 FYI. -------- Original Message -------- Subject: I-D Action: draft-ivov-xmpp-cusax-04.txt Date: Thu, 04 Apr 2013 20:16:30 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) Author(s) : Emil Ivov Peter Saint-Andre Enrico Marocco Filename : draft-ivov-xmpp-cusax-04.txt Pages : 11 Date : 2013-04-04 Abstract: This document describes suggested practices for combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). Such practices aim to provide a single fully featured real-time communication service by using complementary subsets of features from each of the protocols. Typically such subsets would include telephony capabilities from SIP and instant messaging and presence capabilities from XMPP. This specification does not define any new protocols or syntax for either SIP or XMPP. However, implementing it may require modifying or at least reconfiguring existing client and server-side software. Also, it is not the purpose of this document to make recommendations as to whether or not such combined use should be preferred to the mechanisms provided natively by each protocol (for example, SIP's SIMPLE or XMPP's Jingle). It merely aims to provide guidance to those who are interested in such a combined use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax There's also a htmlized version available at: http://tools.ietf.org/html/draft-ivov-xmpp-cusax-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ivov-xmpp-cusax-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From gonzalo.camarillo@ericsson.com Thu Apr 4 23:13:11 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D9B21F96F0 for ; Thu, 4 Apr 2013 23:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.236 X-Spam-Level: X-Spam-Status: No, score=-106.236 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdHxbCJaot7M for ; Thu, 4 Apr 2013 23:13:11 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AA24021F96EF for ; Thu, 4 Apr 2013 23:13:10 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-d1-515e6b75a7c4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 38.BB.19728.57B6E515; Fri, 5 Apr 2013 08:13:09 +0200 (CEST) Received: from [131.160.126.117] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Apr 2013 08:13:09 +0200 Message-ID: <515E6B74.5030506@ericsson.com> Date: Fri, 5 Apr 2013 09:13:08 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIJMWRmVeSWpSXmKPExsUyM+JvrW5pdlygQeNjNYulkxawOjB6LFny kymAMYrLJiU1J7MstUjfLoErY/pn84IetoqJP2ezNjA+ZOli5OSQEDCR2LFvFhOELSZx4d56 ti5GLg4hgVOMEhdmbGGBcNYwSiyZvQusildAW6Jr/yT2LkYODhYBFYlXNzJAwmwCFhJbbt0H GyoqECXx7+1uRohyQYmTM5+AxUUEFCT2XjrACmILC2hInOt7xgaxWFJi0bROsBpmAT2JKVdb GCFseYntb+cwg9hCQGuXP2thmcDIPwvJ2FlIWmYhaVnAyLyKkT03MTMnvdxoEyMwmA5u+a26 g/HOOZFDjNIcLErivOGuFwKEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MCZ7JLMEbnip+Xrn m+ATXleWG9mbO4iIZH1RE9OoULIMmJS+rF5528ztN3x+3HWJ2zc98J7W+jvrLp3ddSFvld9i oxnpme9amlViG0+cWPH2966ltUUu7yaYsoSENs+wyv3fJtfv18L29Ii6VEUO19dn4uHm/25a hodpdXzTycxl0layW3mrWomlOCPRUIu5qDgRAHyiW670AQAA Subject: [dispatch] Acronym for the SIP-XMPP effort X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 06:13:11 -0000 Folks, I am going to handle the chartering of the SIP-XMPP effort, as discussed in Orlando. As usual, we need to choose an acronym for the group. Among the acronyms I have heard, I like this one best so far: SIXPAC - SIP Integration with XMPP in Presence Aware Contexts While, per the RAI tradition, it refers to an alcoholic drink, usually beers, it also refers to the nice six packs all RAI contributors are working on during the spring in order to show off at the beach in summer :-) Any other suggestions? With respect to the chairs for this effort, we will be choosing them soon as well. So, if you are interested but have not volunteered yet per my other email (from yesterday), now it would be a great time to drop me a note. Thanks, Gonzalo From br@brianrosen.net Fri Apr 5 06:20:37 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFA421F9788 for ; Fri, 5 Apr 2013 06:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.129 X-Spam-Level: X-Spam-Status: No, score=-100.129 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnUA1fwfrDBJ for ; Fri, 5 Apr 2013 06:20:36 -0700 (PDT) Received: from mm2.idig.net (raphotoclub.ca [70.33.247.99]) by ietfa.amsl.com (Postfix) with ESMTP id EA8D721F978A for ; Fri, 5 Apr 2013 06:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=hhH+2j0xmAc8Uj8xaJb40P+WOMMgurNOEmv1JcE8HQw=; b=UmomKSqFO9itjTpGYziPYpG5XCtnk2kuAWFNQdCLpQl2T/drFyCt1JJrdwtvc7LbEAc7spBkVL/6JiGx4+fi+3NMqgVmFOHbQcyFfCH3cup/FDtE2bimWObj0CX/EXS+FTyXLSvze6iqakSwkOOgG//5Ny3llyV9qOXW24Iaeis=; Received: from neustargw.va.neustar.com ([209.173.53.233]:40282 helo=[192.168.133.229]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UO6ZC-0004wV-Cf; Fri, 05 Apr 2013 09:20:30 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <515CDDB1.2010809@stpeter.im> Date: Fri, 5 Apr 2013 09:20:28 -0400 Content-Transfer-Encoding: 7bit Message-Id: <0900D531-F793-42B3-9868-DDC35F9520C0@brianrosen.net> References: <515CDDB1.2010809@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: DISPATCH Subject: Re: [dispatch] conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 13:20:37 -0000 > It strikes me that one solution here would be to establish an IANA > registry for conference roles, with a registration policy (cf. RFC > 5226) of at least Expert Review and perhaps Specification Required (I > think RFC Required is a bit heavy). IMHO this would help to prevent > continued confusion and the minting of new roles that overlap with > existing roles. I like this idea. Brian From salvatore.loreto@ericsson.com Fri Apr 5 06:55:18 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8E421F97BE for ; Fri, 5 Apr 2013 06:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2NVKK8YI3PC for ; Fri, 5 Apr 2013 06:55:17 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7423B21F97B9 for ; Fri, 5 Apr 2013 06:55:17 -0700 (PDT) X-AuditID: c1b4fb30-b7f0d6d000007e61-14-515ed7c40803 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DB.A6.32353.4C7DE515; Fri, 5 Apr 2013 15:55:16 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Apr 2013 15:55:15 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id ACB4124ED for ; Fri, 5 Apr 2013 16:55:15 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EC9BA54980 for ; Fri, 5 Apr 2013 16:55:12 +0300 (EEST) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AC2D45441B for ; Fri, 5 Apr 2013 16:55:12 +0300 (EEST) Message-ID: <515ED83C.4090800@ericsson.com> Date: Fri, 5 Apr 2013 16:57:16 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <515CDDB1.2010809@stpeter.im> In-Reply-To: <515CDDB1.2010809@stpeter.im> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvre6R63GBBv9WSFgsnbSA1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGT/nHWYqOMlWcWLXLKYGxsWsXYycHBICJhI3uiaxQ9hiEhfu rWfrYuTiEBI4xSjxceNVZghnPaPE9MuPmCCcy4wSk5ZdgMocY5RY+uUWlLOPUeLIvh4WkGG8 AtoSvX//s4HYLAIqEg8mrmUCsdkEzCSeP9wC1MDBISqQLPF/hzdEuaDEyZlPwFpFBEQl5q9Y BHaTsICGxPItO8DGCAloSnw+OBtsDKeAlsSlRa1gNrOArcSFOddZIGx5ie1v5zBD/KMmcfXc JmaIXi2J3rOdTBMYRWYhWTcLSfssJO0LGJlXMbLnJmbmpJebb2IEBvPBLb8NdjBuui92iFGa g0VJnDfc9UKAkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbI8LqT36uNWZzWXHfdc8ktLy/g cnKCjVuUQJ1lzv1+K/VA1mnuRq5yL27PqXE3e9Gw6+6ZdcGpUfmaB5SSHF6kf2mcHpYjsSDn 6KEV8kZBZczylXsv+WbI74z3TAi9Vc4ooHQ9/Onn9vnXN13j09jHaZIwV62stY3nne609auZ /i1RPvTeVYmlOCPRUIu5qDgRAGyeigI0AgAA Subject: Re: [dispatch] conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 13:55:18 -0000 On 4/4/13 4:56 AM, Peter Saint-Andre wrote: > Furthermore, I'm concerned that various implementations will define > their own roles, blithely unaware that very similar (or even identical > but differently named roles) are already in use by other implementations. > > It strikes me that one solution here would be to establish an IANA > registry for conference roles, with a registration policy (cf. RFC > 5226) of at least Expert Review and perhaps Specification Required (I > think RFC Required is a bit heavy). IMHO this would help to prevent > continued confusion and the minting of new roles that overlap with > existing roles. > > Thoughts? I do think is a good idea to establish a IANA registry for conference roles and I concur on the fact that RFC Required is a bit too much (and unnecessary) cheers Salvatore From pkyzivat@alum.mit.edu Fri Apr 5 08:25:02 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168D721F97E1 for ; Fri, 5 Apr 2013 08:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwnON9vdekof for ; Fri, 5 Apr 2013 08:25:01 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 40B2B21F97DA for ; Fri, 5 Apr 2013 08:25:01 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta01.westchester.pa.mail.comcast.net with comcast id LCkj1l0071uE5Es51FR0Zq; Fri, 05 Apr 2013 15:25:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id LFR01l00h3ZTu2S3cFR0bW; Fri, 05 Apr 2013 15:25:00 +0000 Message-ID: <515EECF3.1080906@alum.mit.edu> Date: Fri, 05 Apr 2013 23:25:39 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <49D7A71B-6D88-42A1-AC8D-9CB300B077EE@edvina.net> In-Reply-To: <49D7A71B-6D88-42A1-AC8D-9CB300B077EE@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365175500; bh=yBXat+vTaRakB+g1bjccvWwy9mtotJs+B5izBJp8RwQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SvVeTY7j/63knEZ21EoKzd3N2EkV1uP2R7rFCl5tiWHqbOA4H++yQ+ZPwuoSAvFn7 M7X972fgf/eRkgdoNN4Z51VgI2NSPVQAVIHbUr/66dAEbqOO9RCpMDvi1JWE93TwFp 6DhXxwWB3LtUBgo63FSfzlaC3kCPe17mCEFsjzY7zYzhM9q69tk3EjR5+4yzaPm97q aftKECznjSqo201wVDmZgZws/ScdcU6PqotQQKm0wEqndsKJyYkVNsJ0tR3LV55YJe W1vzSITRoYpsX2iiWE+HMUaUoywe/vV56eD1cCf7DoPW75lzt2KoyzTAZOT44zd29o VLirZOVUAV/Fw== Subject: Re: [dispatch] SIP SNMP MIB and new transports X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 15:25:02 -0000 Olle, On 4/5/13 4:12 AM, Olle E. Johansson wrote: > Hi! > > RFC 4780 defines an OID for transports. If we add new transports (websockets) we need to expand this table. The RFC in itself doesn't outline a procedure for extending it. > > Should the draft for websockets transport extend the MIB? It is too bad this wasn't raised sooner, e.g. during WGLC. draft-ietf-sipcore-sip-websocket-08 is now with the editor, so it is really too late to address this in that draft now. So if something needs to be done about this then I guess it will require a separate draft. For the moment, ISTM the obvious work around is: bit 0: a protocol other than those defined here > In the Kamailio SNMP implementation, I have used bit 6 for ws and 7 for wss. I know *nothing* about mibs, but when looking at 4780 I don't see any evidence that it was designed with a mechanism for extension as new transports are defined. Is there some way to fix that, and link it to a new IANA registry? Thanks, Paul > /O > > ------ > > SipTCTransportProtocol ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "This convention is a bit map. Each bit represents a transport > protocol. If a bit has value 1, then that selected transport > protocol is in some way dependent on the context of the object > using this convention. If a bit has value 0, then that > transport protocol is not selected. Combinations of bits can > be set when multiple transport protocols are selected. > > bit 0: a protocol other than those defined here > bit 1: User Datagram Protocol > bit 2: Transmission Control Protocol > bit 3: Stream Control Transmission Protocol > bit 4: Transport Layer Security Protocol over TCP > bit 5: Transport Layer Security Protocol over SCTP > " > REFERENCE " > RFC 3261, Section 18 and RFC 4168 > " > SYNTAX BITS { > other(0), -- none of the following > udp(1), > tcp(2), > sctp(3), -- > RFC4168 > > tlsTcp(4), > tlsSctp(5) -- > RFC 4168 > > } > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From stpeter@stpeter.im Fri Apr 5 08:30:52 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0AE21F97E9 for ; Fri, 5 Apr 2013 08:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECyf-n-H5zOy for ; Fri, 5 Apr 2013 08:30:51 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3C32F21F97DE for ; Fri, 5 Apr 2013 08:30:51 -0700 (PDT) Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C67CF406D9; Fri, 5 Apr 2013 09:40:41 -0600 (MDT) Message-ID: <515EEE29.60700@stpeter.im> Date: Fri, 05 Apr 2013 09:30:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Salvatore Loreto References: <515CDDB1.2010809@stpeter.im> <515ED83C.4090800@ericsson.com> In-Reply-To: <515ED83C.4090800@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 15:30:52 -0000 On 4/5/13 7:57 AM, Salvatore Loreto wrote: > On 4/4/13 4:56 AM, Peter Saint-Andre wrote: >> Furthermore, I'm concerned that various implementations will define >> their own roles, blithely unaware that very similar (or even identical >> but differently named roles) are already in use by other implementations. >> >> It strikes me that one solution here would be to establish an IANA >> registry for conference roles, with a registration policy (cf. RFC >> 5226) of at least Expert Review and perhaps Specification Required (I >> think RFC Required is a bit heavy). IMHO this would help to prevent >> continued confusion and the minting of new roles that overlap with >> existing roles. >> >> Thoughts? > I do think is a good idea to establish a IANA registry for conference roles > and I concur on the fact that RFC Required is a bit too much (and > unnecessary) OK. I might write a brief I-D about this sometime soon. Peter -- Peter Saint-Andre https://stpeter.im/ From pkyzivat@alum.mit.edu Fri Apr 5 08:31:04 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8ED21F9822 for ; Fri, 5 Apr 2013 08:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mO4JMq-3-qa for ; Fri, 5 Apr 2013 08:31:04 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD7F21F9820 for ; Fri, 5 Apr 2013 08:31:03 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta09.westchester.pa.mail.comcast.net with comcast id LCJm1l0031ap0As59FWzoD; Fri, 05 Apr 2013 15:30:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id LFWz1l00E3ZTu2S3iFWz8w; Fri, 05 Apr 2013 15:30:59 +0000 Message-ID: <515EEE5E.3060708@alum.mit.edu> Date: Fri, 05 Apr 2013 23:31:42 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <515CDDB1.2010809@stpeter.im> <0900D531-F793-42B3-9868-DDC35F9520C0@brianrosen.net> In-Reply-To: <0900D531-F793-42B3-9868-DDC35F9520C0@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365175859; bh=8J8hh/N0Wq2C0bFSwtYXJNZcJ364QNsQEd0nDlh02QU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PV/CQvsc15vRCRqCCgk2lbxf94Sn6odM3Gp+54JLsY19kl8Kwp71q+rwdVINvTgCI iian4JQGl190YfxVnvD/ksDtNhOksAJFFukPfb+uKQ1swzmyTpkMZ8ULgKz0aK0c8K KTT/+gMFTrV5l+WrTC8epygz0fkZT+Oovy4MJ0+n8OZFC4uFrjRnylPpNPyTO+Exrw dagX4yM2q3VC5F0js+wsPw10oqw1jERjdLWDN+PW08b94p0/1JvVk0rH8G4R2shFuq HSfqY/almlrhF9wDSlL8dHA/1YEZNRS73BBzZWoTRdDqg+nFEu16zWLCW8H7tq03HY rSA+fhm2QjGIA== Subject: Re: [dispatch] conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 15:31:04 -0000 This also seems reasonable to me. But I would be conservative about policy for new ones. I don't think we know enough to describe criteria for an expert, and I expect there to be a lot of bad ideas to come up here. So I think I would go for Standards Action for now, to ensure strong debate. Even then, I think we need to think hard about definitions for the first batch, that clearly distinguish one role from another. Thanks, Paul On 4/5/13 9:20 PM, Brian Rosen wrote: >> It strikes me that one solution here would be to establish an IANA >> registry for conference roles, with a registration policy (cf. RFC >> 5226) of at least Expert Review and perhaps Specification Required (I >> think RFC Required is a bit heavy). IMHO this would help to prevent >> continued confusion and the minting of new roles that overlap with >> existing roles. > I like this idea. > > Brian > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From stpeter@stpeter.im Fri Apr 5 08:37:38 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133C921F982D for ; Fri, 5 Apr 2013 08:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KCyY499zL9q for ; Fri, 5 Apr 2013 08:37:36 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8467B21F9847 for ; Fri, 5 Apr 2013 08:37:36 -0700 (PDT) Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 01B19406D9; Fri, 5 Apr 2013 09:47:16 -0600 (MDT) Message-ID: <515EEFB4.9030404@stpeter.im> Date: Fri, 05 Apr 2013 09:37:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Paul Kyzivat References: <515CDDB1.2010809@stpeter.im> <0900D531-F793-42B3-9868-DDC35F9520C0@brianrosen.net> <515EEE5E.3060708@alum.mit.edu> In-Reply-To: <515EEE5E.3060708@alum.mit.edu> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 15:37:38 -0000 On 4/5/13 9:31 AM, Paul Kyzivat wrote: > This also seems reasonable to me. But I would be conservative about > policy for new ones. I don't think we know enough to describe criteria > for an expert, and I expect there to be a lot of bad ideas to come up > here. So I think I would go for Standards Action for now, to ensure > strong debate. You make a good point about being able to provide clear guidelines to an expert. We either need to figure that out during the process of defining this IANA registry or use the standards process to become clear on each registration request as it comes in. > Even then, I think we need to think hard about definitions for the first > batch, that clearly distinguish one role from another. Agreed. Peter -- Peter Saint-Andre https://stpeter.im/ From jmpolk@cisco.com Fri Apr 5 12:35:57 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E5121F9875 for ; Fri, 5 Apr 2013 12:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.3 X-Spam-Level: X-Spam-Status: No, score=-109.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UkNZ7oLZn2I for ; Fri, 5 Apr 2013 12:35:56 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 80D4221F9895 for ; Fri, 5 Apr 2013 12:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=341; q=dns/txt; s=iport; t=1365190556; x=1366400156; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=dU+zY4NNcu1+BktLZJqeykiGjQlUtyAOPve/jauPXvA=; b=SqRcVQcGrls4RaploA+bcuQICFSku1KKoetR2+tfB6ygtS9TWvXcNg3s +89yyfKmOigXOatiB+wu6JNcJRlv8w8QpmKPB+x9iHX2UjZ3+vZUmJ5E+ KyHRtpfaN+P2J8atidGJKDZMAuXqDSS3zvdqrx3SQ+bnNWiP3VssmT8jc 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAF8mX1GtJV2Y/2dsb2JhbABLgwbBW4ENFnSCHwEBAQQ4Ak8HBBgJFRAPCj4GAYgmwiCPIoNAA4h8nn+DKR4 X-IronPort-AV: E=Sophos;i="4.87,416,1363132800"; d="scan'208";a="195590788" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 05 Apr 2013 19:35:56 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8718.cisco.com [10.99.80.25]) (authenticated bits=0) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r35JZtJx003139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Apr 2013 19:35:56 GMT Message-Id: <201304051935.r35JZtJx003139@rcdn-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 05 Apr 2013 14:34:47 -0500 To: Gonzalo Camarillo , DISPATCH From: James Polk In-Reply-To: <515E6B74.5030506@ericsson.com> References: <515E6B74.5030506@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [dispatch] Acronym for the SIP-XMPP effort X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 19:35:57 -0000 At 01:13 AM 4/5/2013, Gonzalo Camarillo wrote: >I am going to handle the chartering of the SIP-XMPP effort, as discussed >in Orlando. As usual, we need to choose an acronym for the group. Among >the acronyms I have heard, I like this one best so far: > > SIXPAC - SIP Integration with XMPP in Presence Aware Contexts wfm James From michaellundberg.ietf@gmail.com Fri Apr 5 13:13:36 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6972421F96AB for ; Fri, 5 Apr 2013 13:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cpVCk8beL5e for ; Fri, 5 Apr 2013 13:13:35 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id F3F3121F8CE8 for ; Fri, 5 Apr 2013 13:13:34 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id d7so3131904wer.12 for ; Fri, 05 Apr 2013 13:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=pgzXfAPbE74D3JfgtPJLhmmWkvTmpeUWhMZK97J3gQY=; b=zUNOg1RF7S5wXDHFdMk3AubuZ7E5Fr5wUEx9dECbzNGv16RtIUD6j4lADVzylfADiQ z4nNG7pNd/zas+tdx7UFPd3pYsDqIJXlom/rO8DgTFRCtjNVU/a3yg9AnwgO2hP8DbiS aatdBWLaLAATEyW6N8J+qkr/pujKYp1gdT+dapFUOtPPazEi2ZCdfqbgPzwl+JXjFjTL W7cQRJpBWwv1JX3qYWpauluaGLrqCWHrqPslUXn3qWJX41Rs3DqkkGmnmy17c5nShC1f Fgfwa8L8aFSAZEt38yq579BQeJWnQElHuboBvTeBVwv7p09RtfIdXrBEG58sGqy6KXHU /ALg== MIME-Version: 1.0 X-Received: by 10.180.97.132 with SMTP id ea4mr846132wib.23.1365192813989; Fri, 05 Apr 2013 13:13:33 -0700 (PDT) Received: by 10.216.163.194 with HTTP; Fri, 5 Apr 2013 13:13:33 -0700 (PDT) In-Reply-To: <515BAAEE.2070305@stpeter.im> References: <515BAAEE.2070305@stpeter.im> Date: Fri, 5 Apr 2013 16:13:33 -0400 Message-ID: From: Michael Lundberg To: Peter Saint-Andre Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on draft-saintandre-sip-xmpp-presence-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 20:13:36 -0000 Peter, Thanks. I think the updates look good. One additional suggestion is to add the element to Table 7, with a note similar to the one provided in Table 6. This will provide a method for mapping 'away' and 'dnd' information in the opposite direction. Similar to the note in Table 6, this would require the SIP implementation to support the 'jabber:client' namespace. If the SIP implementation supports the namespace, the gateway can then map the values directly into the element of the XMPP presence messages. Regards, Michael On Wed, Apr 3, 2013 at 12:07 AM, Peter Saint-Andre wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael, I think your feedback has been addressed in -05. Please check. > > On 3/9/13 5:29 PM, Michael Lundberg wrote: >> Peter, >> >> Thanks for resubmitting the SIP-XMPP presence I-D. I think this >> and the other documents are important as there are a lot of >> interworking issues today with XMPP and SIP/SIMPLE implementations, >> and I think these documents can help reduce some of those >> interworking challenges. >> >> In order to help ensure interworking between different >> implementations, I think Sections 5.2 and 5.3 need to have some >> stronger =91MUST=92 language instead of SHOULDs, MAYs, etc. This will >> enforce proper and complete mappings between implementations that >> conform to this document. >> >> While I don=92t think the document needs to enforce the use of the >> element mapping discussed in 5.2, I think if >> implementations are going to use the mapping, this document should >> enforce the use of a specific namespace and describe the mapping of >> values specified in RFC 6121 (i.e., away, dnd, chat, and >> xa). This will at least allow a minimum set of standard mappings >> between XMPP and SIP, which can be expanded on in future >> document(s). Section 5.3 could then also discuss how this mapping >> can be accomplished from SIP to XMPP if the SIP endpoints/devices >> support this same namespace. One of the big interworking >> challenges with today=92s implementations is the use of different >> namespaces given the extensibility of XML-based presence standards >> (e.g., PIDF, RPID), which allows individuals to create their own >> namespace. This flexibility is good for ingenuity, but problematic >> for interworking between different implementations. I think >> standardizing a basic set of common status information using a >> specific namespace is needed, and this document is a good place to >> do that. >> >> In my opinion, I do not think Section 6 should be part of this >> base document. While I like the idea of encapsulating the SIP >> information into the XMPP message, I think this content >> should be a consideration for implementing =91rich presence=92. As >> written, this method is only applicable for SIP to XMPP >> translation, and if the focus of this document is just =91basic=92 >> presence information interworking, the SIP to XMPP mapping in >> Section 5.3 already describes a method for how this can be >> accomplished. >> >> Regards, Michael _______________________________________________ >> dispatch mailing list dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRW6rtAAoJEOoGpJErxa2pF0sP/0IHN6cPgtVnXRKhYh8SrHi6 > 8MuBgX/ChhuIGS/OtNuO8b334KnBs65DjMakgVSTYqu+QD6ng/MIgLMtoumSbYv0 > EJWgyxKY8uuO5HMUshZ7p70ApK6+DD0PqeVKR7bKtFXPFGaVJ/6+NAzSAVSUAJze > 4qVSbEkD8/ZQAzo+Y7IRuDXE8j70ZFhTAZUrK22GH00aw++CiXe6VqPBr0eDpsT+ > 6xJt9uTwoEBmJ4r97772VI1lX+wrZkQvuhysHyAyq+XsUGpMliFCT+sra5KqAjo1 > FDr0zSgz+zf3zqFolORaSaMxYe3Zfc8uzg7XBti3dhnZY0J1HtRZ+ZcBh49YxJc+ > ahMrw2K/MiVq+ZgDAwqp6qL64n1TgaXXToDprnYlxFWItlTH/E7oLAcZdBjc6ebn > gRWsA/NuE/u12pggoKb42ifW3Zn5J6rGfx4YYSMPmHbzAqmzbOxntL2jKpfd092i > BvoVMG/tS7zRiJTfrx+7fAwkUVBgB6SG1w61xPqupmVBc3KWtQyDsYkizLeRDzNx > 5jghVEuuDkb/g27flFX4f5KsjXbpeOqoChEbaI0S9Mfk5QZvMgybFoq0Zbb1bhCu > Tzia87u+/MiUPQQjaIde75TI33OMX2RsitAWA5+JoBoDKgTFzfd7BcrQrdY7uExo > Cf07OkOWExZN9vonPOWk > =3DQs0U > -----END PGP SIGNATURE----- From ron.even.tlv@gmail.com Fri Apr 5 13:46:30 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B60521F98E1 for ; Fri, 5 Apr 2013 13:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WuTM4h8ijR6 for ; Fri, 5 Apr 2013 13:46:29 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F289C21F98D0 for ; Fri, 5 Apr 2013 13:46:28 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id z7so1487494eaf.17 for ; Fri, 05 Apr 2013 13:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=E2Xmi95EBZJWqbcXNo51Wpy/PkbBSzuQqZEieukzCog=; b=xZrZOfjn1MK8EXuqBlILyQ8fvXIIsfgJWUHJ8lgd9SlgWgDc3wzgYZ4lhfhXQSe2qP qfXE0AGqIF5mxAnOeoGuwM2OAlllHrw/60iBh/oHVULTEUoeiXEA1bD/S3D1qE6n4bZ2 lJSDtdNHia8r6e/9MIGe3IQl7iHcA+H1bHkO7noXMh/cGok1wPea4MIoXCoXuhW9XZUj d+38SszoyJ33N9mtnbkWEBR+e38sksGfdc0dn5wwNRzK+U7xMP3PQrtBFoUYTxWcrtrj hH8cnaQ9o/ZHAjChB6rCR7Nb8QdEoL3R/CPczxhoOjTDbepIcyqiBt6614Ce+vF5Pwu1 oIXw== X-Received: by 10.14.107.69 with SMTP id n45mr1235354eeg.23.1365194788083; Fri, 05 Apr 2013 13:46:28 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id s3sm17525095eem.4.2013.04.05.13.46.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 05 Apr 2013 13:46:27 -0700 (PDT) From: "Roni Even" To: "'Peter Saint-Andre'" , "'DISPATCH'" References: <515CDDB1.2010809@stpeter.im> In-Reply-To: <515CDDB1.2010809@stpeter.im> Date: Fri, 5 Apr 2013 23:46:00 +0300 Message-ID: <01cc01ce323e$96d92f20$c48b8d60$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFua3zcil2UbbMMDnvyWiErcdpwqpmHpTSw Content-Language: en-us Subject: Re: [dispatch] conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 20:46:30 -0000 Hi, I think that we first need to understand the scope of the role. RFC 4575 talks about the role of the user. This is the conference participant. There is also RFC4796 that defines the content attribute which talks about the content of an RTP stream. In CLUE we are talking about a capture which is a specific stream again and not about the participant role. So if we proceed we first need to specify what we mean by role. Roni Even. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Saint-Andre Sent: 04 April, 2013 4:56 AM To: DISPATCH Subject: [dispatch] conference roles -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 RFC 4575 (Section 5.6.3) defines the concept of a role in a conference, but does not specify or define any roles. 5.6.3. This element MAY contain a set of human-readable strings describing the roles of the user in the conference. Note that this information is applicable for human consumption only. This specification does not define the set of possible conferencing roles or the semantics associated with each. It is expected that future conferencing specifications will define these and the corresponding schema extensions, as appropriate. RFC 6501 (Section 4.6.5.2) specifies a few values for the role element, but does not actually define what those values mean. 4.6.5.2. A provides the context for the set of conference operations that a participant can perform. This element can contain one or more of the following values: "administrator", "moderator", "user", "participant", "observer", and "none". A role of "none" indicates that any role is assigned. The semantic definition is out of the scope of this document and is subject to future policy documents. This element can be extended with new roles in future documents. (As far as I know, those "future policy documents" have not been published.) More recently, draft-groves-clue-capture-attr specifies several additional roles: "manager", "chairman", "secretary", "lecturer", and "audience" (so-called person roles) as well as "speaker" and "controller" (so-called conference roles). Personally, I happen to have an interest in defining a few other roles, such as "host", "presenter", "scribe", and "panelist". Unfortunately there's quite a bit of overlap and confusion here. For instance, one could argue that "host", "manager", and "controller" (perhaps even "chairman") are the same as or very similar to "administrator" or "moderator" from RFC 6501. There might also be overlap between "lecturer", "speaker", and "presenter" (and between "speaker" and "panelist"). Furthermore, I'm concerned that various implementations will define their own roles, blithely unaware that very similar (or even identical but differently named roles) are already in use by other implementations. It strikes me that one solution here would be to establish an IANA registry for conference roles, with a registration policy (cf. RFC 5226) of at least Expert Review and perhaps Specification Required (I think RFC Required is a bit heavy). IMHO this would help to prevent continued confusion and the minting of new roles that overlap with existing roles. Thoughts? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRXN2wAAoJEOoGpJErxa2p98YP/1AtEgnS9T6w9aYc4V66Z0wv AJJ0r4Xk8mKWyqYsovyyqLoXnqnFitOSBrlt1pskDw/pDhI08LZiPkN3G3sMDSdo qhCen5UcSMRaKwDCaddXiIOzMP2IOEqJFltWWj32BX/qgtYVSMac9Vgsw/HJWzUi hjLM5U84W4mLBLGC5XgT7jqwTYA3pb1tqfN0Fn1Ony/kW9Nmy0+fciQhMTLrkOi6 cwplCwdNsmZeGbp4ABlDMLA2WcilqmU7Iu61lKlNmbnizTXGeTznsst51LZvuEO3 c9z0UUQl+g88F4ZxBphdbtxzK9qRFD4l+FSRRwPxM3vggjVUSp829GCHEgdUeyel v3Mxy0aTmsziKOUJ3lTU2mi3RGu9b7lkei0t1EF8rXAz6upMCJcd+90qD29QbP3s z5V6hz7iJCe172XiElmbX29d2u3yt7SbHNX9Ime4SvHMWX9NrJyuoOiSk+7IF73k qX2QIe3JJDPX4Q0KO9Od64m95hjPgM2EiYj7gFbq9K3cAwZ0x3nExWN4+XB2WWyJ Qo4+vSk1eL04dzcy06m7cDrM9snlm4usOA8YrvabItAKryl9E8d0rqNi8Y6PB2sI IcnT73QbPJIvLzP/Z03Pn4n1uhz0K+QjIySJKW3bcs0Nj5qyjyMAQCIt+DvzP8Fq 5PghQ2Ey40XHE3Mp6V35 =i5bw -----END PGP SIGNATURE----- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From eckelcu@cisco.com Fri Apr 5 15:09:18 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8FE21F9890 for ; Fri, 5 Apr 2013 15:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTeWFJWDRuVG for ; Fri, 5 Apr 2013 15:09:17 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D66C321F987C for ; Fri, 5 Apr 2013 15:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2773; q=dns/txt; s=iport; t=1365199758; x=1366409358; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Cc5rCoL1Q6Kz8uhWa4OmM0qLL14nTwdlKq44+pWqxeg=; b=iz6x86fZGnOxson2iiI+fd7rLV6vJgWpZEkO4Npg5sTMPm+6fD7wGfbU DX0uyzVXn35LVJhqH7EbY1gKziL1ys2Ckj04dwbuNj0lReedy5dr3iyWH 4K5i+jbSS03qGnqSMLvLc0vz2HQxlrc0qCQnumJI59UdnUxuxVavli8xG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAEJKX1GtJV2b/2dsb2JhbABLgwY2wSSBDRZ0gh8BAQECAQEBAQE3GxMGCwUHBAIBCBEEAQEBChQJByEGCxQJCAIEAQ0FCId6AwkFAQy4HA2JXYxJgiEmCwcGgllhA5UOjVKFG4MLgig X-IronPort-AV: E=Sophos;i="4.87,417,1363132800"; d="scan'208";a="195612379" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 05 Apr 2013 22:09:11 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r35M9Ah9022406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Apr 2013 22:09:10 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 5 Apr 2013 17:09:10 -0500 From: "Charles Eckel (eckelcu)" To: Lorenzo Miniero , Victor Pascual Avila Thread-Topic: [dispatch] Use of BFCP or MSRP over datachannel or websocket Thread-Index: Ac4rsMGiPKz1pFC/QlekwsQdT+Np8QAPdkwAAJrbf4AAMBBWAAAC6FCAACd34YAAO57QAAACCf2AAAd5dQAAATjHgAAAwzSAABAf7IAAAVfFAABIeJMg Date: Fri, 5 Apr 2013 22:09:10 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047E386E@xmb-aln-x08.cisco.com> References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <004301ce2e30$2317e700$6947b500$@co.in> <001201ce2efc$0695a5f0$13c0f1d0$@co.in> <003601ce3088$618e3c00$24aab400$@co.in> <515C98AC.7020600@alum.mit.edu> <20130403235821.12f4e8a4@rainpc> <20130404081830.6a01c45d@rainpc> In-Reply-To: <20130404081830.6a01c45d@rainpc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:09:19 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Lorenzo Miniero > Sent: Wednesday, April 03, 2013 11:19 PM > To: Victor Pascual Avila > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket >=20 > On Thu, 4 Apr 2013 07:40:03 +0200 > Victor Pascual Avila wrote: >=20 > > On Wed, Apr 3, 2013 at 11:58 PM, Lorenzo Miniero > wrote: > > > That said, though, I may have this view because of how, just as you, = I'm > currently associating BFCP with the conferencing world (well, it was born= in > XCON after all), which may be a wrong assumption: people may be using > BFCP for entirely different scenarios as well, and the example made by > someone a few posts ago (I think it was Victor but I may be wrong) about > one of two peers acting as the floor control server in a call may be a > perfectly valid scenario for it being used differently than what I'm used= to. > > > > It was not me -- all my use cases include a conf server. On the client > > side, we have WebRTC and non-WebRTC web endpoints (all of them > > supporting WebSockets already) as well as "legacy" BFCP devices. > > > > Cheers, > > -Victor >=20 >=20 > Ops you're right, sorry about that! As they say here in Napoli, "that's h= ow > you send people to jail" :-) >=20 > I just checked the archives and it was Charles Eckel that referred to the > possibility in a couple of posts. Yes, and I still stand by BFCP being useful and implemented for point to po= int and peer to peer use cases, not just for conference calls between a cli= ent and a conference server. If you want additional details, please have a = look at the following IMTC Best Practice shared with the IETF through a lia= ison statement last year: https://datatracker.ietf.org/documents/LIAISON/liaison-2012-05-31-imtc-the-= ietf-imtc-work-on-sip-feature-parity-with-h323-attachment-3.pdf That said, I am not saying BFCP over websockets is a bad idea. Rather, I am= saying it is not sufficient for all the use cases for which BFCP is used t= oday. Perhaps that is okay, and we just need to define something else for t= he other use cases, and applications need to know when to use one method as= opposed to another. This adds complexity other than that of implementing B= FCP over websockets. Cheers, Charles =20 > Cheers, > Lorenzo >=20 > -- > Lorenzo Miniero, COB >=20 > Meetecho s.r.l. > Web Conferencing and Collaboration Tools > http://www.meetecho.com > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From worley@shell01.TheWorld.com Fri Apr 5 15:24:03 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B16721F988D for ; Fri, 5 Apr 2013 15:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CK0QshX4oxce for ; Fri, 5 Apr 2013 15:24:02 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 333DF21F90A1 for ; Fri, 5 Apr 2013 15:24:01 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r35MNS6s007253; Fri, 5 Apr 2013 18:23:30 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r35MNSDt2014449; Fri, 5 Apr 2013 17:23:28 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r35MNPP22006964; Fri, 5 Apr 2013 18:23:25 -0400 (EDT) Date: Fri, 5 Apr 2013 18:23:25 -0400 (EDT) Message-Id: <201304052223.r35MNPP22006964@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Peter Saint-Andre In-reply-to: <515CDDB1.2010809@stpeter.im> References: <515CDDB1.2010809@stpeter.im> Cc: dispatch@ietf.org Subject: Re: [dispatch] conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:24:03 -0000 > From: Peter Saint-Andre > > It strikes me that one solution here would be to establish an IANA > registry for conference roles, with a registration policy (cf. RFC > 5226) of at least Expert Review and perhaps Specification Required (I > think RFC Required is a bit heavy). IMHO this would help to prevent > continued confusion and the minting of new roles that overlap with > existing roles. > > Thoughts? My thought is that more work than this is needed. We may not need an RFC to review and define a good set of role names, but I think we need to start with an I-D that discusses all the issues and desiderata of how to define role names, and establishes an initial set. Only that sort of writing, discussion, and analysis will solidify knowledge of what how such a registry should operate. Dale From spromano@unina.it Fri Apr 5 15:40:25 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6048E21F9931 for ; Fri, 5 Apr 2013 15:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7FIRSgMz2Dd for ; Fri, 5 Apr 2013 15:40:24 -0700 (PDT) Received: from relay1.tre.it (mail.tre.it [62.13.171.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9661221F992B for ; Fri, 5 Apr 2013 15:40:23 -0700 (PDT) Received: from [192.168.1.104] ([10.88.68.46]) by relay1.tre.it with ESMTP id r35MeLG1009458-r35MeLG2009458 for ; Sat, 6 Apr 2013 00:40:22 +0200 From: Simon Pietro Romano Content-Type: multipart/alternative; boundary="Apple-Mail=_F8DF8A88-3E87-49AF-A658-7C7CB1DFBE1A" Date: Sat, 6 Apr 2013 00:40:22 +0200 References: <79CA1F04-BC72-4939-BAF9-1DC9E3149E59@unina.it> To: DISPATCH Message-Id: <59882D7F-84C6-4BDC-AB8D-6C344E0D4029@unina.it> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [dispatch] Fwd: [clue] conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:40:25 -0000 --Apple-Mail=_F8DF8A88-3E87-49AF-A658-7C7CB1DFBE1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 FYI. Simon Inizio messaggio inoltrato: > Da: Simon Pietro Romano > Oggetto: Re: [clue] [dispatch] conference roles > Data: 06 aprile 2013 00:39:19 GMT+02:00 > A: Peter Saint-Andre > Cc: clue@ietf.org >=20 > Hi Peter, >=20 > thank you for raising such an interesting discussion. This reminds me = of a specific thread dedicated to policies and roles inside XCON, back = in 2007. I expressed my personal view on this subject in a (long) e-mail = (http://www.ietf.org/mail-archive/web/xcon/current/msg01919.html) you = might want to have a look at. As you mention in your e-mail "future = policy documents" have not been published. >=20 > Cheers, >=20 > Simon >=20 >=20 > Il giorno 04/apr/2013, alle ore 16:42, Peter Saint-Andre ha scritto: >=20 >> FYI. >>=20 >>=20 >> -------- Original Message -------- >> Subject: [dispatch] conference roles >> Date: Wed, 03 Apr 2013 19:56:01 -0600 >> From: Peter Saint-Andre >> To: DISPATCH >>=20 >> RFC 4575 (Section 5.6.3) defines the concept of a role in a >> conference, but does not specify or define any roles. >>=20 >> 5.6.3. >>=20 >> This element MAY contain a set of human-readable strings describing >> the roles of the user in the conference. Note that this = information >> is applicable for human consumption only. This specification does >> not define the set of possible conferencing roles or the semantics >> associated with each. It is expected that future conferencing >> specifications will define these and the corresponding schema >> extensions, as appropriate. >>=20 >> RFC 6501 (Section 4.6.5.2) specifies a few values for the role >> element, but does not actually define what those values mean. >>=20 >> 4.6.5.2. >>=20 >> A provides the context for the set of conference operations >> that a participant can perform. This element can contain one or = more >> of the following values: "administrator", "moderator", "user", >> "participant", "observer", and "none". A role of "none" indicates >> that any role is assigned. The semantic definition is out = of >> the scope of this document and is subject to future policy = documents. >> This element can be extended with new roles in future documents. >>=20 >> (As far as I know, those "future policy documents" have not been >> published.) >>=20 >> More recently, draft-groves-clue-capture-attr specifies several >> additional roles: "manager", "chairman", "secretary", "lecturer", and >> "audience" (so-called person roles) as well as "speaker" and >> "controller" (so-called conference roles). Personally, I happen to >> have an interest in defining a few other roles, such as "host", >> "presenter", "scribe", and "panelist". >>=20 >> Unfortunately there's quite a bit of overlap and confusion here. For >> instance, one could argue that "host", "manager", and "controller" >> (perhaps even "chairman") are the same as or very similar to >> "administrator" or "moderator" from RFC 6501. There might also be >> overlap between "lecturer", "speaker", and "presenter" (and between >> "speaker" and "panelist"). >>=20 >> Furthermore, I'm concerned that various implementations will define >> their own roles, blithely unaware that very similar (or even = identical >> but differently named roles) are already in use by other = implementations. >>=20 >> It strikes me that one solution here would be to establish an IANA >> registry for conference roles, with a registration policy (cf. RFC >> 5226) of at least Expert Review and perhaps Specification Required (I >> think RFC Required is a bit heavy). IMHO this would help to prevent >> continued confusion and the minting of new roles that overlap with >> existing roles. >>=20 >> Thoughts? >>=20 >> Peter >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >>=20 >=20 > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico = II > Computer Engineering Department=20 > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it >=20 > < idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( = ( ) > \_) ) = / > = (_/ >=20 >=20 >=20 >=20 >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_F8DF8A88-3E87-49AF-A658-7C7CB1DFBE1A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Da: Simon Pietro Romano <spromano@unina.it>
Oggetto: = Re: [clue] [dispatch] conference = roles
Data: 06 aprile 2013 00:39:19 = GMT+02:00
A: Peter Saint-Andre <stpeter@stpeter.im>

Hi = Peter,

thank you for raising such an interesting = discussion. This reminds me of a specific thread dedicated to policies = and roles inside XCON, back in 2007. I expressed my personal view on = this subject in a (long) e-mail (h= ttp://www.ietf.org/mail-archive/web/xcon/current/msg01919.html) y= ou might want to have a look at. As you mention in your e-mail "future = policy documents" have not been = published.

Cheers,

Simon=


Il giorno 04/apr/2013, alle ore = 16:42, Peter Saint-Andre ha scritto:

FYI.


-------- Original Message = --------
Subject: [dispatch] conference roles
Date: Wed, 03 Apr = 2013 19:56:01 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
To: = DISPATCH <dispatch@ietf.org>

RFC = 4575 (Section 5.6.3) defines the concept of a role in a
conference, = but does not specify or define any roles.

5.6.3. = <roles>

  This element MAY contain a set of = human-readable strings describing
  the roles of the user = in the conference.  Note that this information
  is = applicable for human consumption only.  This specification does
=   not define the set of possible conferencing roles or the = semantics
  associated with each.  It is expected = that future conferencing
  specifications will define = these and the corresponding schema
  extensions, as = appropriate.

RFC 6501 (Section 4.6.5.2) specifies a few values = for the role
element, but does not actually define what those values = mean.

4.6.5.2. <roles>

  A <role> = provides the context for the set of conference operations
=   that a participant can perform.  This element can = contain one or more
  of the following values: = "administrator", "moderator", "user",
  "participant", = "observer", and "none".  A role of "none" indicates
=   that any role is assigned.  The <roles> semantic = definition is out of
  the scope of this document and is = subject to future policy documents.
  This element can be = extended with new roles in future documents.

(As far as I know, = those "future policy documents" have not been
published.)

More = recently, draft-groves-clue-capture-attr specifies several
additional = roles: "manager", "chairman", "secretary", "lecturer", and
"audience" = (so-called person roles) as well as "speaker" and
"controller" = (so-called conference roles). Personally, I happen to
have an = interest in defining a few other roles, such as "host",
"presenter", = "scribe", and "panelist".

Unfortunately there's quite a bit of = overlap and confusion here. For
instance, one could argue that = "host", "manager", and "controller"
(perhaps even "chairman") are the = same as or very similar to
"administrator" or "moderator" from RFC = 6501. There might also be
overlap between "lecturer", "speaker", and = "presenter" (and between
"speaker" and = "panelist").

Furthermore, I'm concerned that various = implementations will define
their own roles, blithely unaware that = very similar (or even identical
but differently named roles) are = already in use by other implementations.

It strikes me that one = solution here would be to establish an IANA
registry for conference = roles, with a registration policy (cf. RFC
5226) of at least Expert = Review and perhaps Specification Required (I
think RFC Required is a = bit heavy). IMHO this would help to prevent
continued confusion and = the minting of new roles that overlap with
existing = roles.

Thoughts?

Peter

______________________________= _________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dispatch


______________________________= _________________
clue mailing = list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/






=
      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_F8DF8A88-3E87-49AF-A658-7C7CB1DFBE1A-- From dromasca@avaya.com Sun Apr 7 01:20:43 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C9021F86C2 for ; Sun, 7 Apr 2013 01:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.496 X-Spam-Level: X-Spam-Status: No, score=-103.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrAJfIJq2EJ9 for ; Sun, 7 Apr 2013 01:20:42 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2518E21F86C3 for ; Sun, 7 Apr 2013 01:20:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFupNVGHCzI1/2dsb2JhbABEDoJYv26BBBZzgh8BAQEBAgEBAQEPKDEDEAcEAgEIDQEDBAEBAQoUCQcnCxQJCAIEAQkJCBqHawYBC6FKnRwEjlsmEgaCWWEDkwaJXopUgkk/gic X-IronPort-AV: E=Sophos;i="4.84,786,1355115600"; d="scan'208";a="4525515" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Apr 2013 04:20:23 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Apr 2013 04:17:50 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Sun, 7 Apr 2013 04:20:21 -0400 From: "Romascanu, Dan (Dan)" To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] SIP SNMP MIB and new transports Thread-Index: AQHOMXDYxqKdTITWyUCS2mrmv95O2JjIA9SAgAJlAtA= Date: Sun, 7 Apr 2013 08:20:20 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0C2E4F@AZ-FFEXMB04.global.avaya.com> References: <49D7A71B-6D88-42A1-AC8D-9CB300B077EE@edvina.net> <515EECF3.1080906@alum.mit.edu> In-Reply-To: <515EECF3.1080906@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] SIP SNMP MIB and new transports X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 08:20:43 -0000 Hi, > Is there some way to fix that, and link it to a > new IANA registry? Yes, there is a way. It involves updating RFC 4780 by placing the SipTCTran= sportProtocol under IANA change control. Actually it may be a good idea to = transfer all the TCs in the SIP MIB under the control of IANA, so that they= can be extended if and when there is a need to add new values to the enume= rations or bitmaps. Thus the TCs do become the registries. The IANA conside= rations policy section also needs to be updated in order to define the RFC = 5226 policy for updating the registries (for example ' Expert Review (or De= signated Expert))' It's not a horrendous task if it is focused on this specific change and the= impulse to make other updates to RFC 4780 is resisted.=20 Regards, Dan (Technical Advisor for the SIP WG when the SIP MIB was written) > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, April 05, 2013 6:26 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] SIP SNMP MIB and new transports >=20 > Olle, >=20 > On 4/5/13 4:12 AM, Olle E. Johansson wrote: > > Hi! > > > > RFC 4780 defines an OID for transports. If we add new transports > (websockets) we need to expand this table. The RFC in itself doesn't > outline a procedure for extending it. > > > > Should the draft for websockets transport extend the MIB? >=20 > It is too bad this wasn't raised sooner, e.g. during WGLC. > draft-ietf-sipcore-sip-websocket-08 is now with the editor, so it is > really too late to address this in that draft now. >=20 > So if something needs to be done about this then I guess it will require > a separate draft. >=20 > For the moment, ISTM the obvious work around is: >=20 > bit 0: a protocol other than those defined here >=20 > > In the Kamailio SNMP implementation, I have used bit 6 for ws and 7 > for wss. >=20 > I know *nothing* about mibs, but when looking at 4780 I don't see any > evidence that it was designed with a mechanism for extension as new > transports are defined. Is there some way to fix that, and link it to a > new IANA registry? >=20 > Thanks, > Paul >=20 > > /O > > > > ------ > > > > SipTCTransportProtocol ::=3D TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "This convention is a bit map. Each bit represents a > transport > > protocol. If a bit has value 1, then that selected transport > > protocol is in some way dependent on the context of the > object > > using this convention. If a bit has value 0, then that > > transport protocol is not selected. Combinations of bits can > > be set when multiple transport protocols are selected. > > > > bit 0: a protocol other than those defined here > > bit 1: User Datagram Protocol > > bit 2: Transmission Control Protocol > > bit 3: Stream Control Transmission Protocol > > bit 4: Transport Layer Security Protocol over TCP > > bit 5: Transport Layer Security Protocol over SCTP > > " > > REFERENCE " > > RFC 3261, Section 18 and RFC 4168 > > " > > SYNTAX BITS { > > other(0), -- none of the following > > udp(1), > > tcp(2), > > sctp(3), -- > > RFC4168 > > > > tlsTcp(4), > > tlsSctp(5) -- > > RFC 4168 > > > > } > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From saul@ag-projects.com Sun Apr 7 09:44:00 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E04E21F859D for ; Sun, 7 Apr 2013 09:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp04NhMBvcYk for ; Sun, 7 Apr 2013 09:44:00 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id D146E21F8585 for ; Sun, 7 Apr 2013 09:43:59 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id D5032B35E1; Sun, 7 Apr 2013 18:43:57 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 2F869B35DD; Sun, 7 Apr 2013 18:43:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <515E391A.3030800@stpeter.im> Date: Sun, 7 Apr 2013 18:43:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130405023718.11095.85523.idtracker@ietfa.amsl.com> <515E391A.3030800@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1085) Cc: DISPATCH Subject: Re: [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-im-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 16:44:00 -0000 Hi Peter, I did a quick read of this version, in section 4, shouldn't we be = looking at the RURI, instead of the To header? On Apr 5, 2013, at 4:38 AM, Peter Saint-Andre wrote: > FYI. >=20 >=20 > -------- Original Message -------- > Subject: I-D Action: draft-saintandre-sip-xmpp-im-03.txt > Date: Thu, 04 Apr 2013 19:37:18 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Interworking between the Session Initiation = Protocol > (SIP) and the Extensible Messaging and Presence Protocol (XMPP): = Instant > Messaging > Author(s) : Peter Saint-Andre > Avshalom Houri > Joe Hildebrand > Filename : draft-saintandre-sip-xmpp-im-03.txt > Pages : 10 > Date : 2013-04-04 >=20 > Abstract: > This document defines a bidirectional protocol mapping for the > exchange of single instant messages between the Session Initiation > Protocol (SIP) and the Extensible Messaging and Presence Protocol > (XMPP). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-im >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-im-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-saintandre-sip-xmpp-im-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Sun Apr 7 09:47:50 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7773A21F8615 for ; Sun, 7 Apr 2013 09:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hx93gv3E0WLA for ; Sun, 7 Apr 2013 09:47:50 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id BC50221F859D for ; Sun, 7 Apr 2013 09:47:49 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 11290B35E1; Sun, 7 Apr 2013 18:47:48 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 71C95B017C; Sun, 7 Apr 2013 18:47:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <515E40A6.90508@stpeter.im> Date: Sun, 7 Apr 2013 18:47:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <868045FC-9C51-4F7A-A061-DF04A6C3A2C4@ag-projects.com> References: <20130405030911.17780.89055.idtracker@ietfa.amsl.com> <515E40A6.90508@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1085) Cc: DISPATCH Subject: Re: [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-chat-05.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 16:47:50 -0000 Hi Peter, Are you planning to include mappings for MSRP REPORT chunks and XEP-0184 = delivery receipts? (not sure if I asked this earlier, I may have = forgotten). On Apr 5, 2013, at 5:10 AM, Peter Saint-Andre wrote: > FYI. >=20 >=20 > -------- Original Message -------- > Subject: I-D Action: draft-saintandre-sip-xmpp-chat-05.txt > Date: Thu, 04 Apr 2013 20:09:11 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Interworking between the Session Initiation = Protocol > (SIP) and the Extensible Messaging and Presence Protocol (XMPP): > One-to-One Text Chat > Author(s) : Peter Saint-Andre > Eddy Gavita > Nazin Hossain > Salvatore Loreto > Filename : draft-saintandre-sip-xmpp-chat-05.txt > Pages : 12 > Date : 2013-04-04 >=20 > Abstract: > This document defines a bidirectional protocol mapping for the > exchange of instant messages in the context of a one-to-one chat > session between a user of the Session Initiation Protocol (SIP) and = a > user of the Extensible Messaging and Presence Protocol (XMPP). > Specifically for SIP text chat, this document specifies a mapping to > the Message Session Relay Protocol (MSRP). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-chat >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-chat-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-saintandre-sip-xmpp-chat-05 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Sun Apr 7 10:44:32 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E01D21F86DE for ; Sun, 7 Apr 2013 10:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTQh7X25KAJx for ; Sun, 7 Apr 2013 10:44:31 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8080521F86BA for ; Sun, 7 Apr 2013 10:44:30 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id DD411B35E2; Sun, 7 Apr 2013 19:44:29 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 86FE8B017C; Sun, 7 Apr 2013 19:44:28 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <515BAA15.9050704@stpeter.im> Date: Sun, 7 Apr 2013 19:44:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <107B362C-9F29-4763-94D4-7823E3219C28@ag-projects.com> References: <20130403040257.13025.99948.idtracker@ietfa.amsl.com> <515BAA15.9050704@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1085) Cc: DISPATCH Subject: Re: [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-presence-05.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 17:44:32 -0000 Hi Peter, Here are some comments on revision 5: - Section 3.3.1: The initial SUBSCRIBE should have an empty to tag. - Section 4.3: Tuple id should be ID-orchard - Section 4.3, table 7: The reference to looks like a c&p error = ;-) I think we should make sue of the 'contact' child element of the PIDF = tuple to provide the full (translated as per the core draft) URI of the = presence entity. From/To headers cannot have GRUUs in them IIRC, so the = contact element seems like the right place to hold this piece of = information. This way the endpoint which processes this presence = information will learn how to contact *this* particular instance. In addition, the draft currently only considers the case where a single = NOTIFY is generated for a presence stanza, but if RLS is used a presence = agent will aggregate multiple PIDF documents in a single RLMI document = and send it in a single NOTIFY, so not relying in the =46rom header = would help. Regards, On Apr 3, 2013, at 6:03 AM, Peter Saint-Andre wrote: > FYI. >=20 >=20 > -------- Original Message -------- > Subject: I-D Action: draft-saintandre-sip-xmpp-presence-05.txt > Date: Tue, 02 Apr 2013 21:02:57 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Interworking between the Session Initiation = Protocol > (SIP) and the Extensible Messaging and Presence Protocol (XMPP): = Presence > Author(s) : Peter Saint-Andre > Avshalom Houri > Joe Hildebrand > Filename : draft-saintandre-sip-xmpp-presence-05.txt > Pages : 20 > Date : 2013-04-02 >=20 > 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). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-presence >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-presence-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-saintandre-sip-xmpp-presence-05= >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Sa=FAl Ibarra Corretg=E9 AG Projects From mary.ietf.barnes@gmail.com Sun Apr 7 11:32:10 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E35921F8AA8 for ; Sun, 7 Apr 2013 11:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.516 X-Spam-Level: X-Spam-Status: No, score=-103.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0sSR8GVG4Cr for ; Sun, 7 Apr 2013 11:32:09 -0700 (PDT) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 15D4121F8AA6 for ; Sun, 7 Apr 2013 11:32:09 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id q19so2735114qeb.26 for ; Sun, 07 Apr 2013 11:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=ga7HNJJC1ajhWgTyKTbReP2mTgNokYB9Dl4aJTpatgo=; b=JVy3z2Vbh6E/3m5a+FQfB4ltOXHEl8cNVSdP3+wNfLhVXZHwrBwM/7G3QqJpbHfw2Z KHzri+9mR7kvbNcCC7kk4qJoumnFUcB8Vs+TcPdTSxufJI20QtfZBvaPWeDIM5K3RA3v SaPiLDM7wAyYcVYGpUcRKWJEPUZ1vrfraAHmu8FbXcM2e+AL+loUKGSd9m8/+2TtI9V/ OB/GB9hIJhHTaMbqr/Zo/sayTilcOWUAh5qAfxCSzcKZKHnGU/2ImeCHRv2vUVGHRtPP 2WhjdraA5nx6Jz4vK3tbf7GJ67l2rm9n/ZvAszZIKPabg9ufBJc0S2jCaVwAAbhHwM/r 69oQ== MIME-Version: 1.0 X-Received: by 10.229.137.211 with SMTP id x19mr2072934qct.108.1365359528380; Sun, 07 Apr 2013 11:32:08 -0700 (PDT) Received: by 10.49.94.166 with HTTP; Sun, 7 Apr 2013 11:32:08 -0700 (PDT) In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047E386E@xmb-aln-x08.cisco.com> References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <004301ce2e30$2317e700$6947b500$@co.in> <001201ce2efc$0695a5f0$13c0f1d0$@co.in> <003601ce3088$618e3c00$24aab400$@co.in> <515C98AC.7020600@alum.mit.edu> <20130403235821.12f4e8a4@rainpc> <20130404081830.6a01c45d@rainpc> <92B7E61ADAC1BB4F941F943788C08828047E386E@xmb-aln-x08.cisco.com> Date: Sun, 7 Apr 2013 13:32:08 -0500 Message-ID: From: Mary Barnes To: "Charles Eckel (eckelcu)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 18:32:10 -0000 On Fri, Apr 5, 2013 at 5:09 PM, Charles Eckel (eckelcu) wrote: >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Lorenzo Miniero >> Sent: Wednesday, April 03, 2013 11:19 PM >> To: Victor Pascual Avila >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocke= t >> >> On Thu, 4 Apr 2013 07:40:03 +0200 >> Victor Pascual Avila wrote: >> >> > On Wed, Apr 3, 2013 at 11:58 PM, Lorenzo Miniero >> wrote: >> > > That said, though, I may have this view because of how, just as you,= I'm >> currently associating BFCP with the conferencing world (well, it was bor= n in >> XCON after all), which may be a wrong assumption: people may be using >> BFCP for entirely different scenarios as well, and the example made by >> someone a few posts ago (I think it was Victor but I may be wrong) about >> one of two peers acting as the floor control server in a call may be a >> perfectly valid scenario for it being used differently than what I'm use= d to. >> > >> > It was not me -- all my use cases include a conf server. On the client >> > side, we have WebRTC and non-WebRTC web endpoints (all of them >> > supporting WebSockets already) as well as "legacy" BFCP devices. >> > >> > Cheers, >> > -Victor >> >> >> Ops you're right, sorry about that! As they say here in Napoli, "that's = how >> you send people to jail" :-) >> >> I just checked the archives and it was Charles Eckel that referred to th= e >> possibility in a couple of posts. > > Yes, and I still stand by BFCP being useful and implemented for point to = point and peer to peer use cases, not just for conference calls between a c= lient and a conference server. If you want additional details, please have = a look at the following IMTC Best Practice shared with the IETF through a l= iaison statement last year: > https://datatracker.ietf.org/documents/LIAISON/liaison-2012-05-31-imtc-th= e-ietf-imtc-work-on-sip-feature-parity-with-h323-attachment-3.pdf > > That said, I am not saying BFCP over websockets is a bad idea. Rather, I = am saying it is not sufficient for all the use cases for which BFCP is used= today. Perhaps that is okay, and we just need to define something else for= the other use cases, and applications need to know when to use one method = as opposed to another. This adds complexity other than that of implementing= BFCP over websockets. [MB] Right. I don't think anyone's suggesting BFCP over websockets would subsume other usages. We have different application environments that need some of the same building blocks, but the flexibility in "transports" is a good thing IMHO. [/MB] > > Cheers, > Charles > >> Cheers, >> Lorenzo >> >> -- >> Lorenzo Miniero, COB >> >> Meetecho s.r.l. >> Web Conferencing and Collaboration Tools >> http://www.meetecho.com >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From gsalguei@cisco.com Sun Apr 7 13:25:16 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E241C21F8ECB for ; Sun, 7 Apr 2013 13:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkVQMdN2yJfw for ; Sun, 7 Apr 2013 13:25:16 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7863321F8EE6 for ; Sun, 7 Apr 2013 13:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1639; q=dns/txt; s=iport; t=1365366314; x=1366575914; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3iGtn8lZcVrwEM4FRapm4UAe5fiX+CnC0PgeEKz9nEo=; b=I4+HO2vVqL13bgSXXYIILC/yZpKWqfUFy8hyDAAjadiiej2TANrh4LT6 tNWKcmMGdLgKiFebnJNK6opkce9pNp1MV9MTUCyXUpGNjfUs46t6SznPz JtadBOEHmr+NRQmC8uRvMCIZBSye219ZfisQadAhOWHFIzjV2MTsvUwOC Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAMbVYVGtJXG//2dsb2JhbABRgwY2wSSBAhZ0gh8BAQECAQE6LhEQAgEINhAhESUCBA4FG4dnAwkGDLNHDYlZBIxQgiAzB4JgYQOVE4Fhi3OFG4ML X-IronPort-AV: E=Sophos;i="4.87,426,1363132800"; d="scan'208";a="196046557" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 07 Apr 2013 20:25:14 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r37KPDHP003986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Apr 2013 20:25:13 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.60]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Sun, 7 Apr 2013 15:25:13 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Mary Barnes Thread-Topic: [dispatch] Use of BFCP or MSRP over datachannel or websocket Thread-Index: AQHOM75EZYNQxCKQpECoMrHnIZ8oyZjLNIbo Date: Sun, 7 Apr 2013 20:25:12 +0000 Message-ID: <1B5F7E07-2C42-437C-9855-C734D930B0E2@cisco.com> References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <004301ce2e30$2317e700$6947b500$@co.in> <001201ce2efc$0695a5f0$13c0f1d0$@co.in> <003601ce3088$618e3c00$24aab400$@co.in> <515C98AC.7020600@alum.mit.edu> <20130403235821.12f4e8a4@rainpc> <20130404081830.6a01c45d@rainpc> <92B7E61ADAC1BB4F941F943788C08828047E386E@xmb-aln-x08.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 20:25:17 -0000 On Apr 7, 2013, at 2:32 PM, "Mary Barnes" wrot= e: >> Yes, and I still stand by BFCP being useful and implemented for point to= point and peer to peer use cases, not just for conference calls between a = client and a conference server. If you want additional details, please have= a look at the following IMTC Best Practice shared with the IETF through a = liaison statement last year: >> https://datatracker.ietf.org/documents/LIAISON/liaison-2012-05-31-imtc-t= he-ietf-imtc-work-on-sip-feature-parity-with-h323-attachment-3.pdf >>=20 >> That said, I am not saying BFCP over websockets is a bad idea. Rather, I= am saying it is not sufficient for all the use cases for which BFCP is use= d today. Perhaps that is okay, and we just need to define something else fo= r the other use cases, and applications need to know when to use one method= as opposed to another. This adds complexity other than that of implementin= g BFCP over websockets. > [MB] Right. I don't think anyone's suggesting BFCP over websockets > would subsume other usages. We have different application > environments that need some of the same building blocks, but the > flexibility in "transports" is a good thing IMHO. [/MB] This is pretty much my same feeling on this. There are customer use cases,= proven instances where it is the superior solution, and it plays nicely wi= th legacy implementations. I see no reason not to pursue this, despite any= (IMO grossly overestimated) perceived additional complexity introduced as = a result of an additional transport choice. Gonzalo= From stpeter@stpeter.im Sun Apr 7 15:15:28 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2844F21F8A4F for ; Sun, 7 Apr 2013 15:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyrE0nPgbI-X for ; Sun, 7 Apr 2013 15:15:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE5021F85D9 for ; Sun, 7 Apr 2013 15:15:27 -0700 (PDT) Received: from [192.168.1.4] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AFD474004E for ; Sun, 7 Apr 2013 16:25:25 -0600 (MDT) Message-ID: <5161F005.9070203@stpeter.im> Date: Sun, 07 Apr 2013 16:15:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: DISPATCH References: <20130407221345.16413.81856.idtracker@ietfa.amsl.com> In-Reply-To: <20130407221345.16413.81856.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130407221345.16413.81856.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dispatch] Fwd: I-D Action: draft-saintandre-impp-call-info-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 22:15:28 -0000 FYI. -------- Original Message -------- Subject: I-D Action: draft-saintandre-impp-call-info-01.txt Date: Sun, 07 Apr 2013 15:13:45 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Instant Messaging and Presence Purpose for the Call-Info Header in the Session Initiation Protocol (SIP) Author(s) : Peter Saint-Andre Filename : draft-saintandre-impp-call-info-01.txt Pages : 4 Date : 2013-04-07 Abstract: This document defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-saintandre-impp-call-info There's also a htmlized version available at: http://tools.ietf.org/html/draft-saintandre-impp-call-info-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-saintandre-impp-call-info-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Christian.Groves@nteczone.com Sun Apr 7 22:43:35 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E2E21F91CA for ; Sun, 7 Apr 2013 22:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7cPQycZiTFr for ; Sun, 7 Apr 2013 22:43:34 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 8193421F91D6 for ; Sun, 7 Apr 2013 22:43:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAE5YYlF20S1b/2dsb2JhbAANRIM8wSWBG4MTAQEBBAEBATUbFQMDCg0ECxEDAQIBCRYPCQMCAQIBFSgIEwYCAQEXiAWqCZJTBI8YEgaDOwOrHw Received: from ppp118-209-45-91.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.45.91]) by ipmail07.adl2.internode.on.net with ESMTP; 08 Apr 2013 15:13:31 +0930 Message-ID: <51625901.2070709@nteczone.com> Date: Mon, 08 Apr 2013 15:43:29 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <515CDDB1.2010809@stpeter.im> <515D9165.7@stpeter.im> <5162583A.1010807@nteczone.com> In-Reply-To: <5162583A.1010807@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] [clue] Fwd: conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 05:43:35 -0000 Perhaps I should have kept this on the dispatch list? Christian On 8/04/2013 3:40 PM, Christian Groves wrote: > Hello Peter, > > I had envisaged that from the CLUE perspective that an IANA registry > would be establish for Role (and some of the attributes). I'm not sure > that it is possible to harmonise RFC4575, RFC6501 and CLUE as I think > they have different semantics. > > RFC4575 seems just to have a free text field that's human readable. > The goal of the CLUE "role" attribute is to have a set of tags which > are human readable and able to used in an automatic way. > > RFC6501 talks about "conference operations that a participant can > perform" I think this is semantically different to what is being > proposed in CLUE which is more about the person/s in a capture (i.e. > those depicted in the RTP stream). > > If it helps lessen the confusion we could change the name of the CLUE > parameter from "role" to "Character", "Captured Persons" or "Person > represented by media", etc.? With the semantic that the media contains > a person who is acting in that character/role. > > I think part of the challenge will be to define the values. A person > can have multiple roles/characters, e.g. a chairman who is acting as a > scribe. Some have a similar function but have a different connotation > e.g. presenter versus lecturer. I think to move forward we need to > address these sorts of things. The previous RFCs seem to have largely > ignored the problem in the final text. I'm not implying that it wasn't > considered in their development. > > Regards, Christian > > On 5/04/2013 1:42 AM, Peter Saint-Andre wrote: >> FYI. >> >> >> -------- Original Message -------- >> Subject: [dispatch] conference roles >> Date: Wed, 03 Apr 2013 19:56:01 -0600 >> From: Peter Saint-Andre >> To: DISPATCH >> >> RFC 4575 (Section 5.6.3) defines the concept of a role in a >> conference, but does not specify or define any roles. >> >> 5.6.3. >> >> This element MAY contain a set of human-readable strings describing >> the roles of the user in the conference. Note that this information >> is applicable for human consumption only. This specification does >> not define the set of possible conferencing roles or the semantics >> associated with each. It is expected that future conferencing >> specifications will define these and the corresponding schema >> extensions, as appropriate. >> >> RFC 6501 (Section 4.6.5.2) specifies a few values for the role >> element, but does not actually define what those values mean. >> >> 4.6.5.2. >> >> A provides the context for the set of conference operations >> that a participant can perform. This element can contain one or >> more >> of the following values: "administrator", "moderator", "user", >> "participant", "observer", and "none". A role of "none" indicates >> that any role is assigned. The semantic definition is >> out of >> the scope of this document and is subject to future policy >> documents. >> This element can be extended with new roles in future documents. >> >> (As far as I know, those "future policy documents" have not been >> published.) >> >> More recently, draft-groves-clue-capture-attr specifies several >> additional roles: "manager", "chairman", "secretary", "lecturer", and >> "audience" (so-called person roles) as well as "speaker" and >> "controller" (so-called conference roles). Personally, I happen to >> have an interest in defining a few other roles, such as "host", >> "presenter", "scribe", and "panelist". >> >> Unfortunately there's quite a bit of overlap and confusion here. For >> instance, one could argue that "host", "manager", and "controller" >> (perhaps even "chairman") are the same as or very similar to >> "administrator" or "moderator" from RFC 6501. There might also be >> overlap between "lecturer", "speaker", and "presenter" (and between >> "speaker" and "panelist"). >> >> Furthermore, I'm concerned that various implementations will define >> their own roles, blithely unaware that very similar (or even identical >> but differently named roles) are already in use by other >> implementations. >> >> It strikes me that one solution here would be to establish an IANA >> registry for conference roles, with a registration policy (cf. RFC >> 5226) of at least Expert Review and perhaps Specification Required (I >> think RFC Required is a bit heavy). IMHO this would help to prevent >> continued confusion and the minting of new roles that overlap with >> existing roles. >> >> Thoughts? >> >> Peter >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > From Markus.Isomaki@nokia.com Mon Apr 8 03:47:33 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173DA21F9380 for ; Mon, 8 Apr 2013 03:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ERjz334bTUB for ; Mon, 8 Apr 2013 03:47:32 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 608EB21F936E for ; Mon, 8 Apr 2013 03:47:32 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r38AlSYe009815; Mon, 8 Apr 2013 13:47:29 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Apr 2013 13:47:28 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.193]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0328.011; Mon, 8 Apr 2013 10:47:27 +0000 From: To: , Thread-Topic: [dispatch] Acronym for the SIP-XMPP effort Thread-Index: AQHOMcSr6x4nnLFyJkqNuTZyx616zZjMJZkQ Date: Mon, 8 Apr 2013 10:47:27 +0000 Message-ID: References: <515E6B74.5030506@ericsson.com> In-Reply-To: <515E6B74.5030506@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IgHA4421zI8AMsjp2kpc/dzDyIh6mI1rcnP+iXDE/tZSbmDKVwW9MBCAGbPj1IR8iBsgIjoPBHYrrELDOfwc6y6SeKhk+/TpaiFLJE++Opg5SrSBtFZyP5KEsDhACGHffAN5DfgWQxtNQRbeQgsT/NfNbE77aa/OfzGoJZAWNrdkriaIb1ymHZbmUnf/vewuzGwN0pD0Aam/guLqeTe2pfWksvEFgthrk//3tQJfv/k8 x-originating-ip: [172.21.81.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Apr 2013 10:47:28.0171 (UTC) FILETIME=[768E37B0:01CE3446] X-Nokia-AV: Clean Subject: Re: [dispatch] Acronym for the SIP-XMPP effort X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 10:47:33 -0000 Hi Gonzalo, SIXPAC was the name of an earlier proposal to charter a WG about combined u= se of SIP and XMPP at the endpoint. It never made it to a real WG, but some= thing similar still exists in the form of the CUSAX proposal (http://datatr= acker.ietf.org/doc/draft-ivov-xmpp-cusax/).=20 Since this effort we are now chartering is about translation/mapping/gatewa= ying between SIP and XMPP, it may be best to use a different name for it to= avoid confusion with the combined usage work.=20 Markus -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of ext Gonzalo Camarillo Sent: 05 April, 2013 09:13 To: DISPATCH Subject: [dispatch] Acronym for the SIP-XMPP effort Folks, I am going to handle the chartering of the SIP-XMPP effort, as discussed in= Orlando. As usual, we need to choose an acronym for the group. Among the a= cronyms I have heard, I like this one best so far: SIXPAC - SIP Integration with XMPP in Presence Aware Contexts While, per the RAI tradition, it refers to an alcoholic drink, usually beer= s, it also refers to the nice six packs all RAI contributors are working on= during the spring in order to show off at the beach in summer :-) Any other suggestions? With respect to the chairs for this effort, we will be choosing them soon a= s well. So, if you are interested but have not volunteered yet per my other= email (from yesterday), now it would be a great time to drop me a note. Thanks, Gonzalo _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From rifatyu@avaya.com Mon Apr 8 06:41:19 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF91421F888C for ; Mon, 8 Apr 2013 06:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAe6I6VQRk8n for ; Mon, 8 Apr 2013 06:41:19 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id EA61B21F8BF4 for ; Mon, 8 Apr 2013 06:41:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHpXMFHGmAcF/2dsb2JhbABEgkMjv05/FnOCIQEBAxIbTBIBFRVWJgEEDg0ah3EBpGGcQ45jMYJmYQOcWopRgwiCJw X-IronPort-AV: E=Sophos;i="4.84,760,1355115600"; d="scan'208,217";a="6020728" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 08 Apr 2013 09:41:17 -0400 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 08 Apr 2013 09:38:36 -0400 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.02.0328.009; Mon, 8 Apr 2013 09:41:16 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "dispatch@ietf.org" Thread-Topic: [dispatch] draft-saintandre-sip-xmpp-media-02 Thread-Index: Ac40Xr3iC86x6GTlQG6vxQi2/vjAOQ== Date: Mon, 8 Apr 2013 13:41:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.48] Content-Type: multipart/alternative; boundary="_000_C563F76EA324474CA3722A35154AFDB3139FC976AZUS1EXMB01glob_" MIME-Version: 1.0 Subject: [dispatch] draft-saintandre-sip-xmpp-media-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 13:41:20 -0000 --_000_C563F76EA324474CA3722A35154AFDB3139FC976AZUS1EXMB01glob_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, I did a quick review for the sip-xmpp-media-02 document and have the follow= ing comments/questions: Section 2.1, bullet 3: This bullet states "The SIP signaling channel is transported over UDP, ..."= . While SIP can be transported over UDP, it is also widely transported over= TCP and TLS. You may want to reword this sentence and clarify that stateme= nt. Section 2.2.1, Jingle Action to SIP Method mapping table: content-accept, session-accept: I think that the SIP part should be "INVITE= response (18x)" instead of "... (1xx)" content-add, content-modify, content-remove: how about UPDATE? Section 2.3.1, first jingle, you have two "from" attributes; I think that the second one should be the "= to" attribute instead. Section 2.3.1, the SDP in the first INVITE sent from the GW to the target, = the m line should include the codecs offered by this SDP. Section 2.3.1., 180 Ringing, The "To" header seems to include a tag with the same value as of the resour= ce of the "to" attribute in the Jingle session-initiation. It is likely that these values will be different, and it would be up to the= GW to map these values. General comments: * This document seems to assume that the user part of the SIP id and XMPP i= d is the same. I understand that this document is trying to address the media mapping, but= is there any document that deals with the mapping of ids, and does it addr= ess the use case of a user having different user parts for his SIP and XMPP= ids? * A SIP INVITE could be forked and multiple responses sent to the originato= r. Are you going to cover this use case? does this change the mapping table= ? Regards, Rifaat --_000_C563F76EA324474CA3722A35154AFDB3139FC976AZUS1EXMB01glob_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter,

 

I did a quick review for the sip-xmpp-media-02 docum= ent and have the following comments/questions:

 

Section 2.1, bullet 3:

This bullet states "The SIP signaling channel i= s transported over UDP, ...". While SIP can be transported over UDP, i= t is also widely transported over TCP and TLS. You may want to reword this = sentence and clarify that statement.

 

Section 2.2.1, Jingle Action to SIP Method mapping t= able:

content-accept, session-accept: I think that the SIP= part should be "INVITE response (18x)" instead of "... (1xx= )"

content-add, content-modify, content-remove: how abo= ut UPDATE?

 

Section 2.3.1, first jingle,

you have two "from" attributes; I think th= at the second one should be the "to" attribute instead.

 

Section 2.3.1, the SDP in the first INVITE sent from= the GW to the target, the m line should include the codecs offered by this= SDP.

 

Section 2.3.1., 180 Ringing,

The "To" header seems to include a tag wit= h the same value as of the resource of the "to" attribute in the = Jingle session-initiation.

It is likely that these values will be different, an= d it would be up to the GW to map these values.

 

General comments:

* This document seems to assume that the user part o= f the SIP id and XMPP id is the same.

I understand that this document is trying to address= the media mapping, but is there any document that deals with the mapping o= f ids, and does it address the use case of a user having different user par= ts for his SIP and XMPP ids?

* A SIP INVITE could be forked and multiple response= s sent to the originator. Are you going to cover this use case? does this c= hange the mapping table?

 

 

Regards,

Rifaat

 

--_000_C563F76EA324474CA3722A35154AFDB3139FC976AZUS1EXMB01glob_-- From info@vonniman.com Mon Apr 8 07:37:40 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E782B21F97D8 for ; Mon, 8 Apr 2013 07:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbVN6vBtAyHj for ; Mon, 8 Apr 2013 07:37:40 -0700 (PDT) Received: from mail1.ms.forss.net (mail2.ms.forss.net [95.128.113.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4C94521F97D7 for ; Mon, 8 Apr 2013 07:37:40 -0700 (PDT) Received: from [192.168.1.88] (c-76e1e155.315-1-64736c11.cust.bredbandsbolaget.se [85.225.225.118]) (Authenticated sender: info) by mail1.ms.forss.net (Postfix) with ESMTPSA id A10772005A; Mon, 8 Apr 2013 16:37:36 +0200 (CEST) User-Agent: Microsoft-MacOutlook/14.3.2.130206 Date: Mon, 08 Apr 2013 16:40:23 +0200 From: "info@vonniman.com" To: , , Message-ID: Thread-Topic: [dispatch] Acronym for the SIP-XMPP effort In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [dispatch] Acronym for the SIP-XMPP effort X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 14:37:41 -0000 SIXPACK+1 DOUBLE-SIXPACK A hard choice... /Bruno On 08/04/13 12:47, "Markus.Isomaki@nokia.com" wrote: >Hi Gonzalo, > >SIXPAC was the name of an earlier proposal to charter a WG about combined >use of SIP and XMPP at the endpoint. It never made it to a real WG, but >something similar still exists in the form of the CUSAX proposal >(http://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/). > >Since this effort we are now chartering is about >translation/mapping/gatewaying between SIP and XMPP, it may be best to >use a different name for it to avoid confusion with the combined usage >work. > >Markus > > >-----Original Message----- >From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >Behalf Of ext Gonzalo Camarillo >Sent: 05 April, 2013 09:13 >To: DISPATCH >Subject: [dispatch] Acronym for the SIP-XMPP effort > >Folks, > >I am going to handle the chartering of the SIP-XMPP effort, as discussed >in Orlando. As usual, we need to choose an acronym for the group. Among >the acronyms I have heard, I like this one best so far: > > SIXPAC - SIP Integration with XMPP in Presence Aware Contexts > >While, per the RAI tradition, it refers to an alcoholic drink, usually >beers, it also refers to the nice six packs all RAI contributors are >working on during the spring in order to show off at the beach in summer >:-) > >Any other suggestions? > >With respect to the chairs for this effort, we will be choosing them soon >as well. So, if you are interested but have not volunteered yet per my >other email (from yesterday), now it would be a great time to drop me a >note. > >Thanks, > >Gonzalo >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From stpeter@stpeter.im Mon Apr 8 10:27:44 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603F821F9797 for ; Mon, 8 Apr 2013 10:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kud-Um9o5kis for ; Mon, 8 Apr 2013 10:27:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D21EB21F9779 for ; Mon, 8 Apr 2013 10:27:43 -0700 (PDT) Received: from [10.129.24.115] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4B1CA4004E; Mon, 8 Apr 2013 11:37:44 -0600 (MDT) Message-ID: <5162FE13.6000107@stpeter.im> Date: Mon, 08 Apr 2013 11:27:47 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-saintandre-sip-xmpp-media-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 17:27:44 -0000 On 4/8/13 7:41 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > I did a quick review for the sip-xmpp-media-02 document and have the following comments/questions: Thanks, Rifaat! This document still needs quite a bit of work. Saúl Ibarra and I are working to update draft-saintandre-sip-xmpp-groupchat first, but we'll move on to draft-saintandre-sip-xmpp-media after that. I'll reply to your message in more detail later this week. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Apr 8 10:50:10 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741FD21F91A5 for ; Mon, 8 Apr 2013 10:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYrWdPBF0F+A for ; Mon, 8 Apr 2013 10:50:08 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9692E21F919A for ; Mon, 8 Apr 2013 10:50:08 -0700 (PDT) Received: from [10.129.24.115] (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B74934004E; Mon, 8 Apr 2013 12:00:04 -0600 (MDT) Message-ID: <5163034F.9000801@stpeter.im> Date: Mon, 08 Apr 2013 11:50:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christian Groves References: <515CDDB1.2010809@stpeter.im> <515D9165.7@stpeter.im> <5162583A.1010807@nteczone.com> <51625901.2070709@nteczone.com> In-Reply-To: <51625901.2070709@nteczone.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] [clue] Fwd: conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 17:50:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/7/13 11:43 PM, Christian Groves wrote: > Perhaps I should have kept this on the dispatch list? Perhaps. At the least, it would be good to have one place to talk about this topic. > On 8/04/2013 3:40 PM, Christian Groves wrote: >> Hello Peter, >> >> I had envisaged that from the CLUE perspective that an IANA >> registry would be establish for Role (and some of the >> attributes). I'm not sure that it is possible to harmonise >> RFC4575, RFC6501 and CLUE as I think they have different >> semantics. >> >> RFC4575 seems just to have a free text field that's human >> readable. The goal of the CLUE "role" attribute is to have a set >> of tags which are human readable and able to used in an automatic >> way. >> >> RFC6501 talks about "conference operations that a participant >> can perform" I think this is semantically different to what is >> being proposed in CLUE which is more about the person/s in a >> capture (i.e. those depicted in the RTP stream). >> >> If it helps lessen the confusion we could change the name of the >> CLUE parameter from "role" to "Character", "Captured Persons" or >> "Person represented by media", etc.? With the semantic that the >> media contains a person who is acting in that character/role. Apparently I got confused by the use of the term "role" in draft-groves-clue-capture-attr because to me it seems like an extension to the roles defined in RFC 6501, which provided some new values for the same construct defined in RFC 4575. What you're saying is that the CLUE roles proposed in draft-groves-clue-capture-attr are actually a completely different construct. That is, RFC 4575 and RFC 6501 define roles as essentially bundles of permissions to perform certain operations, whereas the roles / characters in draft-groves-clue-capture-attr have nothing to do with conference control. Correct? >> I think part of the challenge will be to define the values. A >> person can have multiple roles/characters, e.g. a chairman who is >> acting as a scribe. Some have a similar function but have a >> different connotation e.g. presenter versus lecturer. I think to >> move forward we need to address these sorts of things. The >> previous RFCs seem to have largely ignored the problem in the >> final text. Agreed. Just FYI, in the XMPP community we had thought about the concept of "hats", which are roles you can play in a conference (and you can play multiple roles, just as you can wear different hats). We have a very basic spec for hats here: http://xmpp.org/extensions/xep-0317.html Rather than continuing to pursue the hats idea, I've been thinking that it might be better to settle on using conference-info syntax from RFC 4575 (since that would improve interoperability across SIP systems and XMPP systems -- there's nothing SIP-specific about conference-info itself). Unfortunately, it appears that the conference-info syntax is clear but the semantics are not. I'm happy to put some cycles into clarifying the semantics if there's interest. (Now it seems that is a separate topic from the CLUE work, since CLUE isn't actually using the RFC 4575 construct. So discussing this on the DISPATCH list seems correct.) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRYwNPAAoJEOoGpJErxa2p7b4P/1mWKSutcNRB7Zocwj4bFj43 uYol1z/HSFBCPxLtqgVUL8EVifEImmf0aanMsX1+kgz/YMnpPNef5vISSL2GpQXW zWEUdZQ5CJInPXkkKY4kxmFLtqs4HBHBjjJiUjb99qFv++qgmNA0gTx5qEKfV5d4 O1CR/ua6iZRj2W78srt4zln3GQbdbkOUqVkAkf/SoNvggSdMwEkI/ZDx34x7hCdP S2bn4tAcsRMFhLKiPPY0+oV4FRQ6/R4LE278dwmt2eqFQREJOMLiNOn2f3G5Bcr2 P+f0nH22b2Nyd3KKQfvX34BiQebxRZ3VS+WrUJqofwz37/WL3CyoLOh9r+GSGrBJ y1ch18d28G/DbMOJQhYn41U0447A+mb0Q4VnuwB/YAeRn/DoXI0Y478slrJIkyXs pruktAusj4uhdCnTD5noBI3+4aGj7PNJIAWBCCb/EEGPOrQNnUDWoup345nxHZoK /SzXSaz+guiQsb/heOGCQYH+q9E25n0UWMgKBAiVGQ1O6/Bc/FLemnryRr6WDfVV qCofoU1wRbe2CS73LTnrH6+MeWY63Cjkv3jyTzzhuVdJIt1nopRwQMJvHWV48rii DHrBNZA1aweJhPLtjtSzNb1bxg1g0swRMpCnyfDNML4Je5h9mp3+M2+S8mZc8ssm qnM8GsRfyErV2pI505Fc =n3og -----END PGP SIGNATURE----- From rlb@ipv.sx Mon Apr 8 12:38:57 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A902421F85A1 for ; Mon, 8 Apr 2013 12:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vVEfvAQO0w1 for ; Mon, 8 Apr 2013 12:38:57 -0700 (PDT) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id E78DE21F85A2 for ; Mon, 8 Apr 2013 12:38:56 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id o17so6528615oag.6 for ; Mon, 08 Apr 2013 12:38:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=hd9/gJ/ICrrG6V0viADgCfnje6AjNTt720nol1KHvZ8=; b=iH+fo8GbEmXNKyQ3L4qFxRvm5XYGLQ2j2aqVAwYEt4A95kXdy75XqIJwpkNH7UY9n9 4xKjZ76RutpMuWGE9SgaLBHMHIyje5RyyekrZmYEDlQJoQXK2DNUSaeOxqfU5CaB8IbW 1A5hhf8F2Fh0CMLavH/obuQKtE7SHyyPs1XZNxK1Pt+WahYm3ovdmLStLoU8yiooyjx8 7e+MjaQKVlshUeUqax77bDlsdWae5HNt0QErqRv5zQ0dPxhBv343SKE4Lu+Dfxxec4Zo 7lVDAS6uMPzbHJkQykk7iagyuoLB9RgPxcoGBhXwn67qsu1l6GnwApAvkYelWkprADVf S5aQ== MIME-Version: 1.0 X-Received: by 10.60.34.98 with SMTP id y2mr11713147oei.74.1365449936397; Mon, 08 Apr 2013 12:38:56 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 8 Apr 2013 12:38:56 -0700 (PDT) X-Originating-IP: [108.18.40.68] In-Reply-To: References: <515E6B74.5030506@ericsson.com> Date: Mon, 8 Apr 2013 15:38:56 -0400 Message-ID: From: Richard Barnes To: Markus.Isomaki@nokia.com Content-Type: multipart/alternative; boundary=089e01175d076b391c04d9de9691 X-Gm-Message-State: ALoCoQmmF3CFhWQbUx9bdCNRnIIBUatbcjLY4RruYxDs8sm32rp6Cujm57Fst1+5EMz6EKx+UTyv Cc: dispatch@ietf.org Subject: Re: [dispatch] Acronym for the SIP-XMPP effort X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 19:38:57 -0000 --089e01175d076b391c04d9de9691 Content-Type: text/plain; charset=ISO-8859-1 STOX - SIP-to-XMPP? On Mon, Apr 8, 2013 at 6:47 AM, wrote: > Hi Gonzalo, > > SIXPAC was the name of an earlier proposal to charter a WG about combined > use of SIP and XMPP at the endpoint. It never made it to a real WG, but > something similar still exists in the form of the CUSAX proposal ( > http://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/). > > Since this effort we are now chartering is about > translation/mapping/gatewaying between SIP and XMPP, it may be best to use > a different name for it to avoid confusion with the combined usage work. > > Markus > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of ext Gonzalo Camarillo > Sent: 05 April, 2013 09:13 > To: DISPATCH > Subject: [dispatch] Acronym for the SIP-XMPP effort > > Folks, > > I am going to handle the chartering of the SIP-XMPP effort, as discussed > in Orlando. As usual, we need to choose an acronym for the group. Among the > acronyms I have heard, I like this one best so far: > > SIXPAC - SIP Integration with XMPP in Presence Aware Contexts > > While, per the RAI tradition, it refers to an alcoholic drink, usually > beers, it also refers to the nice six packs all RAI contributors are > working on during the spring in order to show off at the beach in summer :-) > > Any other suggestions? > > With respect to the chairs for this effort, we will be choosing them soon > as well. So, if you are interested but have not volunteered yet per my > other email (from yesterday), now it would be a great time to drop me a > note. > > Thanks, > > Gonzalo > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --089e01175d076b391c04d9de9691 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable STOX - SIP-to-XMPP?



O= n Mon, Apr 8, 2013 at 6:47 AM, <Markus.Isomaki@nokia.com> wrote:
Hi Gonzalo,

SIXPAC was the name of an earlier proposal to charter a WG about combined u= se of SIP and XMPP at the endpoint. It never made it to a real WG, but some= thing similar still exists in the form of the CUSAX proposal (htt= p://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/).

Since this effort we are now chartering is about translation/mapping/gatewa= ying between SIP and XMPP, it may be best to use a different name for it to= avoid confusion with the combined usage work.

Markus


-----Original Message-----
From: dispatch-bounces@ietf.or= g [mailto:dispatch-bounces= @ietf.org] On Behalf Of ext Gonzalo Camarillo
Sent: 05 April, 2013 09:13
To: DISPATCH
Subject: [dispatch] Acronym for the SIP-XMPP effort

Folks,

I am going to handle the chartering of the SIP-XMPP effort, as discussed in= Orlando. As usual, we need to choose an acronym for the group. Among the a= cronyms I have heard, I like this one best so far:

=A0 SIXPAC - SIP Integration with XMPP in Presence Aware Contexts

While, per the RAI tradition, it refers to an alcoholic drink, usually beer= s, it also refers to the nice six packs all RAI contributors are working on= during the spring in order to show off at the beach in summer :-)

Any other suggestions?

With respect to the chairs for this effort, we will be choosing them soon a= s well. So, if you are interested but have not volunteered yet per my other= email (from yesterday), now it would be a great time to drop me a note.
Thanks,

Gonzalo
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--089e01175d076b391c04d9de9691-- From prvs=8037949ad=christou_chris@bah.com Mon Apr 8 12:50:47 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAE121F86C1 for ; Mon, 8 Apr 2013 12:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEC8GJCAqbvs for ; Mon, 8 Apr 2013 12:50:46 -0700 (PDT) Received: from mclniron02-ext.bah.com (mclniron02-ext.bah.com [128.229.5.22]) by ietfa.amsl.com (Postfix) with ESMTP id A1A6A21F8E63 for ; Mon, 8 Apr 2013 12:50:44 -0700 (PDT) x-SBRS: None X-REMOTE-IP: 10.12.10.201 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsFAJoeY1EKDArJ/2dsb2JhbABRgkJ6r0aJMQGIM4EhdIIfAQEBBAEBASpBCwwEAgEIDgMEAQELHQcnCxQJCAIEAQ0FCIgYvWiJC4RWgREGBxkHBAYBBoJaYQOTLIRpkniBczU X-IronPort-AV: E=Sophos;i="4.87,432,1363147200"; d="scan'208,217";a="482330895" Received: from ashbcshb02.resource.ds.bah.com ([10.12.10.201]) by mclniron02-int.bah.com with ESMTP; 08 Apr 2013 15:50:43 -0400 Received: from ASHBDAG1M1.resource.ds.bah.com ([169.254.1.69]) by ASHBCSHB02.resource.ds.bah.com ([10.12.10.201]) with mapi id 14.02.0342.004; Mon, 8 Apr 2013 15:50:43 -0400 From: "Christou, Christos [USA]" To: Richard Barnes , "Markus.Isomaki@nokia.com" Thread-Topic: [External] Re: [dispatch] Acronym for the SIP-XMPP effort Thread-Index: AQHONEaM30vuLJqJuEu/zLS3KR2O0pjM++sA///AN+A= Date: Mon, 8 Apr 2013 19:50:43 +0000 Message-ID: <462D69106F82344E95BC83996D8039D25A02059D@ASHBDAG1M1.resource.ds.bah.com> References: <515E6B74.5030506@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.5.20] Content-Type: multipart/alternative; boundary="_000_462D69106F82344E95BC83996D8039D25A02059DASHBDAG1M1resou_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] [External] Re: Acronym for the SIP-XMPP effort X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 19:50:47 -0000 --_000_462D69106F82344E95BC83996D8039D25A02059DASHBDAG1M1resou_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like it. From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Richard Barnes Sent: Monday, April 08, 2013 3:39 PM To: Markus.Isomaki@nokia.com Cc: dispatch@ietf.org Subject: [External] Re: [dispatch] Acronym for the SIP-XMPP effort STOX - SIP-to-XMPP? On Mon, Apr 8, 2013 at 6:47 AM, > wrote: Hi Gonzalo, SIXPAC was the name of an earlier proposal to charter a WG about combined u= se of SIP and XMPP at the endpoint. It never made it to a real WG, but some= thing similar still exists in the form of the CUSAX proposal (http://datatr= acker.ietf.org/doc/draft-ivov-xmpp-cusax/). Since this effort we are now chartering is about translation/mapping/gatewa= ying between SIP and XMPP, it may be best to use a different name for it to= avoid confusion with the combined usage work. Markus -----Original Message----- From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of ex= t Gonzalo Camarillo Sent: 05 April, 2013 09:13 To: DISPATCH Subject: [dispatch] Acronym for the SIP-XMPP effort Folks, I am going to handle the chartering of the SIP-XMPP effort, as discussed in= Orlando. As usual, we need to choose an acronym for the group. Among the a= cronyms I have heard, I like this one best so far: SIXPAC - SIP Integration with XMPP in Presence Aware Contexts While, per the RAI tradition, it refers to an alcoholic drink, usually beer= s, it also refers to the nice six packs all RAI contributors are working on= during the spring in order to show off at the beach in summer :-) Any other suggestions? With respect to the chairs for this effort, we will be choosing them soon a= s well. So, if you are interested but have not volunteered yet per my other= email (from yesterday), now it would be a great time to drop me a note. Thanks, Gonzalo _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_462D69106F82344E95BC83996D8039D25A02059DASHBDAG1M1resou_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I like it.

 <= /p>

From: dispatch= -bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, April 08, 2013 3:39 PM
To: Markus.Isomaki@nokia.com
Cc: dispatch@ietf.org
Subject: [External] Re: [dispatch] Acronym for the SIP-XMPP effort

 

STOX - SIP-to-XMPP?

 

 

On Mon, Apr 8, 2013 at 6:47 AM, <Markus.Isomaki@nokia.com&= gt; wrote:

Hi Gonzalo,

SIXPAC was the name of an earlier proposal to charter a WG about combined u= se of SIP and XMPP at the endpoint. It never made it to a real WG, but some= thing similar still exists in the form of the CUSAX proposal (htt= p://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/).

Since this effort we are now chartering is about translation/mapping/gatewa= ying between SIP and XMPP, it may be best to use a different name for it to= avoid confusion with the combined usage work.

Markus



-----Original Message-----
From: dispatch-bounces@ietf.or= g [mailto:dispatch-bounces= @ietf.org] On Behalf Of ext Gonzalo Camarillo
Sent: 05 April, 2013 09:13
To: DISPATCH
Subject: [dispatch] Acronym for the SIP-XMPP effort

Folks,

I am going to handle the chartering of the SIP-XMPP effort, as discussed in= Orlando. As usual, we need to choose an acronym for the group. Among the a= cronyms I have heard, I like this one best so far:

  SIXPAC - SIP Integration with XMPP in Presence Aware Contexts

While, per the RAI tradition, it refers to an alcoholic drink, usually beer= s, it also refers to the nice six packs all RAI contributors are working on= during the spring in order to show off at the beach in summer :-)

Any other suggestions?

With respect to the chairs for this effort, we will be choosing them soon a= s well. So, if you are interested but have not volunteered yet per my other= email (from yesterday), now it would be a great time to drop me a note.
Thanks,

Gonzalo
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 

--_000_462D69106F82344E95BC83996D8039D25A02059DASHBDAG1M1resou_-- From stpeter@stpeter.im Mon Apr 8 19:03:51 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447D721F84E9 for ; Mon, 8 Apr 2013 19:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOcoicaJjXWb for ; Mon, 8 Apr 2013 19:03:50 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0D521F845E for ; Mon, 8 Apr 2013 19:03:50 -0700 (PDT) Received: from [192.168.1.4] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6551A4004E for ; Mon, 8 Apr 2013 20:13:52 -0600 (MDT) Message-ID: <51637701.6040906@stpeter.im> Date: Mon, 08 Apr 2013 20:03:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <515CDDB1.2010809@stpeter.im> <515D9165.7@stpeter.im> <5162583A.1010807@nteczone.com> <51625901.2070709@nteczone.com> <5163034F.9000801@stpeter.im> In-Reply-To: <5163034F.9000801@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] [clue] Fwd: conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 02:03:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/8/13 11:50 AM, Peter Saint-Andre wrote: > Just FYI, in the XMPP community we had thought about the concept > of "hats", which are roles you can play in a conference (and you > can play multiple roles, just as you can wear different hats). We > have a very basic spec for hats here: > > http://xmpp.org/extensions/xep-0317.html > > Rather than continuing to pursue the hats idea, I've been thinking > that it might be better to settle on using conference-info syntax > from RFC 4575 (since that would improve interoperability across SIP > systems and XMPP systems -- there's nothing SIP-specific about > conference-info itself). Unfortunately, it appears that the > conference-info syntax is clear but the semantics are not. I'm > happy to put some cycles into clarifying the semantics if there's > interest. BTW, looking at RFC 4575, I notice that it defines a element but doesn't describe the syntax very precisely: 4.6.5.2. A provides the context for the set of conference operations that a participant can perform. This element can contain one or more of the following values: "administrator", "moderator", "user", "participant", "observer", and "none". A role of "none" indicates that any role is assigned. The semantic definition is out of the scope of this document and is subject to future policy documents. This element can be extended with new roles in future documents. That seems to imply that the syntax is: foo But the examples have: foo And is the syntax a comma-separated or space-separated list of values, or is it multiple child elements (whether or )? Anyone up for 4575bis??? ;-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRY3cBAAoJEOoGpJErxa2p9IsP/3FOY+Qz5ECnnhUsYnnZP4+y VgBggrhh2o0sBtm9h8Sx+afI6eH6TRje6uwDf6nfxMW3RPDdycThWFpC5Swkgetz wosAWSlSELU5lm0uHcN+OBaHLb023bVdOqV6BRo+7LoYXY2g+nimJzHeyTxCCisC gegdfoUVeffFtncaFcI1i2Fd5uoFk18jqLj0naZvUtgg+v8ETJVPFAQhyAae7qVL IME6Hgi853OVulckGvYD6uDU+VR36L0wQAydbJzjah3ntvw4qCjU1nggoYi+r5ED Leekvzz7tOn6+INzgKZpccei1OXNBmpibT+6IkNCieMSD2/uimIiMwK9fpFtrhp3 sAXzEhzX6+FtsghSUgqQgS6YjbammFk9lzkIPCN4iItxG1/vcYbfoWjSnWptQVAB ONHOFp+O5sikBrfxHpoIO5Yl1k7WcA8zX/2NDBHAD2fqFmBA6C7MHUBgb5pBmdkM WsoY8OW+07O9eN3YShqJqh11nPYYYX0Pdf1r5f3GtVlzGsqXbqSH6kn6P4g4w9UA tOfqC2H0CWIyvRdE8xYHvd2pwzimuzu+1qnpblPWFPhtYeqbCgzN8QHgxt2cTaY6 rcYxc0OS64xa9fQHg8ludnY5KIFKv1JDaVuzgnN+6pjxrqzQgCC+zIu9W50vSL8p g+xahByFC+kkkkSOY6C/ =CIF9 -----END PGP SIGNATURE----- From Christian.Groves@nteczone.com Mon Apr 8 19:27:29 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0538F21F8EC1 for ; Mon, 8 Apr 2013 19:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGUMtlmbCBTG for ; Mon, 8 Apr 2013 19:27:28 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id D6FDE21F8EB2 for ; Mon, 8 Apr 2013 19:27:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAAt8Y1F20TFL/2dsb2JhbAANRIM8wTuBJoMTAQEBBAEBATUbFQYKEQsYCRYPCQMCAQIBFTATBgIBARCIDKoWgzGQLI8qg0EDmBWTCg Received: from ppp118-209-49-75.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.49.75]) by ipmail04.adl6.internode.on.net with ESMTP; 09 Apr 2013 11:57:26 +0930 Message-ID: <51637C8C.7030802@nteczone.com> Date: Tue, 09 Apr 2013 12:27:24 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <515CDDB1.2010809@stpeter.im> <515D9165.7@stpeter.im> <5162583A.1010807@nteczone.com> <51625901.2070709@nteczone.com> <5163034F.9000801@stpeter.im> <51637701.6040906@stpeter.im> In-Reply-To: <51637701.6040906@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] [clue] Fwd: conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 02:27:29 -0000 Hello Peter, Do you mean RFC6501bis? :-) Christian On 9/04/2013 12:03 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 4/8/13 11:50 AM, Peter Saint-Andre wrote: > >> Just FYI, in the XMPP community we had thought about the concept >> of "hats", which are roles you can play in a conference (and you >> can play multiple roles, just as you can wear different hats). We >> have a very basic spec for hats here: >> >> http://xmpp.org/extensions/xep-0317.html >> >> Rather than continuing to pursue the hats idea, I've been thinking >> that it might be better to settle on using conference-info syntax >> from RFC 4575 (since that would improve interoperability across SIP >> systems and XMPP systems -- there's nothing SIP-specific about >> conference-info itself). Unfortunately, it appears that the >> conference-info syntax is clear but the semantics are not. I'm >> happy to put some cycles into clarifying the semantics if there's >> interest. > BTW, looking at RFC 4575, I notice that it defines a element > but doesn't describe the syntax very precisely: > > 4.6.5.2. > > A provides the context for the set of conference operations > that a participant can perform. This element can contain one or more > of the following values: "administrator", "moderator", "user", > "participant", "observer", and "none". A role of "none" indicates > that any role is assigned. The semantic definition is out of > the scope of this document and is subject to future policy documents. > This element can be extended with new roles in future documents. > > That seems to imply that the syntax is: > > > foo > > > But the examples have: > > > foo > > > And is the syntax a comma-separated or space-separated list of values, > or is it multiple child elements (whether or )? > > Anyone up for 4575bis??? ;-) > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRY3cBAAoJEOoGpJErxa2p9IsP/3FOY+Qz5ECnnhUsYnnZP4+y > VgBggrhh2o0sBtm9h8Sx+afI6eH6TRje6uwDf6nfxMW3RPDdycThWFpC5Swkgetz > wosAWSlSELU5lm0uHcN+OBaHLb023bVdOqV6BRo+7LoYXY2g+nimJzHeyTxCCisC > gegdfoUVeffFtncaFcI1i2Fd5uoFk18jqLj0naZvUtgg+v8ETJVPFAQhyAae7qVL > IME6Hgi853OVulckGvYD6uDU+VR36L0wQAydbJzjah3ntvw4qCjU1nggoYi+r5ED > Leekvzz7tOn6+INzgKZpccei1OXNBmpibT+6IkNCieMSD2/uimIiMwK9fpFtrhp3 > sAXzEhzX6+FtsghSUgqQgS6YjbammFk9lzkIPCN4iItxG1/vcYbfoWjSnWptQVAB > ONHOFp+O5sikBrfxHpoIO5Yl1k7WcA8zX/2NDBHAD2fqFmBA6C7MHUBgb5pBmdkM > WsoY8OW+07O9eN3YShqJqh11nPYYYX0Pdf1r5f3GtVlzGsqXbqSH6kn6P4g4w9UA > tOfqC2H0CWIyvRdE8xYHvd2pwzimuzu+1qnpblPWFPhtYeqbCgzN8QHgxt2cTaY6 > rcYxc0OS64xa9fQHg8ludnY5KIFKv1JDaVuzgnN+6pjxrqzQgCC+zIu9W50vSL8p > g+xahByFC+kkkkSOY6C/ > =CIF9 > -----END PGP SIGNATURE----- > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From stpeter@stpeter.im Mon Apr 8 19:30:38 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A0721F8EBE for ; Mon, 8 Apr 2013 19:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gja5UXx-fFEf for ; Mon, 8 Apr 2013 19:30:37 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 744A321F8E62 for ; Mon, 8 Apr 2013 19:30:37 -0700 (PDT) Received: from [192.168.1.4] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BC86C4004E; Mon, 8 Apr 2013 20:40:39 -0600 (MDT) Message-ID: <51637D48.2070602@stpeter.im> Date: Mon, 08 Apr 2013 20:30:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christian Groves References: <515CDDB1.2010809@stpeter.im> <515D9165.7@stpeter.im> <5162583A.1010807@nteczone.com> <51625901.2070709@nteczone.com> <5163034F.9000801@stpeter.im> <51637701.6040906@stpeter.im> <51637C8C.7030802@nteczone.com> In-Reply-To: <51637C8C.7030802@nteczone.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] [clue] Fwd: conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 02:30:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/8/13 8:27 PM, Christian Groves wrote: > Hello Peter, > > Do you mean RFC6501bis? :-) Maybe both, given that RFC 6501 elements refine, extend, or are interleaved with the root element from RFC 4575. (But yes, I was quoting from RFC 6501 there...) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRY31HAAoJEOoGpJErxa2pxZ8P/11aUJA24+oJ5xT8+S7pyjRy mBj6G7xuYohKjeKcd0FLspz3WT2h4IUnzAccN4vA4Q2z4BDf/tLBjoyaMRdlDQzo T3NR/NBE+ryf36nQ8oX9LmGaeHnHSPJoc7wj1vhigZmjIKO0E7W9Bqs+VqTDttIy JKAccPVM911JIB+ybpjSGiT2w4kuj2UDHfSWs+Fi+da4WG68ezgiW1nUUemdBpWL aPYaIStCdGoLXGq5RygPGlthm+T6X2bn4IP1kaPEtqM59+J6l0QGOrSFeoC5vK/R Tu4ENNGr5AxQk1Wb6S3r6b2nmtn+aeV8oWSGndAOwBjiG3wc/+SDybczzEfXmMI3 f1DNswZAzRKUt+fOcFmGYWCxX5mc3vtl2vh6Yjl07xFiQhOAQJted8Zl3d14mfjL YwyghDuYlhc9yN9IoI/1bca6kCizMrjJ4uJWZiWMkUH5/LrUTh0VrAqvq62GC2aX Evl2yZHrk9k1WOMSQ2dd7QWQcqzxPJ+dq+ZUP0Al5533Ndz/lvY9sdizo3vNqENw fbzxp3b6mwFb2DPWvm5tEda9jMWGfXX5BiiqPy35ozfPyhGbhFk85jCVsUF+kNc+ hm1apCnqdmdxV/SZsM8hc8SVjk8RTPLDPQEqUB6UfgAAWvOtLS0FcnsaajRGJrJL mLEPy0hppVwjoRwu3F4M =Q348 -----END PGP SIGNATURE----- From gonzalo.camarillo@ericsson.com Tue Apr 9 05:47:05 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B32321F9367 for ; Tue, 9 Apr 2013 05:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.238 X-Spam-Level: X-Spam-Status: No, score=-106.238 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDPHSka2dzST for ; Tue, 9 Apr 2013 05:47:04 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E471D21F936C for ; Tue, 9 Apr 2013 05:47:03 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-f4-51640dc3926f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EB.B7.10459.3CD04615; Tue, 9 Apr 2013 14:46:59 +0200 (CEST) Received: from [131.160.126.108] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Apr 2013 14:46:59 +0200 Message-ID: <51640DC2.4020500@ericsson.com> Date: Tue, 9 Apr 2013 15:46:58 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Richard Barnes References: <515E6B74.5030506@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvre5h3pRAg4mTrCyWTlrAanH+7yI2 i6l9tg7MHkuW/GTymLxxFovH3VuXmAKYo7hsUlJzMstSi/TtErgy1hyrLWgXqfh08gFLA2M3 fxcjB4eEgInEgifuXYycQKaYxIV769m6GLk4hAROMUosmbWeGSQhJLCGUWLFXDkQm1dAW2LG is8sIDaLgIrE4sUfGEFsNgELiS237oPFRQWiJP693c0IUS8ocXLmE7C4iIC8xOnrD1hBbGYB fYnOzm1gcWEBc4kDqxazQCzewyjxu2M62GJOgUCJZY87WCGuk5RYNK2TBaJZT2LK1RZGCFte YvvbOVCHakssf9bCMoFRaBaS3bOQtMxC0rKAkXkVI3tuYmZOernhJkZg6B7c8lt3B+OpcyKH GKU5WJTEecNcLwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYBQ0ujVTcw7fR4Yw4b516+dr mC4QCcyxDnqveij7sX5UvopAh9fUsntP9HsXLrObNEUzYXrhArcop1qjypgbuvv14gxbVuxl OnRzXpun57HN668sq/hzLrhD5pPXpr1HHr+revo6gWdlt3o769uUl2qe7Yc0XU88Xq+xreLl nZaO4uIv2dsO5CqxFGckGmoxFxUnAgDlr8n7KwIAAA== Cc: dispatch@ietf.org Subject: Re: [dispatch] Acronym for the SIP-XMPP effort X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 12:47:05 -0000 Hi, I agree we want to avoid creating confusion by re-using an acronym. I am fine with using STOX instead. It is clearly more financial oriented. Thanks, Gonzalo On 08/04/2013 10:38 PM, Richard Barnes wrote: > STOX - SIP-to-XMPP? > > > > On Mon, Apr 8, 2013 at 6:47 AM, > wrote: > > Hi Gonzalo, > > SIXPAC was the name of an earlier proposal to charter a WG about > combined use of SIP and XMPP at the endpoint. It never made it to a > real WG, but something similar still exists in the form of the CUSAX > proposal (http://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/). > > Since this effort we are now chartering is about > translation/mapping/gatewaying between SIP and XMPP, it may be best > to use a different name for it to avoid confusion with the combined > usage work. > > Markus > > > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org > ] On Behalf Of ext Gonzalo Camarillo > Sent: 05 April, 2013 09:13 > To: DISPATCH > Subject: [dispatch] Acronym for the SIP-XMPP effort > > Folks, > > I am going to handle the chartering of the SIP-XMPP effort, as > discussed in Orlando. As usual, we need to choose an acronym for the > group. Among the acronyms I have heard, I like this one best so far: > > SIXPAC - SIP Integration with XMPP in Presence Aware Contexts > > While, per the RAI tradition, it refers to an alcoholic drink, > usually beers, it also refers to the nice six packs all RAI > contributors are working on during the spring in order to show off > at the beach in summer :-) > > Any other suggestions? > > With respect to the chairs for this effort, we will be choosing them > soon as well. So, if you are interested but have not volunteered yet > per my other email (from yesterday), now it would be a great time to > drop me a note. > > Thanks, > > Gonzalo > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From gonzalo.camarillo@ericsson.com Tue Apr 9 05:56:47 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7855521F8F69 for ; Tue, 9 Apr 2013 05:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.238 X-Spam-Level: X-Spam-Status: No, score=-106.238 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+7gn1PByJ6J for ; Tue, 9 Apr 2013 05:56:46 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6508C21F8F33 for ; Tue, 9 Apr 2013 05:56:46 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-62-5164100970cd Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A9.1A.10459.90014615; Tue, 9 Apr 2013 14:56:41 +0200 (CEST) Received: from [131.160.126.108] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Apr 2013 14:56:40 +0200 Message-ID: <51641008.6040103@ericsson.com> Date: Tue, 9 Apr 2013 15:56:40 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Peter Saint-Andre References: <20130407221345.16413.81856.idtracker@ietfa.amsl.com> <5161F005.9070203@stpeter.im> In-Reply-To: <5161F005.9070203@stpeter.im> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VpdTICXQ4GyXoMXSSQtYLY7t6Wd2 YPJYsuQnk8fcPS+YA5iiuGxSUnMyy1KL9O0SuDL239vBXjBRoKL55GS2BsZu3i5GTg4JAROJ k9PXs0PYYhIX7q1n62Lk4hASOMUo8fjrDGYIZw2jxOE9c5hAqngFtCUmfzzMDGKzCKhIbPiy CcxmE7CQ2HLrPguILSoQJfHv7W5GiHpBiZMzn4DFRQS0JC5d6wPaxsHBLKAgsWY9J0hYWMBf 4tX+96wgtpBAvETP43VMICWcQOXrXupD3CYpsWhaJ9gUZgE9iSlXWxghbHmJ7W/nMEO0akss f9bCMoFRaBaSxbOQtMxC0rKAkXkVI3tuYmZOernhJkZgoB7c8lt3B+OpcyKHGKU5WJTEecNc LwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYGRUPij5y2jT7qfcUUKTj/oWiFq82FzEUJDf +0dzhtLJD0uNzm0NtSj4sYpjj8X8CcwsHZe+33+Sq/qqaeIxj/3LIx+uv+edvywm5EZN4J6L ln9ravZK7t/9zdtcaZls93krv89/tljs9vLni7YTEsn75rXo4ibPGwWXdzinudzffKpj4oe4 79JKLMUZiYZazEXFiQCHcNjIIgIAAA== Cc: DISPATCH Subject: Re: [dispatch] Fwd: I-D Action: draft-saintandre-impp-call-info-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 12:56:47 -0000 Folks, based on the discussions we have had on this draft (messages with "URI schemes in P-Asserted-Identity" in their Subjects), I am going to AD sponsor this draft. Cheers, Gonzalo On 08/04/2013 1:15 AM, Peter Saint-Andre wrote: > FYI. > > > -------- Original Message -------- > Subject: I-D Action: draft-saintandre-impp-call-info-01.txt > Date: Sun, 07 Apr 2013 15:13:45 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Instant Messaging and Presence Purpose for the > Call-Info Header in the Session Initiation Protocol (SIP) > Author(s) : Peter Saint-Andre > Filename : draft-saintandre-impp-call-info-01.txt > Pages : 4 > Date : 2013-04-07 > > Abstract: > This document defines and registers a value of "impp" ("instant > messaging and presence protocol") for the "purpose" header field > parameter of the Call-Info header field in the Session Initiation > Protocol (SIP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-saintandre-impp-call-info > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-saintandre-impp-call-info-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-saintandre-impp-call-info-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@alum.mit.edu Tue Apr 9 06:57:54 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80D421F8F9E for ; Tue, 9 Apr 2013 06:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.094 X-Spam-Level: X-Spam-Status: No, score=-0.094 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_17=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akHA2ap2d6kP for ; Tue, 9 Apr 2013 06:57:53 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 9698821F8F16 for ; Tue, 9 Apr 2013 06:57:50 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta03.westchester.pa.mail.comcast.net with comcast id Mmth1l0020Fqzac53pxqHW; Tue, 09 Apr 2013 13:57:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id Mpxp1l00y3ZTu2S3Upxpie; Tue, 09 Apr 2013 13:57:50 +0000 Message-ID: <51641E5C.5000503@alum.mit.edu> Date: Tue, 09 Apr 2013 21:57:48 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <515CDDB1.2010809@stpeter.im> <515D9165.7@stpeter.im> <5162583A.1010807@nteczone.com> <51625901.2070709@nteczone.com> <5163034F.9000801@stpeter.im> In-Reply-To: <5163034F.9000801@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365515870; bh=CzRszJzNLUNdzFoO3Y7hBoT/ieyRRhjjm9nzSOKkiVs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YhX6c25IStfFPH8b8nfH+rglrHen0+7wU0TkQOM0cC7vnBBMxOHXIGj/hx3h5s8aY 8UzmElcH3YAWQPZnhuq/kyWGUtHUzjhfNFgpQbiU60hO7mV4bHdTVMbMs6hpS/CaAQ wYU1s4cwqZODZx3ofEJa29dAqDviocuZiQ4j4hM72kf+8X9tMHds9yN/St9s9QJ9M8 vnuaIWrwF8NqpbehJRb4+tlqFFhqZRSH883nqAx5kWoNZ+f29XmZfZ5lPJHbyVyJMa GcdVc+5cH3YKAAlcqRA1jURxKe9pVSOEQb2Vd+XCqqv92KkD+f59008pfPfoYdY29n r12zTgjIdFnAw== Subject: Re: [dispatch] [clue] Fwd: conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 13:57:54 -0000 Coming late to the discussion... I agree that what CLUE is considering is a different usage than what RFC 4575 is talking about. But in both cases we are talking about attributes that are applied to *something*. For CLUE it is Captures that we are attaching attributes to while in RFC 4575 it is participants. If it makes sense, and I'm not yet sure it does in this case, we could have a definition of "role" that can be used by CLUE to describe captures and is also used in the conference event package to describe participants. My point is that the "name" of this attribute need not fully define what we mean. Rather it is the name together with the thing it is applied to. So I don't have a problem calling this "role". (But I also have no problem calling it something else.) In CLUE we tried this once - with "content" based on reusing the values from a=content. But then we decided that definition was too narrow and extending it enough would have undesirable consequences. It may turn out that sharing/reusing a definition for "role" is also problematic. But we can at least investigate it. Thanks, Paul On 4/9/13 1:50 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 4/7/13 11:43 PM, Christian Groves wrote: >> Perhaps I should have kept this on the dispatch list? > > Perhaps. At the least, it would be good to have one place to talk > about this topic. > >> On 8/04/2013 3:40 PM, Christian Groves wrote: >>> Hello Peter, >>> >>> I had envisaged that from the CLUE perspective that an IANA >>> registry would be establish for Role (and some of the >>> attributes). I'm not sure that it is possible to harmonise >>> RFC4575, RFC6501 and CLUE as I think they have different >>> semantics. >>> >>> RFC4575 seems just to have a free text field that's human >>> readable. The goal of the CLUE "role" attribute is to have a set >>> of tags which are human readable and able to used in an automatic >>> way. >>> >>> RFC6501 talks about "conference operations that a participant >>> can perform" I think this is semantically different to what is >>> being proposed in CLUE which is more about the person/s in a >>> capture (i.e. those depicted in the RTP stream). >>> >>> If it helps lessen the confusion we could change the name of the >>> CLUE parameter from "role" to "Character", "Captured Persons" or >>> "Person represented by media", etc.? With the semantic that the >>> media contains a person who is acting in that character/role. > > Apparently I got confused by the use of the term "role" in > draft-groves-clue-capture-attr because to me it seems like an > extension to the roles defined in RFC 6501, which provided some new > values for the same construct defined in RFC 4575. What you're saying > is that the CLUE roles proposed in draft-groves-clue-capture-attr are > actually a completely different construct. That is, RFC 4575 and RFC > 6501 define roles as essentially bundles of permissions to perform > certain operations, whereas the roles / characters in > draft-groves-clue-capture-attr have nothing to do with conference > control. Correct? > >>> I think part of the challenge will be to define the values. A >>> person can have multiple roles/characters, e.g. a chairman who is >>> acting as a scribe. Some have a similar function but have a >>> different connotation e.g. presenter versus lecturer. I think to >>> move forward we need to address these sorts of things. The >>> previous RFCs seem to have largely ignored the problem in the >>> final text. > > Agreed. > > Just FYI, in the XMPP community we had thought about the concept of > "hats", which are roles you can play in a conference (and you can play > multiple roles, just as you can wear different hats). We have a very > basic spec for hats here: > > http://xmpp.org/extensions/xep-0317.html > > Rather than continuing to pursue the hats idea, I've been thinking > that it might be better to settle on using conference-info syntax from > RFC 4575 (since that would improve interoperability across SIP systems > and XMPP systems -- there's nothing SIP-specific about conference-info > itself). Unfortunately, it appears that the conference-info syntax is > clear but the semantics are not. I'm happy to put some cycles into > clarifying the semantics if there's interest. > > (Now it seems that is a separate topic from the CLUE work, since CLUE > isn't actually using the RFC 4575 construct. So discussing this on the > DISPATCH list seems correct.) > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRYwNPAAoJEOoGpJErxa2p7b4P/1mWKSutcNRB7Zocwj4bFj43 > uYol1z/HSFBCPxLtqgVUL8EVifEImmf0aanMsX1+kgz/YMnpPNef5vISSL2GpQXW > zWEUdZQ5CJInPXkkKY4kxmFLtqs4HBHBjjJiUjb99qFv++qgmNA0gTx5qEKfV5d4 > O1CR/ua6iZRj2W78srt4zln3GQbdbkOUqVkAkf/SoNvggSdMwEkI/ZDx34x7hCdP > S2bn4tAcsRMFhLKiPPY0+oV4FRQ6/R4LE278dwmt2eqFQREJOMLiNOn2f3G5Bcr2 > P+f0nH22b2Nyd3KKQfvX34BiQebxRZ3VS+WrUJqofwz37/WL3CyoLOh9r+GSGrBJ > y1ch18d28G/DbMOJQhYn41U0447A+mb0Q4VnuwB/YAeRn/DoXI0Y478slrJIkyXs > pruktAusj4uhdCnTD5noBI3+4aGj7PNJIAWBCCb/EEGPOrQNnUDWoup345nxHZoK > /SzXSaz+guiQsb/heOGCQYH+q9E25n0UWMgKBAiVGQ1O6/Bc/FLemnryRr6WDfVV > qCofoU1wRbe2CS73LTnrH6+MeWY63Cjkv3jyTzzhuVdJIt1nopRwQMJvHWV48rii > DHrBNZA1aweJhPLtjtSzNb1bxg1g0swRMpCnyfDNML4Je5h9mp3+M2+S8mZc8ssm > qnM8GsRfyErV2pI505Fc > =n3og > -----END PGP SIGNATURE----- > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From mary.ietf.barnes@gmail.com Tue Apr 9 07:15:14 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B88221F913E for ; Tue, 9 Apr 2013 07:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.228 X-Spam-Level: X-Spam-Status: No, score=-103.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkETMSGI4N-4 for ; Tue, 9 Apr 2013 07:15:13 -0700 (PDT) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9DE21F903B for ; Tue, 9 Apr 2013 07:15:12 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id 6so2220134qeb.8 for ; Tue, 09 Apr 2013 07:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NqeIO9ZeLuSfxDXlMP9JivJmgh9ioj5rWmwg8OkCPiQ=; b=nvW4yNU+NkFnB/IC+5zb/Juc55XSiD8um2nS0Hs5cQxLBpb4Ah+rmrOPO4IoJKNj3G wHP2Vilsky7xDheoIBKdJ/1HUCJvXMp5aHCzktLMCrbtg+3MbLzp8m9UElySmM1OuYsP Ja26BzOSa77DUB4PoknkyWhoUt4lXkhVzaWiz9mXwrz3pq24frvH9Np5JVZ9FoNtEzqt Ksmwb4HpUiPgqVK7IuO/aUKpLGB1rpvQfVVVqyTbpGuinEJodMajcA1LrB0XAWYQ4CV5 mVQe5rPjggyuujuVF2krnZU/kVXGOX81LvckO/voGkmUNFlz53OR7VBYjNFbHMEoKnj7 KJ8w== MIME-Version: 1.0 X-Received: by 10.224.72.203 with SMTP id n11mr10587035qaj.72.1365516911761; Tue, 09 Apr 2013 07:15:11 -0700 (PDT) Received: by 10.49.75.5 with HTTP; Tue, 9 Apr 2013 07:15:11 -0700 (PDT) In-Reply-To: <51641E5C.5000503@alum.mit.edu> References: <515CDDB1.2010809@stpeter.im> <515D9165.7@stpeter.im> <5162583A.1010807@nteczone.com> <51625901.2070709@nteczone.com> <5163034F.9000801@stpeter.im> <51641E5C.5000503@alum.mit.edu> Date: Tue, 9 Apr 2013 09:15:11 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Cc: DISPATCH Subject: Re: [dispatch] [clue] Fwd: conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 14:15:14 -0000 Well, I had to join in the thread since it seems appropriate for Mary to respond to a thread with Peter & Paul ;) I do not think that the CLUE usage is any different really than XCON conference package defined role - in terms of the "roles" being both human readable and the semantics being unique to an application and can be based on policies. The latter was the XCON/conference intent as clearly stated in section 4.6.5.2 of 6501. It's the right thing for SIP based conferencing to be using this information and since CLUE is based on SIP, we need to have these things consistent. Regards, Mary. On Tue, Apr 9, 2013 at 8:57 AM, Paul Kyzivat wrote: > Coming late to the discussion... > > I agree that what CLUE is considering is a different usage than what RFC > 4575 is talking about. But in both cases we are talking about attributes > that are applied to *something*. For CLUE it is Captures that we are > attaching attributes to while in RFC 4575 it is participants. > > If it makes sense, and I'm not yet sure it does in this case, we could have > a definition of "role" that can be used by CLUE to describe captures and is > also used in the conference event package to describe participants. > > My point is that the "name" of this attribute need not fully define what we > mean. Rather it is the name together with the thing it is applied to. So I > don't have a problem calling this "role". (But I also have no problem > calling it something else.) > > In CLUE we tried this once - with "content" based on reusing the values from > a=content. But then we decided that definition was too narrow and extending > it enough would have undesirable consequences. It may turn out that > sharing/reusing a definition for "role" is also problematic. But we can at > least investigate it. > > Thanks, > Paul > > > > On 4/9/13 1:50 AM, Peter Saint-Andre wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 4/7/13 11:43 PM, Christian Groves wrote: >>> >>> Perhaps I should have kept this on the dispatch list? >> >> >> Perhaps. At the least, it would be good to have one place to talk >> about this topic. >> >>> On 8/04/2013 3:40 PM, Christian Groves wrote: >>>> >>>> Hello Peter, >>>> >>>> I had envisaged that from the CLUE perspective that an IANA >>>> registry would be establish for Role (and some of the >>>> attributes). I'm not sure that it is possible to harmonise >>>> RFC4575, RFC6501 and CLUE as I think they have different >>>> semantics. >>>> >>>> RFC4575 seems just to have a free text field that's human >>>> readable. The goal of the CLUE "role" attribute is to have a set >>>> of tags which are human readable and able to used in an automatic >>>> way. >>>> >>>> RFC6501 talks about "conference operations that a participant >>>> can perform" I think this is semantically different to what is >>>> being proposed in CLUE which is more about the person/s in a >>>> capture (i.e. those depicted in the RTP stream). >>>> >>>> If it helps lessen the confusion we could change the name of the >>>> CLUE parameter from "role" to "Character", "Captured Persons" or >>>> "Person represented by media", etc.? With the semantic that the >>>> media contains a person who is acting in that character/role. >> >> >> Apparently I got confused by the use of the term "role" in >> draft-groves-clue-capture-attr because to me it seems like an >> extension to the roles defined in RFC 6501, which provided some new >> values for the same construct defined in RFC 4575. What you're saying >> is that the CLUE roles proposed in draft-groves-clue-capture-attr are >> actually a completely different construct. That is, RFC 4575 and RFC >> 6501 define roles as essentially bundles of permissions to perform >> certain operations, whereas the roles / characters in >> draft-groves-clue-capture-attr have nothing to do with conference >> control. Correct? >> >>>> I think part of the challenge will be to define the values. A >>>> person can have multiple roles/characters, e.g. a chairman who is >>>> acting as a scribe. Some have a similar function but have a >>>> different connotation e.g. presenter versus lecturer. I think to >>>> move forward we need to address these sorts of things. The >>>> previous RFCs seem to have largely ignored the problem in the >>>> final text. >> >> >> Agreed. >> >> Just FYI, in the XMPP community we had thought about the concept of >> "hats", which are roles you can play in a conference (and you can play >> multiple roles, just as you can wear different hats). We have a very >> basic spec for hats here: >> >> http://xmpp.org/extensions/xep-0317.html >> >> Rather than continuing to pursue the hats idea, I've been thinking >> that it might be better to settle on using conference-info syntax from >> RFC 4575 (since that would improve interoperability across SIP systems >> and XMPP systems -- there's nothing SIP-specific about conference-info >> itself). Unfortunately, it appears that the conference-info syntax is >> clear but the semantics are not. I'm happy to put some cycles into >> clarifying the semantics if there's interest. >> >> (Now it seems that is a separate topic from the CLUE work, since CLUE >> isn't actually using the RFC 4575 construct. So discussing this on the >> DISPATCH list seems correct.) >> >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBAgAGBQJRYwNPAAoJEOoGpJErxa2p7b4P/1mWKSutcNRB7Zocwj4bFj43 >> uYol1z/HSFBCPxLtqgVUL8EVifEImmf0aanMsX1+kgz/YMnpPNef5vISSL2GpQXW >> zWEUdZQ5CJInPXkkKY4kxmFLtqs4HBHBjjJiUjb99qFv++qgmNA0gTx5qEKfV5d4 >> O1CR/ua6iZRj2W78srt4zln3GQbdbkOUqVkAkf/SoNvggSdMwEkI/ZDx34x7hCdP >> S2bn4tAcsRMFhLKiPPY0+oV4FRQ6/R4LE278dwmt2eqFQREJOMLiNOn2f3G5Bcr2 >> P+f0nH22b2Nyd3KKQfvX34BiQebxRZ3VS+WrUJqofwz37/WL3CyoLOh9r+GSGrBJ >> y1ch18d28G/DbMOJQhYn41U0447A+mb0Q4VnuwB/YAeRn/DoXI0Y478slrJIkyXs >> pruktAusj4uhdCnTD5noBI3+4aGj7PNJIAWBCCb/EEGPOrQNnUDWoup345nxHZoK >> /SzXSaz+guiQsb/heOGCQYH+q9E25n0UWMgKBAiVGQ1O6/Bc/FLemnryRr6WDfVV >> qCofoU1wRbe2CS73LTnrH6+MeWY63Cjkv3jyTzzhuVdJIt1nopRwQMJvHWV48rii >> DHrBNZA1aweJhPLtjtSzNb1bxg1g0swRMpCnyfDNML4Je5h9mp3+M2+S8mZc8ssm >> qnM8GsRfyErV2pI505Fc >> =n3og >> -----END PGP SIGNATURE----- >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Tue Apr 9 08:13:42 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2392A21F94D9 for ; Tue, 9 Apr 2013 08:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.162 X-Spam-Level: ** X-Spam-Status: No, score=2.162 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTzRNA0A1gFh for ; Tue, 9 Apr 2013 08:13:28 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id C4C5E21F9402 for ; Tue, 9 Apr 2013 08:13:23 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta03.westchester.pa.mail.comcast.net with comcast id MmVq1l00317dt5G53rDPQN; Tue, 09 Apr 2013 15:13:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id MrDP1l0073ZTu2S3ZrDP2B; Tue, 09 Apr 2013 15:13:23 +0000 Message-ID: <51643012.7020400@alum.mit.edu> Date: Tue, 09 Apr 2013 23:13:22 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <515E6B74.5030506@ericsson.com> <51640DC2.4020500@ericsson.com> In-Reply-To: <51640DC2.4020500@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365520403; bh=MG8T2twfwGCDFuv5MGKJAvA4q2SABqpDiHpHxRkNQrg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=I/AJXkSbEedi/ZeVKeId3O5wezHGCzZLNOTEeCx79/xN9J00LKhHp/ogQHr1oTnLL C/EfmGoWNVaoX7/a1/N6B4W7tn0vQamxpM+fh2k10gVetxqOOCgxSU3oaMiUgjSr3v 4FbWj9HwhZLR32U+LzqmYNBwB5BPg/S+iHrgYdFsUyx+ve4OJs5vinqz/tx7Q+lGY4 PekLzr9JghhRgU4q+foMUMzyDMt8ss/pAo6Tj4OckvMDrP/ltDNo56GqYwOYB8HoNV e45qUZQ/xSTY8PW+xYKg3qLpSiItq3W20hXt7rLaPCNjIWnWTTRlgwaSvLhD1JtqcJ VhjCutVKvkhhQ== Subject: Re: [dispatch] Acronym for the SIP-XMPP effort X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 15:13:43 -0000 On 4/9/13 8:46 PM, Gonzalo Camarillo wrote: > Hi, > > I agree we want to avoid creating confusion by re-using an acronym. I am > fine with using STOX instead. It is clearly more financial oriented. Hmm - I was thinking it was referring to antique torture devices. Paul > Thanks, > > Gonzalo > > On 08/04/2013 10:38 PM, Richard Barnes wrote: >> STOX - SIP-to-XMPP? >> >> >> >> On Mon, Apr 8, 2013 at 6:47 AM, > > wrote: >> >> Hi Gonzalo, >> >> SIXPAC was the name of an earlier proposal to charter a WG about >> combined use of SIP and XMPP at the endpoint. It never made it to a >> real WG, but something similar still exists in the form of the CUSAX >> proposal (http://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/). >> >> Since this effort we are now chartering is about >> translation/mapping/gatewaying between SIP and XMPP, it may be best >> to use a different name for it to avoid confusion with the combined >> usage work. >> >> Markus >> >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org >> ] On Behalf Of ext Gonzalo Camarillo >> Sent: 05 April, 2013 09:13 >> To: DISPATCH >> Subject: [dispatch] Acronym for the SIP-XMPP effort >> >> Folks, >> >> I am going to handle the chartering of the SIP-XMPP effort, as >> discussed in Orlando. As usual, we need to choose an acronym for the >> group. Among the acronyms I have heard, I like this one best so far: >> >> SIXPAC - SIP Integration with XMPP in Presence Aware Contexts >> >> While, per the RAI tradition, it refers to an alcoholic drink, >> usually beers, it also refers to the nice six packs all RAI >> contributors are working on during the spring in order to show off >> at the beach in summer :-) >> >> Any other suggestions? >> >> With respect to the chairs for this effort, we will be choosing them >> soon as well. So, if you are interested but have not volunteered yet >> per my other email (from yesterday), now it would be a great time to >> drop me a note. >> >> Thanks, >> >> Gonzalo >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From jmpolk@cisco.com Tue Apr 9 08:41:49 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622A521F9428 for ; Tue, 9 Apr 2013 08:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ0l6oZo8h+x for ; Tue, 9 Apr 2013 08:41:48 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B507321F940F for ; Tue, 9 Apr 2013 08:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3083; q=dns/txt; s=iport; t=1365522108; x=1366731708; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=OZus4EvXubQio0GmeeTHGZi1DK9sLAf4g6eSj8lON3E=; b=PKgLvwAhe1QGG/tlRIBmKFrpgEI8IjOV0iVHWyHcnSqjXXyWHtUFaJ6c 5+TCdRerlXRI+wVy4R8G6NBKTai07SuvaIbHt1VA4Oi3vABpNZLu7abEU sc3CP4m1XFGNThmAsJgvYFo2N+OPo8TwHTx1VekUEdUPQaFJg/MaDIiZr s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FADU2ZFGtJV2c/2dsb2JhbABRgwY2wS+BFRZ0gh8BAQEEAQEBNQI0CwwEBwQRBAEBAQkVCQcPCg4fCQgGARKIFAyuSJA6jVKBNwsHBoM7A4h+ijGEa49ugykegTc X-IronPort-AV: E=Sophos;i="4.87,439,1363132800"; d="scan'208";a="196718336" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 09 Apr 2013 15:41:48 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8718.cisco.com [10.99.80.25]) (authenticated bits=0) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r39Ffl37023509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Apr 2013 15:41:47 GMT Message-Id: <201304091541.r39Ffl37023509@rcdn-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 09 Apr 2013 10:40:29 -0500 To: Gonzalo Camarillo , Richard Barnes From: James Polk In-Reply-To: <51640DC2.4020500@ericsson.com> References: <515E6B74.5030506@ericsson.com> <51640DC2.4020500@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: dispatch@ietf.org Subject: Re: [dispatch] Acronym for the SIP-XMPP effort X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 15:41:49 -0000 At 07:46 AM 4/9/2013, Gonzalo Camarillo wrote: >Hi, > >I agree we want to avoid creating confusion by re-using an acronym. I am >fine with using STOX instead. It is clearly more financial oriented. think of it this way, following (buying/selling/owning/investing in/being stuck with/buying high - selling low) STOX (i.e., stocks) will *make* you drink... so it fits our theme indirectly. James >Thanks, > >Gonzalo > >On 08/04/2013 10:38 PM, Richard Barnes wrote: > > STOX - SIP-to-XMPP? > > > > > > > > On Mon, Apr 8, 2013 at 6:47 AM, > > wrote: > > > > Hi Gonzalo, > > > > SIXPAC was the name of an earlier proposal to charter a WG about > > combined use of SIP and XMPP at the endpoint. It never made it to a > > real WG, but something similar still exists in the form of the CUSAX > > proposal (http://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/). > > > > Since this effort we are now chartering is about > > translation/mapping/gatewaying between SIP and XMPP, it may be best > > to use a different name for it to avoid confusion with the combined > > usage work. > > > > Markus > > > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org > > ] On Behalf Of ext Gonzalo Camarillo > > Sent: 05 April, 2013 09:13 > > To: DISPATCH > > Subject: [dispatch] Acronym for the SIP-XMPP effort > > > > Folks, > > > > I am going to handle the chartering of the SIP-XMPP effort, as > > discussed in Orlando. As usual, we need to choose an acronym for the > > group. Among the acronyms I have heard, I like this one best so far: > > > > SIXPAC - SIP Integration with XMPP in Presence Aware Contexts > > > > While, per the RAI tradition, it refers to an alcoholic drink, > > usually beers, it also refers to the nice six packs all RAI > > contributors are working on during the spring in order to show off > > at the beach in summer :-) > > > > Any other suggestions? > > > > With respect to the chairs for this effort, we will be choosing them > > soon as well. So, if you are interested but have not volunteered yet > > per my other email (from yesterday), now it would be a great time to > > drop me a note. > > > > Thanks, > > > > Gonzalo > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From Christian.Groves@nteczone.com Tue Apr 9 17:03:09 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D94821F97D4 for ; Tue, 9 Apr 2013 17:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeuC-eMo3PD5 for ; Tue, 9 Apr 2013 17:03:08 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 816A721F97D6 for ; Tue, 9 Apr 2013 17:03:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAHCrZFF20U+X/2dsb2JhbAANRIM8wTeBK4MTAQEBBAEBATUbFQYbCxgJJQ8CFjATBgIBARCIDKsvk1iPDwyDQQOYGpML Received: from ppp118-209-79-151.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.79.151]) by ipmail04.adl6.internode.on.net with ESMTP; 10 Apr 2013 09:33:05 +0930 Message-ID: <5164AC37.90607@nteczone.com> Date: Wed, 10 Apr 2013 10:03:03 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <515CDDB1.2010809@stpeter.im> <515D9165.7@stpeter.im> <5162583A.1010807@nteczone.com> <51625901.2070709@nteczone.com> <5163034F.9000801@stpeter.im> <51641E5C.5000503@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] [clue] Fwd: conference roles X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 00:03:09 -0000 4.6.5.2 RFC6501 also says "A provides the context for the set of conference operations that a participant can perform." To me this is a semantic. I think the issue is that it presents a set of values that have no definition and says that policy is defined in the future. The description so sparse its hard to see what its actually used for. Policy could be set by the endpoint manufacturer, user, service provider, a standards body etc. Regards, Christian On 10/04/2013 12:15 AM, Mary Barnes wrote: > Well, I had to join in the thread since it seems appropriate for Mary > to respond to a thread with Peter & Paul ;) I do not think that the > CLUE usage is any different really than XCON conference package > defined role - in terms of the "roles" being both human readable and > the semantics being unique to an application and can be based on > policies. The latter was the XCON/conference intent as clearly stated > in section 4.6.5.2 of 6501. It's the right thing for SIP based > conferencing to be using this information and since CLUE is based on > SIP, we need to have these things consistent. > > Regards, > Mary. > > On Tue, Apr 9, 2013 at 8:57 AM, Paul Kyzivat wrote: >> Coming late to the discussion... >> >> I agree that what CLUE is considering is a different usage than what RFC >> 4575 is talking about. But in both cases we are talking about attributes >> that are applied to *something*. For CLUE it is Captures that we are >> attaching attributes to while in RFC 4575 it is participants. >> >> If it makes sense, and I'm not yet sure it does in this case, we could have >> a definition of "role" that can be used by CLUE to describe captures and is >> also used in the conference event package to describe participants. >> >> My point is that the "name" of this attribute need not fully define what we >> mean. Rather it is the name together with the thing it is applied to. So I >> don't have a problem calling this "role". (But I also have no problem >> calling it something else.) >> >> In CLUE we tried this once - with "content" based on reusing the values from >> a=content. But then we decided that definition was too narrow and extending >> it enough would have undesirable consequences. It may turn out that >> sharing/reusing a definition for "role" is also problematic. But we can at >> least investigate it. >> >> Thanks, >> Paul >> >> >> >> On 4/9/13 1:50 AM, Peter Saint-Andre wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 4/7/13 11:43 PM, Christian Groves wrote: >>>> Perhaps I should have kept this on the dispatch list? >>> >>> Perhaps. At the least, it would be good to have one place to talk >>> about this topic. >>> >>>> On 8/04/2013 3:40 PM, Christian Groves wrote: >>>>> Hello Peter, >>>>> >>>>> I had envisaged that from the CLUE perspective that an IANA >>>>> registry would be establish for Role (and some of the >>>>> attributes). I'm not sure that it is possible to harmonise >>>>> RFC4575, RFC6501 and CLUE as I think they have different >>>>> semantics. >>>>> >>>>> RFC4575 seems just to have a free text field that's human >>>>> readable. The goal of the CLUE "role" attribute is to have a set >>>>> of tags which are human readable and able to used in an automatic >>>>> way. >>>>> >>>>> RFC6501 talks about "conference operations that a participant >>>>> can perform" I think this is semantically different to what is >>>>> being proposed in CLUE which is more about the person/s in a >>>>> capture (i.e. those depicted in the RTP stream). >>>>> >>>>> If it helps lessen the confusion we could change the name of the >>>>> CLUE parameter from "role" to "Character", "Captured Persons" or >>>>> "Person represented by media", etc.? With the semantic that the >>>>> media contains a person who is acting in that character/role. >>> >>> Apparently I got confused by the use of the term "role" in >>> draft-groves-clue-capture-attr because to me it seems like an >>> extension to the roles defined in RFC 6501, which provided some new >>> values for the same construct defined in RFC 4575. What you're saying >>> is that the CLUE roles proposed in draft-groves-clue-capture-attr are >>> actually a completely different construct. That is, RFC 4575 and RFC >>> 6501 define roles as essentially bundles of permissions to perform >>> certain operations, whereas the roles / characters in >>> draft-groves-clue-capture-attr have nothing to do with conference >>> control. Correct? >>> >>>>> I think part of the challenge will be to define the values. A >>>>> person can have multiple roles/characters, e.g. a chairman who is >>>>> acting as a scribe. Some have a similar function but have a >>>>> different connotation e.g. presenter versus lecturer. I think to >>>>> move forward we need to address these sorts of things. The >>>>> previous RFCs seem to have largely ignored the problem in the >>>>> final text. >>> >>> Agreed. >>> >>> Just FYI, in the XMPP community we had thought about the concept of >>> "hats", which are roles you can play in a conference (and you can play >>> multiple roles, just as you can wear different hats). We have a very >>> basic spec for hats here: >>> >>> http://xmpp.org/extensions/xep-0317.html >>> >>> Rather than continuing to pursue the hats idea, I've been thinking >>> that it might be better to settle on using conference-info syntax from >>> RFC 4575 (since that would improve interoperability across SIP systems >>> and XMPP systems -- there's nothing SIP-specific about conference-info >>> itself). Unfortunately, it appears that the conference-info syntax is >>> clear but the semantics are not. I'm happy to put some cycles into >>> clarifying the semantics if there's interest. >>> >>> (Now it seems that is a separate topic from the CLUE work, since CLUE >>> isn't actually using the RFC 4575 construct. So discussing this on the >>> DISPATCH list seems correct.) >>> >>> Peter >>> >>> - -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>> >>> iQIcBAEBAgAGBQJRYwNPAAoJEOoGpJErxa2p7b4P/1mWKSutcNRB7Zocwj4bFj43 >>> uYol1z/HSFBCPxLtqgVUL8EVifEImmf0aanMsX1+kgz/YMnpPNef5vISSL2GpQXW >>> zWEUdZQ5CJInPXkkKY4kxmFLtqs4HBHBjjJiUjb99qFv++qgmNA0gTx5qEKfV5d4 >>> O1CR/ua6iZRj2W78srt4zln3GQbdbkOUqVkAkf/SoNvggSdMwEkI/ZDx34x7hCdP >>> S2bn4tAcsRMFhLKiPPY0+oV4FRQ6/R4LE278dwmt2eqFQREJOMLiNOn2f3G5Bcr2 >>> P+f0nH22b2Nyd3KKQfvX34BiQebxRZ3VS+WrUJqofwz37/WL3CyoLOh9r+GSGrBJ >>> y1ch18d28G/DbMOJQhYn41U0447A+mb0Q4VnuwB/YAeRn/DoXI0Y478slrJIkyXs >>> pruktAusj4uhdCnTD5noBI3+4aGj7PNJIAWBCCb/EEGPOrQNnUDWoup345nxHZoK >>> /SzXSaz+guiQsb/heOGCQYH+q9E25n0UWMgKBAiVGQ1O6/Bc/FLemnryRr6WDfVV >>> qCofoU1wRbe2CS73LTnrH6+MeWY63Cjkv3jyTzzhuVdJIt1nopRwQMJvHWV48rii >>> DHrBNZA1aweJhPLtjtSzNb1bxg1g0swRMpCnyfDNML4Je5h9mp3+M2+S8mZc8ssm >>> qnM8GsRfyErV2pI505Fc >>> =n3og >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From dan@itsyscom.com Wed Apr 10 01:28:23 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2FC21F8D05 for ; Wed, 10 Apr 2013 01:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmPc3ge3SgdR for ; Wed, 10 Apr 2013 01:28:22 -0700 (PDT) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF4921F8D00 for ; Wed, 10 Apr 2013 01:28:21 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id d4so99251eek.29 for ; Wed, 10 Apr 2013 01:28:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding :x-gm-message-state; bh=m1sUimZvfLRceRCTQXRbzsobo+GHSJLrHfyPs6HEFXw=; b=DkCnDeur5e8y+sS9avFauvri7dJKkbznVf/VwAAF+A9AMA8kcWXojg2wETQUcKgolO 4PQZ/E9E/PjKwMe/kXfzXSWui1gpxD6PPwQ4WhmIchLb0xj/ClWKgpfefyWt9DVaAlZu WLpLrmk74p+hHe2PWLE1tim4bvgnaNVk1pddNwx96wIEzc/TBJMEVNrbMq9dwi4bpXKP RX6PJcyDVstvQZeAydwNfnaI86ZoDrSzwRzIf0LIBSw52TQqppA7JKrILauS0q1L2rU3 4fEA6h3A2BrGqjO0D1j8Le4O7E2M63/ZZXiawbt6O8eIiE7CPCbORSPfoD+0fT6D8Lr9 xZDQ== X-Received: by 10.15.43.132 with SMTP id x4mr3149748eev.31.1365582500980; Wed, 10 Apr 2013 01:28:20 -0700 (PDT) Received: from [10.10.10.155] (host1.itsyscom.com. [87.139.12.167]) by mx.google.com with ESMTPS id r4sm42285920eeo.12.2013.04.10.01.28.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Apr 2013 01:28:19 -0700 (PDT) Message-ID: <516522A1.6060804@itsyscom.com> Date: Wed, 10 Apr 2013 10:28:17 +0200 From: Dan Christian Bogos Organization: ITsysCOM, inh. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnefexG2BWSUztB/tq1m5M4azU/2jMIBCBQDAT4NTFzudeQPGJ810Wq3xYC7neEVmZKUg6Y X-Mailman-Approved-At: Wed, 10 Apr 2013 05:57:21 -0700 Subject: [dispatch] I-D Action: draft-ivov-xmpp-cusax-04.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 08:29:32 -0000 Dear All, After reading your draft I would like to express here my interest in the integration you have proposed. I have already used it in a couple of scenarios and, despite the latest trends in complicating things and analyzing all kind of network high availability scenarios ... it simply works. If you find them useful, here are some quick thoughts from me on related: * In order to avoid disturbing the security of one protocol when combining it with the other, one should not attempt to unify the authentication mechanisms or the data driving them. * In real-life networks I have met the need of combining CUSAX with keeping support for features available complementary in both protocols, since the ideal case of dual-stack protocol implementation in the agents was quite rare. I am sure in the future these implementations will be more easy to find but, in order to transition existing networks towards CUSAX support, failover mechanisms still need to defined. One simple approach would be flag-ing "exceptions" on both server as well as CUSAX aware UAs. Another useful feature I find by combining SIP and XMPP is improving ways to standardize interaction with SIP Proxies/B2BUAs through XMPP, as example of applicability being third-party-call-control by using non SIP means. I am not sure this is the domain targeted by CUSAX but still votes for SIP+XMPP interaction. Once again, thanks for this! DanB With regards, ITsysCOM, inh. Dan Christian Bogos Tiroler str. 9 D-83435 Bad Reichenhall Germany Tel.: +49 (0) 8651/7174963 Fax.:+49 (0) 8651/7174964 email: dan@itsyscom.com http://www.itsyscom.com From stephane.cazeaux@orange.com Fri Apr 12 14:07:35 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0095C21F8564 for ; Fri, 12 Apr 2013 14:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cngPjDhsa50q for ; Fri, 12 Apr 2013 14:07:34 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 159E521F846C for ; Fri, 12 Apr 2013 14:07:34 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 182217D4002; Fri, 12 Apr 2013 23:07:33 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 0C57D7D4001; Fri, 12 Apr 2013 23:07:33 +0200 (CEST) Received: from FTRDCH02.rd.francetelecom.fr ([10.194.32.13]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Apr 2013 23:07:33 +0200 Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH02.rd.francetelecom.fr ([::1]) with mapi id 14.02.0342.003; Fri, 12 Apr 2013 23:07:32 +0200 From: To: , Thread-Topic: [dispatch] New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt Thread-Index: AQHON8G+N4Ju3olXqUmWoYjTTmp7BA== Date: Fri, 12 Apr 2013 21:07:31 +0000 Message-ID: References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> <513DDE61.7010605@nostrum.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.115.36] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 12 Apr 2013 21:07:33.0224 (UTC) FILETIME=[C025C680:01CE37C1] Cc: dispatch@ietf.org, fluffy@iii.ca Subject: Re: [dispatch] New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 21:07:35 -0000 SGkgYWxsDQoNCkkgY29tZSBiYWNrIG9uIHRoZSBQUyBub3RlIGJlbG93LiBJdCBpcyBwb3NzaWJs ZSB0byBoYW5kbGUgYmluYXJ5IGRhdGEgaW4gSlMgY29kZSB1c2luZyBUeXBlZEFycmF5cyAoaHR0 cDovL3d3dy5raHJvbm9zLm9yZy9yZWdpc3RyeS90eXBlZGFycmF5L3NwZWNzL2xhdGVzdC8pLiBU aGUgVWludDhBcnJheSB0eXBlZCBhcnJheSBpcyBhcHByb3ByaWF0ZSBmb3IgQkZDUC4NCkl0IGlz IGFscmVhZHkgd2lkZWx5IHN1cHBvcnRlZCBpbiBicm93c2VycyAoaHR0cDovL2Nhbml1c2UuY29t L3R5cGVkYXJyYXlzKS4gDQoNClN0w6lwaGFuZQ0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KRGXCoDogScOxYWtpIEJheiBDYXN0aWxsbyBbbWFpbHRvOmliY0BhbGlheC5uZXRdIA0K RW52b3nDqcKgOiBsdW5kaSAxMSBtYXJzIDIwMTMgMTU6MjgNCsOAwqA6IEFkYW0gUm9hY2gNCkNj wqA6IEN1bGxlbiBKZW5uaW5nczsgZGlzcGF0Y2hAaWV0Zi5vcmc7IENBWkVBVVggU3RlcGhhbmUg T0xOQy9PTFBTDQpPYmpldMKgOiBSZTogW2Rpc3BhdGNoXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXBhc2N1YWwtZGlzcGF0Y2gtYmZjcC13ZWJzb2NrZXQtMDAudHh0DQoNCjIw MTMvMy8xMSBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPjoNCj4gQWxsIEkgdGhpbmsgeW91 J2xsIHNlZSBpcyB0aGF0IHRoZSBicm93c2VyIC0tIGp1c3QgbGlrZSBhbnkgb3RoZXIgDQo+IGVu ZHBvaW50IHRoYXQgZG9lc24ndCBzdXBwb3J0IEJGQ1AgLS0gd291bGQgZGVjbGluZSB0aGUgQkZD UCBtZWRpYSBzZWN0aW9uLg0KDQpIb3BlZnVsbHkgeWVzIDopDQoNClRoZW4gdGhlIHByb2JsZW0g aXMgaG93IHRoZSBKUyBjb2RlICpwYXJzZXMqIGFuZCAqbWFuZ2xlcyogdGhlIFNEUCB0byBpbnRl cmFjdCB3aXRoIHRoZSBCRlBDIG1lZGlhIHNlY3Rpb24sIHdoaWNoIGlzIGhhcmQgdG8gYWNjb21w bGlzaCBnaXZlbiB0aGUgU0RQIGZvcm1hdC4uLiBidXQgdGhhdCdzIGFub3RoZXIgc3ViamVjdCA6 KQ0KDQpQUzogQW55aG93IEkgd291bGQgbGlrZSB0byBpbnNpc3QgdGhhdCwgaWYgQkZQQyBtZWFu cyBhICJiaW5hcnkgcHJvdG9jb2wiLCB0aGVuIGl0IHdpbGwgYmUgcmVhbGx5IGhhcmQgdG8gaW1w bGVtZW50IGl0IGF0IEphdmFTY3JpcHQgbGV2ZWwuDQoNCg0KLS0NCknDsWFraSBCYXogQ2FzdGls bG8NCjxpYmNAYWxpYXgubmV0Pg0K From ibc@aliax.net Fri Apr 12 14:49:23 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C31E21F8842 for ; Fri, 12 Apr 2013 14:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ycwivdc82Fa for ; Fri, 12 Apr 2013 14:49:22 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6F37B21F86BA for ; Fri, 12 Apr 2013 14:49:22 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id s14so1829126qeb.27 for ; Fri, 12 Apr 2013 14:49:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=yaEqHH1tC3tb8sXLlORHbfVcIPe+m25cDtIThBFw6K8=; b=UvkUEIKFAlHIqqhDO9KL6sPMih3fp4T66Bj1JozF6ztsU49duh/qL3xA5rKuDwCJ8m 3wEF83vkiUTyhscFM+DjZsUnIgUfJgjw36zBXRMDXdObpsGoQR/BzetlgatcF5ulcw3/ PilttUsa+rEbVsfQwM1nVbZ7TyjqDeLFvF0ZGtuvG/s7ERVjnAhdbVKbxrtfI1FnJoJY FDop6+R/ynZ5EvOMH3HaacIfWXF4EPGNLyw33c8s9Da+BTgdcGvrJf3Kh8LyltNGXiku ZDyNcoRZ+hE8Nxs2p7Y/7dlrDN3a0CU0UE+LsoT4ascp9CEW22mYDhca0yIi0eeK+stg 4XmA== MIME-Version: 1.0 X-Received: by 10.229.169.138 with SMTP id z10mr346557qcy.105.1365803361803; Fri, 12 Apr 2013 14:49:21 -0700 (PDT) Received: by 10.49.81.175 with HTTP; Fri, 12 Apr 2013 14:49:21 -0700 (PDT) Received: by 10.49.81.175 with HTTP; Fri, 12 Apr 2013 14:49:21 -0700 (PDT) In-Reply-To: References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> <513DDE61.7010605@nostrum.com> Date: Fri, 12 Apr 2013 23:49:21 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: stephane.cazeaux@orange.com Content-Type: multipart/alternative; boundary=e89a8f5034aa36baee04da30e0f9 X-Gm-Message-State: ALoCoQkejfytudxX3ZFzXjpQhFJklOj1TBQlk2R3fMqjBzjo1IeOd1/9IKYApAWhyZbYW2vetbD3 Cc: dispatch@ietf.org, Cullen Jennings Subject: Re: [dispatch] New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 21:49:23 -0000 --e89a8f5034aa36baee04da30e0f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sure but, is it really friendly? Would somebody design such a binary protocol from scratch to be handled by JS? -- I=C3=B1aki Baz Castillo El 12/04/2013 23:07, escribi=C3=B3: > Hi all > > I come back on the PS note below. It is possible to handle binary data in > JS code using TypedArrays ( > http://www.khronos.org/registry/typedarray/specs/latest/). The Uint8Array > typed array is appropriate for BFCP. > It is already widely supported in browsers (http://caniuse.com/typedarray= s > ). > > St=C3=A9phane > > > -----Message d'origine----- > De : I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net] > Envoy=C3=A9 : lundi 11 mars 2013 15:28 > =C3=80 : Adam Roach > Cc : Cullen Jennings; dispatch@ietf.org; CAZEAUX Stephane OLNC/OLPS > Objet : Re: [dispatch] New Version Notification for > draft-pascual-dispatch-bfcp-websocket-00.txt > > 2013/3/11 Adam Roach : > > All I think you'll see is that the browser -- just like any other > > endpoint that doesn't support BFCP -- would decline the BFCP media > section. > > Hopefully yes :) > > Then the problem is how the JS code *parses* and *mangles* the SDP to > interact with the BFPC media section, which is hard to accomplish given t= he > SDP format... but that's another subject :) > > PS: Anyhow I would like to insist that, if BFPC means a "binary protocol"= , > then it will be really hard to implement it at JavaScript level. > > > -- > I=C3=B1aki Baz Castillo > > --e89a8f5034aa36baee04da30e0f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sure but, is it really friendly? Would somebody design such = a binary protocol from scratch to be handled by JS?

--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

El 12/04/2013 23:07, <stephane.cazeaux@orange.com> escribi=C3=B3:=
Hi all

I come back on the PS note below. It is possible to handle binary data in J= S code using TypedArrays (http://www.khronos.org/registry/typed= array/specs/latest/). The Uint8Array typed array is appropriate for BFC= P.
It is already widely supported in browsers (http://caniuse.com/typedarrays).

St=C3=A9phane


-----Message d'origine-----
De=C2=A0: I=C3=B1aki Baz Castillo [mailto:= ibc@aliax.net]
Envoy=C3=A9=C2=A0: lundi 11 mars 2013 15:28
=C3=80=C2=A0: Adam Roach
Cc=C2=A0: Cullen Jennings; dispatch@ie= tf.org; CAZEAUX Stephane OLNC/OLPS
Objet=C2=A0: Re: [dispatch] New Version Notification for draft-pascual-disp= atch-bfcp-websocket-00.txt

2013/3/11 Adam Roach <adam@nostrum.c= om>:
> All I think you'll see is that the browser -- just like any other<= br> > endpoint that doesn't support BFCP -- would decline the BFCP media= section.

Hopefully yes :)

Then the problem is how the JS code *parses* and *mangles* the SDP to inter= act with the BFPC media section, which is hard to accomplish given the SDP = format... but that's another subject :)

PS: Anyhow I would like to insist that, if BFPC means a "binary protoc= ol", then it will be really hard to implement it at JavaScript level.<= br>

--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
--e89a8f5034aa36baee04da30e0f9-- From pkyzivat@alum.mit.edu Sat Apr 13 08:31:58 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1BA21F8960 for ; Sat, 13 Apr 2013 08:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAvJZXj1WgkH for ; Sat, 13 Apr 2013 08:31:57 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 3D35721F86BC for ; Sat, 13 Apr 2013 08:31:55 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta05.westchester.pa.mail.comcast.net with comcast id PPoo1l0041GhbT855TXvMu; Sat, 13 Apr 2013 15:31:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:1915:60f9:6219:a5a6]) by omta07.westchester.pa.mail.comcast.net with comcast id PTXt1l00m2bMZ333TTXtm5; Sat, 13 Apr 2013 15:31:55 +0000 Message-ID: <51697A68.6000308@alum.mit.edu> Date: Sat, 13 Apr 2013 11:31:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> <513DDE61.7010605@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365867115; bh=dKJwJXhBxGs46qt6zzKDLlgoC/ES6TH6tg6agynX2C0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=S/tbAnNRbZMrCM3WKptMgpuUaydgYGkVpNk4jlW+HA080oNWLwPnWYzgKzT8D9YW4 nPGmkYudk55yHZIc9Ob25TzN471KUfPkgCa8stsdQDDwF+vizzLURTecLqnsRwi/gK TlAEQpylfpkIeVUHKWm7V/FNblCg8SvkmwEhUoGxLY651mQ9zUS0oRVWLuVrQEUlLH ckrEFRdrolW9hn0fQngvMT8XsCftjsfcDyAgskgttOpFIcCey3EYEJJ0q7BSf6fYin 9Dk0WWQM8KLNImtBGtEA72B1KJyEWxyR8t9z98eupmFIIwIaBiIK0u406KdkRpy9mD tf5fRM0MTV2eA== Subject: Re: [dispatch] New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 15:31:58 -0000 On 4/12/13 5:49 PM, Iñaki Baz Castillo wrote: > Sure but, is it really friendly? Would somebody design such a binary > protocol from scratch to be handled by JS? No, probably not. But since the protocol is already defined and implemented, it isn't unreasonable to expect JS to deal with it, rather than having everybody else adapt to JS limitations. Thanks, Paul > -- > Iñaki Baz Castillo > > > > El 12/04/2013 23:07, > escribió: > > Hi all > > I come back on the PS note below. It is possible to handle binary > data in JS code using TypedArrays > (http://www.khronos.org/registry/typedarray/specs/latest/). The > Uint8Array typed array is appropriate for BFCP. > It is already widely supported in browsers > (http://caniuse.com/typedarrays). > > Stéphane > > > -----Message d'origine----- > De : Iñaki Baz Castillo [mailto:ibc@aliax.net ] > Envoyé : lundi 11 mars 2013 15:28 > À : Adam Roach > Cc : Cullen Jennings; dispatch@ietf.org ; > CAZEAUX Stephane OLNC/OLPS > Objet : Re: [dispatch] New Version Notification for > draft-pascual-dispatch-bfcp-websocket-00.txt > > 2013/3/11 Adam Roach >: > > All I think you'll see is that the browser -- just like any other > > endpoint that doesn't support BFCP -- would decline the BFCP > media section. > > Hopefully yes :) > > Then the problem is how the JS code *parses* and *mangles* the SDP > to interact with the BFPC media section, which is hard to accomplish > given the SDP format... but that's another subject :) > > PS: Anyhow I would like to insist that, if BFPC means a "binary > protocol", then it will be really hard to implement it at JavaScript > level. > > > -- > Iñaki Baz Castillo > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From ibc@aliax.net Mon Apr 15 04:01:40 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C8221F87D5 for ; Mon, 15 Apr 2013 04:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4EspM9iZovk for ; Mon, 15 Apr 2013 04:01:39 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 799C621F87D0 for ; Mon, 15 Apr 2013 04:01:39 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id n41so2095461qco.7 for ; Mon, 15 Apr 2013 04:01:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=ABwEcsvMajiPNWmTpdsPoq40quUA+S6j8FRgNJzwROs=; b=HIbWxE2bO1wfmWj9VmGJeHZTNgJnkP4KBGi/AfNVLY/fW1VNUMyhrDoRX/kVER1whe UOHPADMjYvQbOMbZsU1OEc3V+5r7kzEGZbukPkgzcZb9MMSGA2wR5kONFjSlOXsZ/u1j pIfpr+AMZCR2JhxbmZ8JVZAtXbWjBJGVqJRyQtXsr6D4pGWHzACAHHemE4tg789vCspL rsOSh8hPjNV90Tlfk2GVH/vqp1ANbC9AH7UkpIRzbIrmPz//l4e12Ghz9UtaRuzqMqlY V9bqPuum/iowgEKB3lU89jmQ2Xkucr93GgGUDpmZaLDnxI844/aK5LEP37xy4BRQ2CZx mfGA== X-Received: by 10.49.104.196 with SMTP id gg4mr25240789qeb.53.1366023698900; Mon, 15 Apr 2013 04:01:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Mon, 15 Apr 2013 04:01:18 -0700 (PDT) In-Reply-To: References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 15 Apr 2013 13:01:18 +0200 Message-ID: To: Victor Pascual Avila Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkyfzRLe+aUWvcwzNjNfgx70q6cuZlPCQ1rSP8r6R460dsYvd3KekJxUiMwQt8FlU0dcrX7 Cc: DISPATCH Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 11:01:40 -0000 Section 6 has some typos: - Missing dot at the end of paragraphs 1, 3 and 4. - s/WS/WSS/g in the 4th paragraph. 2013/2/21 Victor Pascual Avila : > Hi all, > > We have submitted a new Internet draft to describe the WebSocket > Protocol as a Transport for the Binary Floor Control Protocol (BFCP). > We are looking forward to your review comments. > > http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 > > Best regards, > -Victor > > > On 2/15/13 6:17 PM, "internet-drafts@ietf.org" > wrote: > >> >>A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt >>has been successfully submitted by Victor Pascual and posted to the >>IETF repository. >> >>Filename: draft-pascual-dispatch-bfcp-websocket >>Revision: 00 >>Title: The WebSocket Protocol as a Transport for the Binary Floo= r >>Control Protocol (BFCP) >>Creation date: 2013-02-15 >>Group: Individual Submission >>Number of pages: 9 >>URL: >>http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-websocket= - >>00.txt >>Status: >>http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket >>Htmlized: >>http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 >> >> >>Abstract: >> The WebSocket protocol enables two-way realtime communication between >> clients and servers. This document specifies a new WebSocket sub- >> protocol as a reliable transport mechanism between Binary Floor >> Control Protocol (BFCP) entities to enable usage of BFCP in new >> scenarios. This document normatively updates >> [I-D.draft-ietf-bfcpbis-rfc4582bis] and >> [I-D.draft-ietf-bfcpbis-rfc4583bis] >> >> >> >> >> >>The IETF Secretariat >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --=20 I=C3=B1aki Baz Castillo From keith.drage@alcatel-lucent.com Mon Apr 15 05:15:07 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6906221F937A for ; Mon, 15 Apr 2013 05:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY5Iz8h9xNh9 for ; Mon, 15 Apr 2013 05:15:06 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id ACD7C21F9027 for ; Mon, 15 Apr 2013 05:15:06 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r3FCF3rH020261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Apr 2013 07:15:03 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r3FCF0ef032120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Apr 2013 08:15:02 -0400 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 15 Apr 2013 08:15:00 -0400 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 15 Apr 2013 14:14:42 +0200 From: "DRAGE, Keith (Keith)" To: Mary Barnes Thread-Topic: [dispatch] Use of BFCP or MSRP over datachannel or websocket Thread-Index: Ac4rsMGiPKz1pFC/QlekwsQdT+Np8QAC46UAA2LP3XA= Date: Mon, 15 Apr 2013 12:14:41 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B027EED@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 12:15:07 -0000 It appears to me that we are fine in the area of non-WebRTC usage. We know = what we are doing. When it comes to webRTC usage, then we have two options. That implies to me= either this document needs to include considerations of why it might be us= ed rather than the data channel versus webrtc, or it needs to be decided th= at some other document should cover it - but webrtc owns no such document. Dispatch to me needs to decide whether this document should have those cons= iderations, or whether some other document should be provided. Regards Keith > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > Sent: 28 March 2013 14:58 > To: DRAGE, Keith (Keith) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket >=20 > I don't think it's the job of dispatch or BFCPbis WG to define or even > make recommendations for RTCWEB. That choice is up to the RTCWEB WG > and it shouldn't be influencing this work. There are applications > other than RTCWEB that can and will make use of BFCPbis over > websockets. I really don't understand why we are getting so hung up > on this - it's the BFCP messages themselves that are important - how > one chooses to transport is up to the application. >=20 > Mary. >=20 > On Thu, Mar 28, 2013 at 7:35 AM, DRAGE, Keith (Keith) > wrote: > > From what I have seen of the discussion so far, there appears to be a > body of support that there is a use case for both BFCP and MSRP over > websocket, for use in a non-rtcweb environment. > > > > If when we get to the rtcweb environment we allow this, and also allow = a > usage over datachannel version, we essentially have two solutions in the > market place. > > > > If that occurs, what guidance will we give to a rtcweb developer as to > which to implement? > > > > Or do we envisage that only one will be allowed (and if so which) in an > rtcweb environment? > > > > > > > > Regards > > > > Keith > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From ibc@aliax.net Mon Apr 15 05:27:36 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BC221F826B for ; Mon, 15 Apr 2013 05:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEh5eT63XPKb for ; Mon, 15 Apr 2013 05:27:35 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4214521F93B4 for ; Mon, 15 Apr 2013 05:27:35 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id n41so2125210qco.7 for ; Mon, 15 Apr 2013 05:27:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=7lmlFm4rutcNQXD24GUZibkbisJFFYzhJzpoN0yWEQk=; b=mImqLRph5TdWex0im+HMp44+oVuNWR/HrXkNIlj7mzkW7Dq4JTsSjgc+ToTTqq10wr GXeWFEckUVFpk0Oud3mf7VRj45ZNiHRCIs1ofhBXhkQIHej0mkzGgsQpQqxLORYKPiHt cAXGNIpc7B80qfIVhCxaJfufoDziJJt2MNsemzYdSUZtw9Sy+K0GahE6tRpR9u9GTPcM GjSgGayWzJxn4pXeACwNN3+ShUHBUcUtQePy/pwx/w3A6manx69lU1gr06W1HTQoXJok ZJTBb4WZpsqu2gRfcpgmhMKGe5gBmbnLGdInh+uudEyKQAcSzSrHqz2vVfTDzWhC6Djl jGxg== X-Received: by 10.49.74.226 with SMTP id x2mr25576948qev.63.1366028848894; Mon, 15 Apr 2013 05:27:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Mon, 15 Apr 2013 05:27:08 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B027EED@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B027EED@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 15 Apr 2013 14:27:08 +0200 Message-ID: To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl5Vdd7/H1CH9zJQHWVxDDLgPsj5k0DEEyedI5aAXGQGa0TNKVjTXMBslmTz7doiL6g/aHa Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 12:27:36 -0000 2013/4/15 DRAGE, Keith (Keith) : > It appears to me that we are fine in the area of non-WebRTC usage. We kno= w what we are doing. > > When it comes to webRTC usage, then we have two options. That implies to = me either this document needs to include considerations of why it might be = used rather than the data channel versus webrtc, or it needs to be decided = that some other document should cover it - but webrtc owns no such document= . > > Dispatch to me needs to decide whether this document should have those co= nsiderations, or whether some other document should be provided. I agree. Just one consideration more: This draft is just intended for a BFCP WebSocket Client to establish a BFCP session with a BFCP WebSocket Server (terms defined within the drat [*]), thus the draft should state that it's not possible for a BFCP WebSocket Client to establish a session with another BFCP WebSocket Client or with any other BFCP peer that is not a BFCP WebSocket Server (and given WebSocket nature I don't expect at all that there will be BCFP nodes behaving as both a WS client and a WS server). Another option would be defining the concept of "BCFP relay server" but IMHO that is out of the scope of this specification. May be another document for this purpose? Regards. [*] http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00#sec= tion-2.1 -- I=C3=B1aki Baz Castillo From gsalguei@cisco.com Mon Apr 15 08:58:39 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C1E21F868B for ; Mon, 15 Apr 2013 08:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njiST7ZUk86F for ; Mon, 15 Apr 2013 08:58:38 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id AC81121F943C for ; Mon, 15 Apr 2013 08:57:22 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3FFurLa010400 for ; Mon, 15 Apr 2013 11:56:54 -0400 (EDT) Received: from rtp-gsalguei-8916.cisco.com (rtp-gsalguei-8916.cisco.com [10.116.132.55]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3FFur4H029460; Mon, 15 Apr 2013 11:56:53 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Gonzalo Salgueiro In-Reply-To: Date: Mon, 15 Apr 2013 11:56:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B027EED@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1503) Cc: dispatch@ietf.org Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:58:40 -0000 On Apr 15, 2013, at 8:27 AM, I=F1aki Baz Castillo wrote: > 2013/4/15 DRAGE, Keith (Keith) : >> It appears to me that we are fine in the area of non-WebRTC usage. We = know what we are doing. >>=20 >> When it comes to webRTC usage, then we have two options. That implies = to me either this document needs to include considerations of why it = might be used rather than the data channel versus webrtc, or it needs to = be decided that some other document should cover it - but webrtc owns no = such document. >>=20 >> Dispatch to me needs to decide whether this document should have = those considerations, or whether some other document should be provided. >=20 > I agree. +1 Having a section in this document discussing typical use cases, scope, = limitations and advantages/disadvantages of other similar transport = mechanisms seems entirely reasonable for this document. > Just one consideration more: This draft is just intended for a BFCP > WebSocket Client to establish a BFCP session with a BFCP WebSocket > Server (terms defined within the drat [*]), thus the draft should > state that it's not possible for a BFCP WebSocket Client to establish > a session with another BFCP WebSocket Client or with any other BFCP > peer that is not a BFCP WebSocket Server (and given WebSocket nature I > don't expect at all that there will be BCFP nodes behaving as both a > WS client and a WS server). >=20 > Another option would be defining the concept of "BCFP relay server" > but IMHO that is out of the scope of this specification. May be > another document for this purpose? I think this is a future consideration for another document. Gonzalo >=20 >=20 > Regards. >=20 >=20 > [*] = http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00#sectio= n-2.1 >=20 >=20 > -- > I=F1aki Baz Castillo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From aaron@thinkingphones.com Mon Apr 15 14:17:00 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99BF21F91A5 for ; Mon, 15 Apr 2013 14:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBizyDrZgzOg for ; Mon, 15 Apr 2013 14:16:59 -0700 (PDT) Received: from hub021-nj-7.exch021.serverdata.net (hub021-nj-7.exch021.serverdata.net [206.225.164.223]) by ietfa.amsl.com (Postfix) with ESMTP id F10B521F9380 for ; Mon, 15 Apr 2013 14:16:58 -0700 (PDT) Received: from MBX021-E2-NJ-2.exch021.domain.local ([10.240.4.54]) by HUB021-NJ-7.exch021.domain.local ([10.240.4.114]) with mapi id 14.02.0318.001; Mon, 15 Apr 2013 14:16:58 -0700 From: Aaron Evans To: "dispatch@ietf.org" Thread-Topic: [dispatch] Fwd: I-D Action: draft-ivov-xmpp-cusax-04.txt Thread-Index: AQHOMi0X6RixO+ZjNECZCGJWfMsAqJjKupoQgA0eFIA= Date: Mon, 15 Apr 2013 21:16:58 +0000 Message-ID: References: <515E42B5.6010504@stpeter.im> <515F1AAD.9080301@jitsi.org> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.41.29.45] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "emcho@jitsi.org" Subject: Re: [dispatch] Fwd: I-D Action: draft-ivov-xmpp-cusax-04.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 18:33:32 -0000 Emil, I read through the latest draft and I think it looks great. =20 This document formalizes a lot of the concepts that we've been trying to im= plement with our UCaaS offering. I also see some other ideas in here that= I think we will consider integrating into our service.=20 -aaron ------------------------------------------------------------ Aaron Evans VP, Engineering P: 613.482.0179=A0 C: 613.355.7263=20 aaron@thinkingphones.com -----Original Message----- From: Emil Ivov [mailto:emcho@jitsi.org]=20 Sent: Friday, April 05, 2013 2:41 PM To: Aaron Evans Subject: Fwd: [dispatch] Fwd: I-D Action: draft-ivov-xmpp-cusax-04.txt Hey Aaron, I already mentioned our CUSAX document. Since you guys have been actively using this model, could I please ask you = to have a look at it and send us any feedback on the DISPATCH mailing list? It's relatively short and at this point even just sayi= ng that you've read it and it makes sense to you is helpful. Cheers, Emil -------- Original Message -------- Subject: [dispatch] Fwd: I-D Action: draft-ivov-xmpp-cusax-04.txt Date: Thu, 04 Apr 2013 21:19:17 -0600 From: Peter Saint-Andre To: DISPATCH FYI. -------- Original Message -------- Subject: I-D Action: draft-ivov-xmpp-cusax-04.txt Date: Thu, 04 Apr 2013 20:16:30 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) Author(s) : Emil Ivov Peter Saint-Andre Enrico Marocco Filename : draft-ivov-xmpp-cusax-04.txt Pages : 11 Date : 2013-04-04 Abstract: This document describes suggested practices for combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). Such practices aim to provide a single fully featured real-time communication service by using complementary subsets of features from each of the protocols. Typically such subsets would include telephony capabilities from SIP and instant messaging and presence capabilities from XMPP. This specification does not define any new protocols or syntax for either SIP or XMPP. However, implementing it may require modifying or at least reconfiguring existing client and server-side software. Also, it is not the purpose of this document to make recommendations as to whether or not such combined use should be preferred to the mechanisms provided natively by each protocol (for example, SIP's SIMPLE or XMPP's Jingle). It merely aims to provide guidance to those who are interested in such a combined use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax There's also a htmlized version available at: http://tools.ietf.org/html/draft-ivov-xmpp-cusax-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ivov-xmpp-cusax-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From oej@edvina.net Sun Apr 21 04:25:39 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CAB21F8E96 for ; Sun, 21 Apr 2013 04:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNh5QIGH7J5a for ; Sun, 21 Apr 2013 04:25:39 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0836F21F8E04 for ; Sun, 21 Apr 2013 04:25:39 -0700 (PDT) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E459493C1AF; Sun, 21 Apr 2013 11:25:37 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" Date: Sun, 21 Apr 2013 13:25:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "dispatch@ietf.org list" X-Mailer: Apple Mail (2.1503) Subject: [dispatch] Fwd: DANE SRV draft and SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 11:25:39 -0000 Hi! Looking at DANE for SIP, I mailed out some thoughts on the DANE mailing = list. If we come to the conclusion that RFC 5922 will need to be updated - will this work be = done in Dispatch or Dane or somewhere else? DANE also has impacts on SIP Identity as an alternative discovery = mechanism for domain certificates (replacing HTTPS). /O Vidarebefordrat brev: > Fr=E5n: "Olle E. Johansson" > =C4mne: DANE SRV draft and SIP > Datum: 21 april 2013 12:27:47 CEST > Till: dane WG list > Kopia: "Olle E. Johansson" >=20 > Hi! >=20 > Looking at the DANE SRV draft with my SIP eyes I realize that there's = a lot of work to be done to get this > to work with SIP.=20 >=20 > SIP has no StartTLS, we use NAPTR records to select transport. The = NAPTR points to a SRV > name that resolves into a set of host names. >=20 > The SIP Domain certificates RFC - http://tools.ietf.org/html/rfc5922 - = specificies matching a=20 > given SIP URI with a certificate. The matching is done on service = domain either with=20 > a ALT name URI, like sip:ietf.org or a DNS name, like ietf.org - but = not the host name. >=20 > I personally agree with the policy in the DANE SRV draft that we = should match on the > SRV hostname used to get A/AAAA records when using DNSsec. For this to = work, > the path from the SIP URI over NAPTR to SRV and hostnames needs to be = fully > signed in and verified in the DNS. This is going to require an update = to 5922. >=20 > The final question is how to handle this without SNI. The certificates = for both > DANE verification and RFC 5922 plus "old-style" verification with the = sip > domain in the CN seems like a complicated mess to manage. >=20 > Food for thought on a sunny Sunday. >=20 > The SRV draft is not clear on how to use Subject AltNames of various = types, > and doesn't mention NAPTR. I am not personally aware of other = protocols using > this setup, so maybe this requires a very SIP specfic draft, following = the wake of the > smtp work. >=20 > /O >=20 From emil@sip-communicator.org Sun Apr 21 13:43:12 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1F221F93D7 for ; Sun, 21 Apr 2013 13:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 304OFqbcqcdj for ; Sun, 21 Apr 2013 13:43:11 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6261421F93D6 for ; Sun, 21 Apr 2013 13:43:11 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id m1so5610283wea.13 for ; Sun, 21 Apr 2013 13:43:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding :x-gm-message-state; bh=s2gjexYdgBLJACrfi2Fo6NtWsVhT4tVzy98O1B+qmxQ=; b=gi/G8HfgUfEMWfsrVMa3e8C5kB2GXY841EkWU04cfWR34+omKka61gXfA53UYWjHU+ qcF6+OPFJMoAuhKaRSBmSd1gHKEgJMFOYfoF/+nGLvGYcDz4lWOJ7Joqe762ZjfKa1lR QxuivIKHDodTwUw/y6uuPB4qCfSoupJMV1MF+6fYoup+0Zw41SbqD7T6Cgs4BVMsHK6p o4SqJT2yHVuDX82bvZ0l2qUewoTS6LAy3ufVr+o17ytpR5hCP2/f+WvvhOobVzN5ZJBY n1rzjxwabmaSzQFVWgj/gQb09ZLTx6RibdguUFFry0KuTQqbQTmYsTan68fbYKbjkXZK QcRA== X-Received: by 10.194.88.138 with SMTP id bg10mr46010708wjb.13.1366576990387; Sun, 21 Apr 2013 13:43:10 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:4082:4f0d:2324:5fce]) by mx.google.com with ESMTPSA id ge7sm15459153wic.0.2013.04.21.13.43.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Apr 2013 13:43:09 -0700 (PDT) Message-ID: <51744F5B.8010506@jitsi.org> Date: Sun, 21 Apr 2013 22:43:07 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnFXeGj7CtC0q/3423iYyECG+9pVK1wsh0TJckO4OEWiIHxlhSs+FnXDb0HWm6OjxHfN3J1 Subject: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 20:43:12 -0000 Hey all, I have been looking at RFC4575 and wondering what the best way would be for a mixer to announce that a conference has an associated chatroom (e.g. an XMPP MUC) available at a certain address. This would allow UAs that support MUCs can join there too. >From what I see the most reasonable way to do this would be a , like this for example: sip:conf545@h323.example.com TTI Bridge participation xmpp:conf545@conference.example.com Multi-User Chat 545 impp-participation Another option would be to use the same but place it ina a element instead: http://sharepoint/salesgroup/ web-page xmpp:conf545@conference.example.com Multi-User Chat 545 impp-participation Does any of the above make sense? In case no other mechanism allows for the same thing in a simpler way, then could we maybe put one of the two on paper? Emil -- https://jitsi.org From saul@ag-projects.com Mon Apr 22 00:53:31 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186EF21F8DB9 for ; Mon, 22 Apr 2013 00:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsPLbsOXHIIX for ; Mon, 22 Apr 2013 00:53:30 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABEA21F8B98 for ; Mon, 22 Apr 2013 00:53:29 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 90452B35DD; Mon, 22 Apr 2013 09:53:28 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id AAD96B017A; Mon, 22 Apr 2013 09:53:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <51744F5B.8010506@jitsi.org> Date: Mon, 22 Apr 2013 09:53:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0BFDB465-BACA-4411-A8F8-203506EA0422@ag-projects.com> References: <51744F5B.8010506@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.1085) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 07:53:31 -0000 Hi Emil! On Apr 21, 2013, at 10:43 PM, Emil Ivov wrote: > Hey all, >=20 > I have been looking at RFC4575 and wondering what the best way would = be > for a mixer to announce that a conference has an associated chatroom > (e.g. an XMPP MUC) available at a certain address. This would allow = UAs > that support MUCs can join there too. >=20 > =46rom what I see the most reasonable way to do this would be a > , like this for example: >=20 > > > sip:conf545@h323.example.com > TTI Bridge > participation > > > xmpp:conf545@conference.example.com > Multi-User Chat 545 > impp-participation > > >=20 I think the above does make sense, now, would the same URI be usable = with Jingle or is intended for MUC only? > Another option would be to use the same but place it ina a > element instead: >=20 > > > http://sharepoint/salesgroup/ > web-page > > > xmpp:conf545@conference.example.com > Multi-User Chat 545 > impp-participation > > >=20 > Does any of the above make sense? In case no other mechanism allows = for > the same thing in a simpler way, then could we maybe put one of the = two > on paper? >=20 This second approach would require a new entry in the IANA registry for = that 'purpose' element right? In any case, this one could also make = sense, I guess it depends on the scenario. Assuming your scenario is Jitsi's use case, that is, the audio / video = conference is held by some entity and the MUC by some other, IMHO this = second approach makes more sense. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From rifatyu@avaya.com Mon Apr 22 06:29:26 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3BF21F85BF for ; Mon, 22 Apr 2013 06:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uP8Eo772cL8F for ; Mon, 22 Apr 2013 06:29:25 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB1221F859A for ; Mon, 22 Apr 2013 06:29:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAL06dVGHCzI1/2dsb2JhbABPgmUhNsB+gQcWdIIfAQEBAQMBAQEPVgYLDAQCAQgNBAQBAQEKHQcnCxQJCAIEAQ0FCBqHcgELn2KcKhMEjw4xBwaCYGEDiFWUbopsgwyCKA X-IronPort-AV: E=Sophos;i="4.87,526,1363147200"; d="scan'208";a="8053371" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 Apr 2013 09:29:24 -0400 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Apr 2013 09:26:21 -0400 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.02.0328.009; Mon, 22 Apr 2013 09:29:24 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= , "Emil Ivov" Thread-Topic: [dispatch] Announcing a MUC with RFC4575 Thread-Index: AQHOPtDZq1kiEme7RESI7iVwh1KKCJjiIk4AgAAZnkA= Date: Mon, 22 Apr 2013 13:29:23 +0000 Message-ID: References: <51744F5B.8010506@jitsi.org> <0BFDB465-BACA-4411-A8F8-203506EA0422@ag-projects.com> In-Reply-To: <0BFDB465-BACA-4411-A8F8-203506EA0422@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.47] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 13:29:26 -0000 Emil, You may want to look at the following CCMP draft: https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp-indication/?incl= ude_text=3D1 We considered the two options you mentioned below and decided that the serv= ices-uris option is more appropriate. As Sa=FAl Ibarra Corretg=E9 mentioned this requires IANA registration for t= he new purpose value, but it can be done in the same document (see section = 4 of the document above). Regards, Rifaat > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Sa=FAl Ibarra Corretg=E9 > Sent: Monday, April 22, 2013 3:53 AM > To: Emil Ivov > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Announcing a MUC with RFC4575 >=20 > Hi Emil! >=20 > On Apr 21, 2013, at 10:43 PM, Emil Ivov wrote: >=20 > > Hey all, > > > > I have been looking at RFC4575 and wondering what the best way would > be > > for a mixer to announce that a conference has an associated chatroom > > (e.g. an XMPP MUC) available at a certain address. This would allow > UAs > > that support MUCs can join there too. > > > > From what I see the most reasonable way to do this would be a > > , like this for example: > > > > > > > > sip:conf545@h323.example.com > > TTI Bridge > > participation > > > > > > xmpp:conf545@conference.example.com > > Multi-User Chat 545 > > impp-participation > > > > > > >=20 > I think the above does make sense, now, would the same URI be usable > with Jingle or is intended for MUC only? >=20 > > Another option would be to use the same but place it ina a > > element instead: > > > > > > > > http://sharepoint/salesgroup/ > > web-page > > > > > > xmpp:conf545@conference.example.com > > Multi-User Chat 545 > > impp-participation > > > > > > > > Does any of the above make sense? In case no other mechanism allows > for > > the same thing in a simpler way, then could we maybe put one of the > two > > on paper? > > >=20 > This second approach would require a new entry in the IANA registry for > that 'purpose' element right? In any case, this one could also make > sense, I guess it depends on the scenario. >=20 > Assuming your scenario is Jitsi's use case, that is, the audio / video > conference is held by some entity and the MUC by some other, IMHO this > second approach makes more sense. >=20 >=20 > Regards, >=20 > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Mon Apr 22 08:18:47 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F76D21E808A for ; Mon, 22 Apr 2013 08:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOGjfQ-5ysL2 for ; Mon, 22 Apr 2013 08:18:46 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF8421E8082 for ; Mon, 22 Apr 2013 08:18:46 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id 1so4182913qee.32 for ; Mon, 22 Apr 2013 08:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=lTg3QjLa6P0kZwDVzgrHPX/gLP/Kems/ltv3DNv5B7M=; b=Gw2oEEAIXM+ncACZnFkXxMicH/V06Dp7W3LQRPh7OJib3mrOotakZOvRGQhX3kqPBg nLHsLa3oO0mWL+fO9dNgaikruI6RkOVmACk+nI71QmaMoxzg9PNBLz6g+oqNzHoNdTu4 Z2ui5OWxya3SJI8BvKtjl3Fkt5LA25zLlf9fzCIZxag9UDfFn8486z2MxtMRNvhLUm/q cuXrwRw5YRuVgn0xK0u88Zu82yXo6kt6WmULLVymz9iS/CbN0F1FPosllsJIfCmSUixH sVKFhavv6kaqSFMMRpEd0dZWA7yD/XUMoQtZ92ILOevFo9gQjWT3qUwViZf7+sEp3eDu Lh6g== MIME-Version: 1.0 X-Received: by 10.229.101.1 with SMTP id a1mr9107879qco.41.1366643925982; Mon, 22 Apr 2013 08:18:45 -0700 (PDT) Received: by 10.49.117.163 with HTTP; Mon, 22 Apr 2013 08:18:45 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Apr 2013 10:18:45 -0500 Message-ID: From: Mary Barnes To: "Olle E. Johansson" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Fwd: DANE SRV draft and SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 15:18:47 -0000 Updates to 5922 should happen in the RAI area. We can discuss on DISPATCH the need for the updates and then decide exactly where the work should be done. I would think the work would be done in SIPCORE, since 5922 updates RFC 3261. Thanks, Mary. On Sun, Apr 21, 2013 at 6:25 AM, Olle E. Johansson wrote: > Hi! > > Looking at DANE for SIP, I mailed out some thoughts on the DANE mailing l= ist. If we come to > the conclusion that RFC 5922 will need to be updated - will this work be = done in Dispatch > or Dane or somewhere else? > > DANE also has impacts on SIP Identity as an alternative discovery mechani= sm for > domain certificates (replacing HTTPS). > > /O > > Vidarebefordrat brev: > >> Fr=E5n: "Olle E. Johansson" >> =C4mne: DANE SRV draft and SIP >> Datum: 21 april 2013 12:27:47 CEST >> Till: dane WG list >> Kopia: "Olle E. Johansson" >> >> Hi! >> >> Looking at the DANE SRV draft with my SIP eyes I realize that there's a = lot of work to be done to get this >> to work with SIP. >> >> SIP has no StartTLS, we use NAPTR records to select transport. The NAPTR= points to a SRV >> name that resolves into a set of host names. >> >> The SIP Domain certificates RFC - http://tools.ietf.org/html/rfc5922 - s= pecificies matching a >> given SIP URI with a certificate. The matching is done on service domain= either with >> a ALT name URI, like sip:ietf.org or a DNS name, like ietf.org - but not= the host name. >> >> I personally agree with the policy in the DANE SRV draft that we should = match on the >> SRV hostname used to get A/AAAA records when using DNSsec. For this to w= ork, >> the path from the SIP URI over NAPTR to SRV and hostnames needs to be fu= lly >> signed in and verified in the DNS. This is going to require an update to= 5922. >> >> The final question is how to handle this without SNI. The certificates f= or both >> DANE verification and RFC 5922 plus "old-style" verification with the si= p >> domain in the CN seems like a complicated mess to manage. >> >> Food for thought on a sunny Sunday. >> >> The SRV draft is not clear on how to use Subject AltNames of various typ= es, >> and doesn't mention NAPTR. I am not personally aware of other protocols = using >> this setup, so maybe this requires a very SIP specfic draft, following t= he wake of the >> smtp work. >> >> /O >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From oej@edvina.net Mon Apr 22 08:34:11 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EFD21F8E2C for ; Mon, 22 Apr 2013 08:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyoVeTaJob8N for ; Mon, 22 Apr 2013 08:34:10 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id E554521F8DFC for ; Mon, 22 Apr 2013 08:34:09 -0700 (PDT) Received: from [192.168.40.23] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id A965993C2A2; Mon, 22 Apr 2013 15:34:07 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: Date: Mon, 22 Apr 2013 17:34:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <23939CF8-ED29-4A11-9E40-BA44FC3EBD8C@edvina.net> References: To: Mary Barnes X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Fwd: DANE SRV draft and SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 15:34:11 -0000 22 apr 2013 kl. 17:18 skrev Mary Barnes : > Updates to 5922 should happen in the RAI area. We can discuss on > DISPATCH the need for the updates and then decide exactly where the > work should be done. I would think the work would be done in SIPCORE, > since 5922 updates RFC 3261. A very important change is the SIP URI to certificate matching. In SIP, we have specified in RFC 5922 that the certificate should match the requested domain, not the host name choosen by the RFC 3263 process. In the current DANE drafts for SRV records the matching is done by the host name choosen as a result in the SRV lookups. This requires a validated trusted chain from the NAPTR down to the SRV and A/AAAA lookup. I can see the point of not having to get new or updated certificates for every domain added to a hosted service.=20 5922 states the following: SIP domain identity: An identity (e.g., "sip:example.com") contained in an X.509 certificate bound to a subject that identifies the subject as an authoritative SIP server for a domain. With DNSsec, the signed DNS zone binds a domain to a server, and the X.509 certificates identifies the server, but doesn't say anything about being authoritative for a domain. Validating certs by host name and binding authority in DNS=20 is a normative change to 5922. I haven't spent any bandwidth on considering SIP identity yet, but it is applicable there too. /O >=20 > Thanks, > Mary. >=20 > On Sun, Apr 21, 2013 at 6:25 AM, Olle E. Johansson = wrote: >> Hi! >>=20 >> Looking at DANE for SIP, I mailed out some thoughts on the DANE = mailing list. If we come to >> the conclusion that RFC 5922 will need to be updated - will this work = be done in Dispatch >> or Dane or somewhere else? >>=20 >> DANE also has impacts on SIP Identity as an alternative discovery = mechanism for >> domain certificates (replacing HTTPS). >>=20 >> /O >>=20 >> Vidarebefordrat brev: >>=20 >>> Fr=E5n: "Olle E. Johansson" >>> =C4mne: DANE SRV draft and SIP >>> Datum: 21 april 2013 12:27:47 CEST >>> Till: dane WG list >>> Kopia: "Olle E. Johansson" >>>=20 >>> Hi! >>>=20 >>> Looking at the DANE SRV draft with my SIP eyes I realize that = there's a lot of work to be done to get this >>> to work with SIP. >>>=20 >>> SIP has no StartTLS, we use NAPTR records to select transport. The = NAPTR points to a SRV >>> name that resolves into a set of host names. >>>=20 >>> The SIP Domain certificates RFC - http://tools.ietf.org/html/rfc5922 = - specificies matching a >>> given SIP URI with a certificate. The matching is done on service = domain either with >>> a ALT name URI, like sip:ietf.org or a DNS name, like ietf.org - but = not the host name. >>>=20 >>> I personally agree with the policy in the DANE SRV draft that we = should match on the >>> SRV hostname used to get A/AAAA records when using DNSsec. For this = to work, >>> the path from the SIP URI over NAPTR to SRV and hostnames needs to = be fully >>> signed in and verified in the DNS. This is going to require an = update to 5922. >>>=20 >>> The final question is how to handle this without SNI. The = certificates for both >>> DANE verification and RFC 5922 plus "old-style" verification with = the sip >>> domain in the CN seems like a complicated mess to manage. >>>=20 >>> Food for thought on a sunny Sunday. >>>=20 >>> The SRV draft is not clear on how to use Subject AltNames of various = types, >>> and doesn't mention NAPTR. I am not personally aware of other = protocols using >>> this setup, so maybe this requires a very SIP specfic draft, = following the wake of the >>> smtp work. >>>=20 >>> /O >>>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From vkg@bell-labs.com Mon Apr 22 09:02:00 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA51D21F89DE for ; Mon, 22 Apr 2013 09:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gnupOTbbnOe for ; Mon, 22 Apr 2013 09:02:00 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id D439A21F87FB for ; Mon, 22 Apr 2013 09:01:59 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r3MG1sWx006655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Apr 2013 11:01:54 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r3MG1rjW014974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Apr 2013 11:01:54 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r3MG1rIV001546; Mon, 22 Apr 2013 11:01:53 -0500 (CDT) Message-ID: <51755FB4.8080804@bell-labs.com> Date: Mon, 22 Apr 2013 11:05:08 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Olle E. Johansson" References: <23939CF8-ED29-4A11-9E40-BA44FC3EBD8C@edvina.net> In-Reply-To: <23939CF8-ED29-4A11-9E40-BA44FC3EBD8C@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: DANE SRV draft and SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 16:02:01 -0000 On 04/22/2013 10:34 AM, Olle E. Johansson wrote: > A very important change is the SIP URI to certificate matching. > In SIP, we have specified in RFC 5922 that the certificate should match > the requested domain, not the host name choosen by the RFC 3263 process. Olle: Indeed. I think we have to be careful here before changing rfc5922. The mechanism in rfc5922 was designed specifically to validate domains, not individual hosts. More inline (at the end). > In the current DANE drafts for SRV records the matching is done by > the host name choosen as a result in the SRV lookups. This requires > a validated trusted chain from the NAPTR down to the SRV and > A/AAAA lookup. > > I can see the point of not having to get new or updated certificates for > every domain added to a hosted service. > > 5922 states the following: > > SIP domain identity: An identity (e.g., "sip:example.com") contained > in an X.509 certificate bound to a subject that identifies the > subject as an authoritative SIP server for a domain. > > With DNSsec, the signed DNS zone binds a domain to a server, > and the X.509 certificates identifies the server, but doesn't > say anything about being authoritative for a domain. > > Validating certs by host name and binding authority in DNS > is a normative change to 5922. I would like to understand DANE's approach better before we proceed to modify rfc5922. Unfortunately, I am swamped for the next couple of weeks, but I will like to spare some time after that to understand better your motivation. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From keith.drage@alcatel-lucent.com Mon Apr 22 09:42:58 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258FA21F9382 for ; Mon, 22 Apr 2013 09:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5w8MEwiXoQB for ; Mon, 22 Apr 2013 09:42:57 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5897D21F937A for ; Mon, 22 Apr 2013 09:42:57 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r3MGgqaJ028434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Apr 2013 11:42:52 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r3MGgogU007945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Apr 2013 12:42:50 -0400 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 22 Apr 2013 12:42:50 -0400 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 22 Apr 2013 18:42:44 +0200 From: "DRAGE, Keith (Keith)" To: Mary Barnes , "Olle E. Johansson" Thread-Topic: [dispatch] Fwd: DANE SRV draft and SIP Thread-Index: AQHOP2y+JQdfpUTyvEyVVtYnjH6YeZjib2lg Date: Mon, 22 Apr 2013 16:42:43 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B02B11A@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Fwd: DANE SRV draft and SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 16:42:58 -0000 While there was never a formal mailing list poll (because we never got to t= he point of needing a 3261bis), I think there was a considerable body of op= inion during the development of domain-certs that the material would form p= art of any 3261bis work. That I think lends support to any further work bei= ng done in sipcore. I do suggest you look back in the archives for the mailing list discussion = on domain-certs. You'll find it on the sip (not sipcore) mailing list archi= ve. You'll find the WG discussion between Feb 2008 and April 2009 with the = IESG approval discussion continuing until May 2010. Regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Mary Barnes > Sent: 22 April 2013 16:19 > To: Olle E. Johansson > Cc: dispatch@ietf.org list > Subject: Re: [dispatch] Fwd: DANE SRV draft and SIP >=20 > Updates to 5922 should happen in the RAI area. We can discuss on > DISPATCH the need for the updates and then decide exactly where the > work should be done. I would think the work would be done in SIPCORE, > since 5922 updates RFC 3261. >=20 > Thanks, > Mary. >=20 > On Sun, Apr 21, 2013 at 6:25 AM, Olle E. Johansson wrote= : > > Hi! > > > > Looking at DANE for SIP, I mailed out some thoughts on the DANE mailing > list. If we come to > > the conclusion that RFC 5922 will need to be updated - will this work b= e > done in Dispatch > > or Dane or somewhere else? > > > > DANE also has impacts on SIP Identity as an alternative discovery > mechanism for > > domain certificates (replacing HTTPS). > > > > /O > > > > Vidarebefordrat brev: > > > >> Fr=E5n: "Olle E. Johansson" > >> =C4mne: DANE SRV draft and SIP > >> Datum: 21 april 2013 12:27:47 CEST > >> Till: dane WG list > >> Kopia: "Olle E. Johansson" > >> > >> Hi! > >> > >> Looking at the DANE SRV draft with my SIP eyes I realize that there's = a > lot of work to be done to get this > >> to work with SIP. > >> > >> SIP has no StartTLS, we use NAPTR records to select transport. The > NAPTR points to a SRV > >> name that resolves into a set of host names. > >> > >> The SIP Domain certificates RFC - http://tools.ietf.org/html/rfc5922 - > specificies matching a > >> given SIP URI with a certificate. The matching is done on service > domain either with > >> a ALT name URI, like sip:ietf.org or a DNS name, like ietf.org - but > not the host name. > >> > >> I personally agree with the policy in the DANE SRV draft that we shoul= d > match on the > >> SRV hostname used to get A/AAAA records when using DNSsec. For this to > work, > >> the path from the SIP URI over NAPTR to SRV and hostnames needs to be > fully > >> signed in and verified in the DNS. This is going to require an update > to 5922. > >> > >> The final question is how to handle this without SNI. The certificates > for both > >> DANE verification and RFC 5922 plus "old-style" verification with the > sip > >> domain in the CN seems like a complicated mess to manage. > >> > >> Food for thought on a sunny Sunday. > >> > >> The SRV draft is not clear on how to use Subject AltNames of various > types, > >> and doesn't mention NAPTR. I am not personally aware of other protocol= s > using > >> this setup, so maybe this requires a very SIP specfic draft, following > the wake of the > >> smtp work. > >> > >> /O > >> > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From stpeter@stpeter.im Mon Apr 22 09:48:34 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D951721F93C7 for ; Mon, 22 Apr 2013 09:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHMhUxQ0NUzn for ; Mon, 22 Apr 2013 09:48:33 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AABF921F93B9 for ; Mon, 22 Apr 2013 09:48:33 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0023741026; Mon, 22 Apr 2013 10:59:19 -0600 (MDT) Message-ID: <517569DF.9080303@stpeter.im> Date: Mon, 22 Apr 2013 10:48:31 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Olle E. Johansson" References: <23939CF8-ED29-4A11-9E40-BA44FC3EBD8C@edvina.net> In-Reply-To: <23939CF8-ED29-4A11-9E40-BA44FC3EBD8C@edvina.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Fwd: DANE SRV draft and SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 16:48:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/22/13 9:34 AM, Olle E. Johansson wrote: > > 22 apr 2013 kl. 17:18 skrev Mary Barnes > : > >> Updates to 5922 should happen in the RAI area. We can discuss >> on DISPATCH the need for the updates and then decide exactly >> where the work should be done. I would think the work would be >> done in SIPCORE, since 5922 updates RFC 3261. > > A very important change is the SIP URI to certificate matching. In > SIP, we have specified in RFC 5922 that the certificate should > match the requested domain, not the host name choosen by the RFC > 3263 process. > > In the current DANE drafts for SRV records the matching is done by > the host name choosen as a result in the SRV lookups. This > requires a validated trusted chain from the NAPTR down to the SRV > and A/AAAA lookup. > > I can see the point of not having to get new or updated > certificates for every domain added to a hosted service. Yes, this is a huge problem for multi-tenanted services. We've been thinking about this for a while in the XMPP world. I suggest you have a look at http://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ (also in the RAI area, of course!) for some related considerations. XMPP too uses SRV (not NAPTR) but draft-dane-srv doesn't quite meet the needs of XMPP, either (Matt Miller and I are providing feedback to the DANE WG as needed). Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRdWnfAAoJEOoGpJErxa2p+rQP/39ppf+6eXnmIHqw4ofC/MOP 7xmjjYiYADpD/EY0Ltv48AykB7/ebE9a90PIa9FdKgphKLkVk5yYPR/TdrAjbVgL 3T++R6uHV7ORrhhwvBgiQZ+jkRA9l7IBmN5UV1C40IpfiURUXjffufipwhW8Hbts TzO5DYgufkkrAo8d3AajF2v4NhSI5qw5JInxZSig4FqznPpQoghg1out0XSfUCJ9 qGF+vP+Q9uUECXDSuw1IJzC/F+Vwd1Vb7070qmOcfH+opEofSUEw3p80zB7+aQnr MfH3DBNIQOySsgk1fUxv0jOBO3gd4iPBb7Dqp/f/e5Kf1JbL94frpnYZiXf/pUmU pSr2eAPCx6nBjVtr2IONWGqxO8WVF7SxqtzCnBpDKhCexlD6rzxDHmgAqZauqU2o tsFbr8SIaxcz5YxS5DKKav/IBViJ63yokSQXo/4iL4u0ATCvD4e30BYB7p2LgS5+ qi0KKYop0YSI5vyPz5mD+vYkeBCupNFKNOb/LyZAc5dkBRAMU4CnsZzWxijYFUb/ jO8+OSO7dG/ivCj4yo0xsMtzr3Q3dhqKOYiyv7SkI1Oxl8MepZf4HjfW8NH597uC d1wYzXEyoSPJkWXg9/LcKFrk5UAabu2buHpfs3B+pQzw1YhBJgFE/OJJx8wWfphM wKpQmPqyjsxaAGxe5pDc =nb63 -----END PGP SIGNATURE----- From oej@edvina.net Mon Apr 22 11:19:09 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E3121F8F3C for ; Mon, 22 Apr 2013 11:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ry-5yx8rnuGD for ; Mon, 22 Apr 2013 11:19:08 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAEE21F8E77 for ; Mon, 22 Apr 2013 11:19:07 -0700 (PDT) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 992CC93C1AF; Mon, 22 Apr 2013 18:19:06 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B02B11A@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Mon, 22 Apr 2013 20:18:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <667E20A3-B542-4C5D-B88D-200EA94EE3C7@edvina.net> References: <949EF20990823C4C85C18D59AA11AD8B02B11A@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] DANE SRV draft and SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 18:19:09 -0000 22 apr 2013 kl. 18:42 skrev "DRAGE, Keith (Keith)" = : > While there was never a formal mailing list poll (because we never got = to the point of needing a 3261bis), I think there was a considerable = body of opinion during the development of domain-certs that the material = would form part of any 3261bis work. That I think lends support to any = further work being done in sipcore. >=20 > I do suggest you look back in the archives for the mailing list = discussion on domain-certs. You'll find it on the sip (not sipcore) = mailing list archive. You'll find the WG discussion between Feb 2008 and = April 2009 with the IESG approval discussion continuing until May 2010. Keith, Thank you for the reference. Note that I'm not saying that RFC 5922 is wrong. The issue at hand is = that the DANE groups current RFC suggests a solution not compatible with 5922. We need to decide which = way to go. We could recommend that the DANE way is used when DNSsec and DANE = validation is possible, and keep RFC 5922 for other cases. Or update the recommendation in 5922 = to make sip with TLS better in regards to hosting larger amounts of domains. In any case, I think we need to do something to support DANE in SIP. Regards, /Olle >=20 > Regards >=20 > Keith >=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Mary Barnes >> Sent: 22 April 2013 16:19 >> To: Olle E. Johansson >> Cc: dispatch@ietf.org list >> Subject: Re: [dispatch] Fwd: DANE SRV draft and SIP >>=20 >> Updates to 5922 should happen in the RAI area. We can discuss on >> DISPATCH the need for the updates and then decide exactly where the >> work should be done. I would think the work would be done in = SIPCORE, >> since 5922 updates RFC 3261. >>=20 >> Thanks, >> Mary. >>=20 >> On Sun, Apr 21, 2013 at 6:25 AM, Olle E. Johansson = wrote: >>> Hi! >>>=20 >>> Looking at DANE for SIP, I mailed out some thoughts on the DANE = mailing >> list. If we come to >>> the conclusion that RFC 5922 will need to be updated - will this = work be >> done in Dispatch >>> or Dane or somewhere else? >>>=20 >>> DANE also has impacts on SIP Identity as an alternative discovery >> mechanism for >>> domain certificates (replacing HTTPS). >>>=20 >>> /O >>>=20 >>> Vidarebefordrat brev: >>>=20 >>>> Fr=E5n: "Olle E. Johansson" >>>> =C4mne: DANE SRV draft and SIP >>>> Datum: 21 april 2013 12:27:47 CEST >>>> Till: dane WG list >>>> Kopia: "Olle E. Johansson" >>>>=20 >>>> Hi! >>>>=20 >>>> Looking at the DANE SRV draft with my SIP eyes I realize that = there's a >> lot of work to be done to get this >>>> to work with SIP. >>>>=20 >>>> SIP has no StartTLS, we use NAPTR records to select transport. The >> NAPTR points to a SRV >>>> name that resolves into a set of host names. >>>>=20 >>>> The SIP Domain certificates RFC - = http://tools.ietf.org/html/rfc5922 - >> specificies matching a >>>> given SIP URI with a certificate. The matching is done on service >> domain either with >>>> a ALT name URI, like sip:ietf.org or a DNS name, like ietf.org - = but >> not the host name. >>>>=20 >>>> I personally agree with the policy in the DANE SRV draft that we = should >> match on the >>>> SRV hostname used to get A/AAAA records when using DNSsec. For this = to >> work, >>>> the path from the SIP URI over NAPTR to SRV and hostnames needs to = be >> fully >>>> signed in and verified in the DNS. This is going to require an = update >> to 5922. >>>>=20 >>>> The final question is how to handle this without SNI. The = certificates >> for both >>>> DANE verification and RFC 5922 plus "old-style" verification with = the >> sip >>>> domain in the CN seems like a complicated mess to manage. >>>>=20 >>>> Food for thought on a sunny Sunday. >>>>=20 >>>> The SRV draft is not clear on how to use Subject AltNames of = various >> types, >>>> and doesn't mention NAPTR. I am not personally aware of other = protocols >> using >>>> this setup, so maybe this requires a very SIP specfic draft, = following >> the wake of the >>>> smtp work. >>>>=20 >>>> /O >>>>=20 >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From stpeter@stpeter.im Mon Apr 22 11:28:24 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1065521F933F for ; Mon, 22 Apr 2013 11:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.979 X-Spam-Level: X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEFgqMhvkXOc for ; Mon, 22 Apr 2013 11:28:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E5CFA21F933B for ; Mon, 22 Apr 2013 11:28:22 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4FC7A41026; Mon, 22 Apr 2013 12:39:09 -0600 (MDT) Message-ID: <51758144.1090201@stpeter.im> Date: Mon, 22 Apr 2013 12:28:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Olle E. Johansson" References: <949EF20990823C4C85C18D59AA11AD8B02B11A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <667E20A3-B542-4C5D-B88D-200EA94EE3C7@edvina.net> In-Reply-To: <667E20A3-B542-4C5D-B88D-200EA94EE3C7@edvina.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] DANE SRV draft and SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 18:28:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/22/13 12:18 PM, Olle E. Johansson wrote: > > 22 apr 2013 kl. 18:42 skrev "DRAGE, Keith (Keith)" > : > >> While there was never a formal mailing list poll (because we >> never got to the point of needing a 3261bis), I think there was a >> considerable body of opinion during the development of >> domain-certs that the material would form part of any 3261bis >> work. That I think lends support to any further work being done >> in sipcore. >> >> I do suggest you look back in the archives for the mailing list >> discussion on domain-certs. You'll find it on the sip (not >> sipcore) mailing list archive. You'll find the WG discussion >> between Feb 2008 and April 2009 with the IESG approval discussion >> continuing until May 2010. > > Keith, Thank you for the reference. > > Note that I'm not saying that RFC 5922 is wrong. The issue at hand > is that the DANE groups current RFC suggests a solution not > compatible with 5922. We need to decide which way to go. > > We could recommend that the DANE way is used when DNSsec and DANE > validation is possible, and keep RFC 5922 for other cases. Well, it's clear to me that we wouldn't allow checking of the derived domain (in RFC 6125 terms) unless DNSSEC validation succeeds. Since that is currently a rare event, we'd just continue to do what RFC 5922 says, which in draft-ietf-xmpp-dna we call the PKI prooftype. > Or update the recommendation in 5922 to make sip with TLS better in > regards to hosting larger amounts of domains. I think that is somewhat a separate issue from defining the DANE prooftype, because other prooftypes might be possible or more deployable in the short term, such as the POSH prooftype that Matt Miller and I have defined in draft-miller-xmpp-posh-prooftype (but which is not specific to XMPP). Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRdYFEAAoJEOoGpJErxa2pLCoP/1wYQA2CGqmaCwtG0udAP9bL PyaYjqWqofvEdnJk/Nm/HKZdZ3MuGzpqydWo11Yi/GOyyjIzZrNQKZ2c4gPhCiNB KdOMiMGBU625vsCJjhu8E5b14sXc4lJc7iEf2dfmMQpwer26YmGrRpolVSsBZ/td 3FvkbPChbC9zg8YHSN9k9tkQlxfwwK5sjgIMDGtOhaKnhUBlIiGV0iTXZL1nkMdq X9DUWzlvCHxNHWB2W1nbtYagNWu6QaoJTI88O/5qcwP4pZsrHbhelvqeuERfF+sY sBIBrxYBNUhM9a7wWhxrlqSBeM/nt/oM46osV/sI5qrobkNs26l7hHkh/CVzpr/H 72c1PaujqKJx4Osidyi24a9Lc6JTke/v4gr+ObN9zDBaUvAcXghqk73j8P2rUsj+ T64/lN1n22G87d9sdi9X7RUdfTlPmg65CFmfhBMTfYnz2ZL7YzVxvnKs+Q/BF/1S 7pHMJoviKM7V1cx3OYaEBqFnnRzWOlcfrULzy0VrFw7IjxD6+W9RxGoi2Zv1R2xL tBy+FV9iUXS9CHyrEmjm+DYgqopg70PCaIEjHZzrC2SCbWw2DBbP0K/d5YL51Vmz Hyz8T3h4pSfgkwa/wPs7WeP6UrHV3Cz66077L+taLuT1NV7JP1lr9L8pLDMj6xQ8 fpkwx+0yZnAY8VBDp76A =6W3o -----END PGP SIGNATURE----- From oej@edvina.net Mon Apr 22 12:18:38 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E43C11E80EC for ; Mon, 22 Apr 2013 12:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPrJhg5z68ox for ; Mon, 22 Apr 2013 12:18:37 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id A36E211E80EA for ; Mon, 22 Apr 2013 12:18:33 -0700 (PDT) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 17E4393C1AF; Mon, 22 Apr 2013 19:18:32 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <51758144.1090201@stpeter.im> Date: Mon, 22 Apr 2013 21:18:31 +0200 Content-Transfer-Encoding: 7bit Message-Id: <460ABD43-9A44-428B-8326-DFAA5E6CFE29@edvina.net> References: <949EF20990823C4C85C18D59AA11AD8B02B11A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <667E20A3-B542-4C5D-B88D-200EA94EE3C7@edvina.net> <51758144.1090201@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] DANE SRV draft and SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 19:18:38 -0000 22 apr 2013 kl. 20:28 skrev Peter Saint-Andre : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 4/22/13 12:18 PM, Olle E. Johansson wrote: >> >> 22 apr 2013 kl. 18:42 skrev "DRAGE, Keith (Keith)" >> : >> >>> While there was never a formal mailing list poll (because we >>> never got to the point of needing a 3261bis), I think there was a >>> considerable body of opinion during the development of >>> domain-certs that the material would form part of any 3261bis >>> work. That I think lends support to any further work being done >>> in sipcore. >>> >>> I do suggest you look back in the archives for the mailing list >>> discussion on domain-certs. You'll find it on the sip (not >>> sipcore) mailing list archive. You'll find the WG discussion >>> between Feb 2008 and April 2009 with the IESG approval discussion >>> continuing until May 2010. >> >> Keith, Thank you for the reference. >> >> Note that I'm not saying that RFC 5922 is wrong. The issue at hand >> is that the DANE groups current RFC suggests a solution not >> compatible with 5922. We need to decide which way to go. >> >> We could recommend that the DANE way is used when DNSsec and DANE >> validation is possible, and keep RFC 5922 for other cases. > > Well, it's clear to me that we wouldn't allow checking of the derived > domain (in RFC 6125 terms) unless DNSSEC validation succeeds. Since > that is currently a rare event, we'd just continue to do what RFC 5922 > says, which in draft-ietf-xmpp-dna we call the PKI prooftype. I'm not sure that the certificates would be compatible, which is a problem. A non-DNSsec client following RFC 5922 requires one certificate with domain names and the DNSsec/DANE client would require host names in the same certificate - unless we have certificate selection (TNI). Being tricky one could possibly have the host name in the CN and add SIP domain URIs in subj alt names. > >> Or update the recommendation in 5922 to make sip with TLS better in >> regards to hosting larger amounts of domains. > > I think that is somewhat a separate issue from defining the DANE > prooftype, because other prooftypes might be possible or more > deployable in the short term, such as the POSH prooftype that Matt > Miller and I have defined in draft-miller-xmpp-posh-prooftype (but > which is not specific to XMPP). I need to read up on your drafts, but how do you handle certificates for one server supporting multiple prooftypes? Are they compatible in XMPP? /O > > Peter > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRdYFEAAoJEOoGpJErxa2pLCoP/1wYQA2CGqmaCwtG0udAP9bL > PyaYjqWqofvEdnJk/Nm/HKZdZ3MuGzpqydWo11Yi/GOyyjIzZrNQKZ2c4gPhCiNB > KdOMiMGBU625vsCJjhu8E5b14sXc4lJc7iEf2dfmMQpwer26YmGrRpolVSsBZ/td > 3FvkbPChbC9zg8YHSN9k9tkQlxfwwK5sjgIMDGtOhaKnhUBlIiGV0iTXZL1nkMdq > X9DUWzlvCHxNHWB2W1nbtYagNWu6QaoJTI88O/5qcwP4pZsrHbhelvqeuERfF+sY > sBIBrxYBNUhM9a7wWhxrlqSBeM/nt/oM46osV/sI5qrobkNs26l7hHkh/CVzpr/H > 72c1PaujqKJx4Osidyi24a9Lc6JTke/v4gr+ObN9zDBaUvAcXghqk73j8P2rUsj+ > T64/lN1n22G87d9sdi9X7RUdfTlPmg65CFmfhBMTfYnz2ZL7YzVxvnKs+Q/BF/1S > 7pHMJoviKM7V1cx3OYaEBqFnnRzWOlcfrULzy0VrFw7IjxD6+W9RxGoi2Zv1R2xL > tBy+FV9iUXS9CHyrEmjm+DYgqopg70PCaIEjHZzrC2SCbWw2DBbP0K/d5YL51Vmz > Hyz8T3h4pSfgkwa/wPs7WeP6UrHV3Cz66077L+taLuT1NV7JP1lr9L8pLDMj6xQ8 > fpkwx+0yZnAY8VBDp76A > =6W3o > -----END PGP SIGNATURE----- From emil@sip-communicator.org Mon Apr 22 12:22:57 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D8B11E80ED for ; Mon, 22 Apr 2013 12:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WAy0HSlbx7G for ; Mon, 22 Apr 2013 12:22:56 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id C21B021F9110 for ; Mon, 22 Apr 2013 12:22:55 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so1169169wgh.27 for ; Mon, 22 Apr 2013 12:22:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=KHUgp2QDCWt8gs7/FViUumz7bIY/GVshk41oCN0WRLs=; b=fKpwvmrFtwqqLBZGviOmBykcUvSGmolKg7wr70eS9l2ELQnDhfbn4ZVk9ox41yktcf b/g+Gn5ED2+UUUb8LLU34W4Uyb8ufYhobFctb2EyXezJa03wJhjVt5YJ+tX1f/e7kdw7 MwWpCaTQT6aC7312OlkWVYkbHAKW7scEUaevzCVOJifUMJZHwUETO6GgyEBQrNITL1FI eQ0ukj9bXnjC+Xs376IjwfjBUwaypcjzAlziu59qfvlBXlfTC9HSVdhj5aU3tYUOgF5p u4YoBAhKvPqBlYd9clFsI7VCZ3pEdCprXXlkv6EnDdOe5xJweNre2Q7Tcy9YgOfskGlN uusw== X-Received: by 10.194.123.168 with SMTP id mb8mr55607478wjb.24.1366658574808; Mon, 22 Apr 2013 12:22:54 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:f9a2:880:ce04:7cbc]) by mx.google.com with ESMTPSA id t7sm21950653wij.2.2013.04.22.12.22.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Apr 2013 12:22:53 -0700 (PDT) Message-ID: <51758E0A.6080801@jitsi.org> Date: Mon, 22 Apr 2013 21:22:50 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <51744F5B.8010506@jitsi.org> <0BFDB465-BACA-4411-A8F8-203506EA0422@ag-projects.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmXys2kiuIbuF6kNO3QzQF22LNGBc9bMUW/qNjzMtwqAJ+jI8gm0ZAVXomxal4mRY4xXmos Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 19:22:57 -0000 Hey Rifaat, Sa=FAl On 22.04.13, 15:29, Shekh-Yusef, Rifaat (Rifaat) wrote: > Emil, >=20 > You may want to look at the following CCMP draft: > https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp-indication/?= include_text=3D1 >=20 > We considered the two options you mentioned below and decided that the = services-uris option is more appropriate. > As Sa=FAl Ibarra Corretg=E9 mentioned this requires IANA registration f= or the new purpose value, but it can be done in the same document (see se= ction 4 of the document above). Just to make sure I understand: are you suggesting that you could add an impp purpose for service-uris in the above document? If so, then this certainly works for me! Thanks! Emil >=20 > Regards, > Rifaat >=20 >=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Sa=FAl Ibarra Corretg=E9 >> Sent: Monday, April 22, 2013 3:53 AM >> To: Emil Ivov >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Announcing a MUC with RFC4575 >> >> Hi Emil! >> >> On Apr 21, 2013, at 10:43 PM, Emil Ivov wrote: >> >>> Hey all, >>> >>> I have been looking at RFC4575 and wondering what the best way would >> be >>> for a mixer to announce that a conference has an associated chatroom >>> (e.g. an XMPP MUC) available at a certain address. This would allow >> UAs >>> that support MUCs can join there too. >>> >>> From what I see the most reasonable way to do this would be a >>> , like this for example: >>> >>> >>> >>> sip:conf545@h323.example.com >>> TTI Bridge >>> participation >>> >>> >>> xmpp:conf545@conference.example.com >>> Multi-User Chat 545 >>> impp-participation >>> >>> >>> >> >> I think the above does make sense, now, would the same URI be usable >> with Jingle or is intended for MUC only? >> >>> Another option would be to use the same but place it ina a >>> element instead: >>> >>> >>> >>> http://sharepoint/salesgroup/ >>> web-page >>> >>> >>> xmpp:conf545@conference.example.com >>> Multi-User Chat 545 >>> impp-participation >>> >>> >>> >>> Does any of the above make sense? In case no other mechanism allows >> for >>> the same thing in a simpler way, then could we maybe put one of the >> two >>> on paper? >>> >> >> This second approach would require a new entry in the IANA registry fo= r >> that 'purpose' element right? In any case, this one could also make >> sense, I guess it depends on the scenario. >> >> Assuming your scenario is Jitsi's use case, that is, the audio / video= >> conference is held by some entity and the MUC by some other, IMHO this= >> second approach makes more sense. >> >> >> Regards, >> >> -- >> Sa=FAl Ibarra Corretg=E9 >> AG Projects >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 --=20 https://jitsi.org From stpeter@stpeter.im Mon Apr 22 12:32:41 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44AF21E80B6 for ; Mon, 22 Apr 2013 12:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INq76qtNr2j4 for ; Mon, 22 Apr 2013 12:32:41 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F142621E80B3 for ; Mon, 22 Apr 2013 12:32:40 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 722F241026; Mon, 22 Apr 2013 13:43:27 -0600 (MDT) Message-ID: <51759057.60506@stpeter.im> Date: Mon, 22 Apr 2013 13:32:39 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Olle E. Johansson" References: <949EF20990823C4C85C18D59AA11AD8B02B11A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <667E20A3-B542-4C5D-B88D-200EA94EE3C7@edvina.net> <51758144.1090201@stpeter.im> <460ABD43-9A44-428B-8326-DFAA5E6CFE29@edvina.net> In-Reply-To: <460ABD43-9A44-428B-8326-DFAA5E6CFE29@edvina.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org list" , mamille2@cisco.com Subject: Re: [dispatch] DANE SRV draft and SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 19:32:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/22/13 1:18 PM, Olle E. Johansson wrote: > > 22 apr 2013 kl. 20:28 skrev Peter Saint-Andre > : > > On 4/22/13 12:18 PM, Olle E. Johansson wrote: >>>> >>>> 22 apr 2013 kl. 18:42 skrev "DRAGE, Keith (Keith)" >>>> : >>>> >>>>> While there was never a formal mailing list poll (because >>>>> we never got to the point of needing a 3261bis), I think >>>>> there was a considerable body of opinion during the >>>>> development of domain-certs that the material would form >>>>> part of any 3261bis work. That I think lends support to any >>>>> further work being done in sipcore. >>>>> >>>>> I do suggest you look back in the archives for the mailing >>>>> list discussion on domain-certs. You'll find it on the sip >>>>> (not sipcore) mailing list archive. You'll find the WG >>>>> discussion between Feb 2008 and April 2009 with the IESG >>>>> approval discussion continuing until May 2010. >>>> >>>> Keith, Thank you for the reference. >>>> >>>> Note that I'm not saying that RFC 5922 is wrong. The issue >>>> at hand is that the DANE groups current RFC suggests a >>>> solution not compatible with 5922. We need to decide which >>>> way to go. >>>> >>>> We could recommend that the DANE way is used when DNSsec and >>>> DANE validation is possible, and keep RFC 5922 for other >>>> cases. > > Well, it's clear to me that we wouldn't allow checking of the > derived domain (in RFC 6125 terms) unless DNSSEC validation > succeeds. Since that is currently a rare event, we'd just continue > to do what RFC 5922 says, which in draft-ietf-xmpp-dna we call the > PKI prooftype. >> I'm not sure that the certificates would be compatible, which is >> a problem. A non-DNSsec client following RFC 5922 requires one >> certificate with domain names and the DNSsec/DANE client would >> require host names in the same certificate - unless we have >> certificate selection (TNI). > >> Being tricky one could possibly have the host name in the CN and >> add SIP domain URIs in subj alt names. In practice, large hosting providers either (1) don't offer certificates at all or (2) offer a certificate with the hostname / derived domain instead of the source domain. In the case of (2), this forces the client developer to offer a special registration method or, even worse, forces the user to override security settings (so that, for example, everyone just "knows" that gmail.com users are actually going to be presented with a certificate for talk.google.com). Both of those are bad outcomes. >>>> Or update the recommendation in 5922 to make sip with TLS >>>> better in regards to hosting larger amounts of domains. > > I think that is somewhat a separate issue from defining the DANE > prooftype, because other prooftypes might be possible or more > deployable in the short term, such as the POSH prooftype that Matt > Miller and I have defined in draft-miller-xmpp-posh-prooftype (but > which is not specific to XMPP). >> I need to read up on your drafts, but how do you handle >> certificates for one server supporting multiple prooftypes? Are >> they compatible in XMPP? I see no reason why they can't be. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRdZBXAAoJEOoGpJErxa2pokgP/18C2O2vOT6KgnpplYm7pm1/ qgRYj5ezta6wJumOyU4Zf1Tyko89YjhUO9dRSO01ETG2Y23Fmgxe4kGK4qjnAlwL fQsdIHBWmT/8s3pSF+/eT6629yaw7kLGnTJe/G2tZ36eN6Gms/WQiEAJF4JpmyEj U7oVdANfQGvVljU7yzHSCc4d5hBmDIcmXEfh/msXvcutfX6ptIrKGszwGhBlnVXS ARn+qxmofVedz/UdwZYH92RpaFrDolqZrcbt6mB3cCPskM3WxEv6GDqwqZ6fWV81 X+tt2v5aetSky97wC0ewtHjOtJ17UAPFGBNLuoktNfD9N3sYT6bCcXYE99+JjNBL dq44uw0zLG1EbY1u3cTYVDnS6f62sM3XWkgZAqgyQQcmi60DsMKSnEym7vJO5o7Y 1/GkdxER30cvSA1hzQQIY8qTjAK5PTIZieAteU0cy7MeFwmO285pymteeU7TSu0d jEOy1jt7Swize9Wizo0zjRAxkpGiWnxEJCcvQau9+h0SF9YR7XHxsnSi+q7W/KWl xXsiYJtmhxFQtdn0AQXbBS2y/ZPSv48S968qOnVKUg+AHkVAoiJghLs01usqYQuk xNvHw97I5rAGgF87++mae5E+XbAEsD47J2Ozwc741yQqwUzIoZG5tase2GivSkjf ensJrCtBxZTT37hGsZoa =O0cH -----END PGP SIGNATURE----- From rifatyu@avaya.com Mon Apr 22 12:37:00 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2E811E80BF for ; Mon, 22 Apr 2013 12:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JgVvO3m4UIn for ; Mon, 22 Apr 2013 12:37:00 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id EBC5611E80D9 for ; Mon, 22 Apr 2013 12:36:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAEqQdVHGmAcF/2dsb2JhbABPgmUhNsEHgQYWdIIfAQEBAQIBAQEBD1YGCwUHBAIBCA0BAwQBAQEKHQcnCxQJCAIEDgUIGodsBgELoB+bLxMEjw4xBwaCYGEDiFWUbopsgwyCKA X-IronPort-AV: E=Sophos;i="4.87,528,1363147200"; d="scan'208";a="8111970" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 Apr 2013 15:36:53 -0400 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Apr 2013 15:33:06 -0400 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.02.0328.009; Mon, 22 Apr 2013 15:36:36 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Emil Ivov Thread-Topic: [dispatch] Announcing a MUC with RFC4575 Thread-Index: AQHOPtDZq1kiEme7RESI7iVwh1KKCJjiIk4AgAAZnkCAAKcOAP//vp9w Date: Mon, 22 Apr 2013 19:36:36 +0000 Message-ID: References: <51744F5B.8010506@jitsi.org> <0BFDB465-BACA-4411-A8F8-203506EA0422@ag-projects.com> <51758E0A.6080801@jitsi.org> In-Reply-To: <51758E0A.6080801@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.47] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 19:37:01 -0000 > Just to make sure I understand: are you suggesting that you could add an > impp purpose for service-uris in the above document? >=20 > If so, then this certainly works for me! No, that is not what I am suggesting. What I am saying is that when you create your document to define your impp,= you can register the new purpose value in the same document in the IANA se= ction, similar to what we did in section 4 of our CCMP document. Regards, Rifaat > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: Monday, April 22, 2013 3:23 PM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: Sa=FAl Ibarra Corretg=E9; dispatch@ietf.org > Subject: Re: [dispatch] Announcing a MUC with RFC4575 >=20 > Hey Rifaat, Sa=FAl >=20 > On 22.04.13, 15:29, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Emil, > > > > You may want to look at the following CCMP draft: > > https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp- > indication/?include_text=3D1 > > > > We considered the two options you mentioned below and decided that the > services-uris option is more appropriate. > > As Sa=FAl Ibarra Corretg=E9 mentioned this requires IANA registration f= or > the new purpose value, but it can be done in the same document (see > section 4 of the document above). >=20 > Just to make sure I understand: are you suggesting that you could add an > impp purpose for service-uris in the above document? >=20 > If so, then this certainly works for me! >=20 > Thanks! > Emil >=20 > > > > Regards, > > Rifaat > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > >> Behalf Of Sa=FAl Ibarra Corretg=E9 > >> Sent: Monday, April 22, 2013 3:53 AM > >> To: Emil Ivov > >> Cc: dispatch@ietf.org > >> Subject: Re: [dispatch] Announcing a MUC with RFC4575 > >> > >> Hi Emil! > >> > >> On Apr 21, 2013, at 10:43 PM, Emil Ivov wrote: > >> > >>> Hey all, > >>> > >>> I have been looking at RFC4575 and wondering what the best way would > >> be > >>> for a mixer to announce that a conference has an associated chatroom > >>> (e.g. an XMPP MUC) available at a certain address. This would allow > >> UAs > >>> that support MUCs can join there too. > >>> > >>> From what I see the most reasonable way to do this would be a > >>> , like this for example: > >>> > >>> > >>> > >>> sip:conf545@h323.example.com > >>> TTI Bridge > >>> participation > >>> > >>> > >>> xmpp:conf545@conference.example.com > >>> Multi-User Chat 545 > >>> impp-participation > >>> > >>> > >>> > >> > >> I think the above does make sense, now, would the same URI be usable > >> with Jingle or is intended for MUC only? > >> > >>> Another option would be to use the same but place it ina a > >>> element instead: > >>> > >>> > >>> > >>> http://sharepoint/salesgroup/ > >>> web-page > >>> > >>> > >>> xmpp:conf545@conference.example.com > >>> Multi-User Chat 545 > >>> impp-participation > >>> > >>> > >>> > >>> Does any of the above make sense? In case no other mechanism allows > >> for > >>> the same thing in a simpler way, then could we maybe put one of the > >> two > >>> on paper? > >>> > >> > >> This second approach would require a new entry in the IANA registry > for > >> that 'purpose' element right? In any case, this one could also make > >> sense, I guess it depends on the scenario. > >> > >> Assuming your scenario is Jitsi's use case, that is, the audio / > video > >> conference is held by some entity and the MUC by some other, IMHO > this > >> second approach makes more sense. > >> > >> > >> Regards, > >> > >> -- > >> Sa=FAl Ibarra Corretg=E9 > >> AG Projects > >> > >> > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 > -- > https://jitsi.org From stpeter@stpeter.im Mon Apr 22 12:48:30 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D42321F9349 for ; Mon, 22 Apr 2013 12:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.252 X-Spam-Level: X-Spam-Status: No, score=-102.252 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8AFbekqBwFK for ; Mon, 22 Apr 2013 12:48:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 87F9B21F9347 for ; Mon, 22 Apr 2013 12:48:29 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7457341026; Mon, 22 Apr 2013 13:59:16 -0600 (MDT) Message-ID: <5175940B.8050305@stpeter.im> Date: Mon, 22 Apr 2013 13:48:27 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <51744F5B.8010506@jitsi.org> <0BFDB465-BACA-4411-A8F8-203506EA0422@ag-projects.com> <51758E0A.6080801@jitsi.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , Emil Ivov Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 19:48:30 -0000 On 4/22/13 1:36 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >> Just to make sure I understand: are you suggesting that you could add an >> impp purpose for service-uris in the above document? >> >> If so, then this certainly works for me! > > No, that is not what I am suggesting. > What I am saying is that when you create your document to define your impp, you can register the new purpose value in the same document in the IANA section, similar to what we did in section 4 of our CCMP document. https://datatracker.ietf.org/doc/draft-saintandre-impp-call-info/ registers the "impp" value for Call-Info, but not for other message header fields. Peter From stpeter@stpeter.im Mon Apr 22 13:44:38 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C960521E80E9 for ; Mon, 22 Apr 2013 13:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.321 X-Spam-Level: X-Spam-Status: No, score=-102.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMh6TSK26FKt for ; Mon, 22 Apr 2013 13:44:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 557E021E80B4 for ; Mon, 22 Apr 2013 13:44:38 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1032641026; Mon, 22 Apr 2013 14:55:24 -0600 (MDT) Message-ID: <5175A133.5040309@stpeter.im> Date: Mon, 22 Apr 2013 14:44:35 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Emil Ivov References: <51744F5B.8010506@jitsi.org> In-Reply-To: <51744F5B.8010506@jitsi.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 20:44:38 -0000 On 4/21/13 2:43 PM, Emil Ivov wrote: > Hey all, > > I have been looking at RFC4575 and wondering what the best way would be > for a mixer to announce that a conference has an associated chatroom > (e.g. an XMPP MUC) available at a certain address. This would allow UAs > that support MUCs can join there too. > > From what I see the most reasonable way to do this would be a > , like this for example: > > > > sip:conf545@h323.example.com > TTI Bridge > participation > > > xmpp:conf545@conference.example.com > Multi-User Chat 545 > impp-participation > > > > Another option would be to use the same but place it ina a > element instead: > > > > http://sharepoint/salesgroup/ > web-page > > > xmpp:conf545@conference.example.com > Multi-User Chat 545 > impp-participation > > > > Does any of the above make sense? In case no other mechanism allows for > the same thing in a simpler way, then could we maybe put one of the two > on paper? Somehow "impp-participation" doesn't sound right to me. What you're talking about is a multiparty text conference that is associated with or auxiliary to the main conference. It seems to me that the text conference could be an XMPP MUC room, an IRC channel, an MSRP multiparty chat session, etc. So I would suggest something like "groupchat" (since the primary purpose here is multiparty text chat, not one-to-one IM and presence as they are traditionally understood). Peter Peter From emil@sip-communicator.org Mon Apr 22 13:59:35 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFF421E80A3 for ; Mon, 22 Apr 2013 13:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azPeisR+vjOI for ; Mon, 22 Apr 2013 13:59:34 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9E08621E80BB for ; Mon, 22 Apr 2013 13:59:34 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so1234278wgh.29 for ; Mon, 22 Apr 2013 13:59:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=F9dD6YhW5j4JMwD6pL/sBa2PHDI9BxONX/hp6AVxV8I=; b=ONY8ycvXdD/Q9ZoD9bB+8VHfK1/zo8/4WXyXW66c3DymSj5AEPRL67FbWC8Gzz52r0 +OcDPhhfXopCsF5S7Mc1qYMjpW6RNpzIfBXV/8kvpYNohzfqAJPyVSN9snRW2d4v5KFM GhllA0oSCMNZQY5K873Nh0Mf1WTBNPvEu7wflogOgTP6B/ZIIcxUovVz/mdxQzdhEZoI FXzQMIrL5duwKGlCOGPH52lizD4TWA9slk+xceDjRMtk3Jdq+T04EoYey4ksjxIoMCGP 7ZUYyxS/ftH3bGrV4XjJQY0N143BNHKgZtI5jt6nOUcXWgr5uM5aqf6e7Ugfq90kOoR4 V83Q== X-Received: by 10.180.80.3 with SMTP id n3mr32932990wix.20.1366664372738; Mon, 22 Apr 2013 13:59:32 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:f9a2:880:ce04:7cbc]) by mx.google.com with ESMTPSA id q18sm22390760wiw.8.2013.04.22.13.59.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Apr 2013 13:59:31 -0700 (PDT) Message-ID: <5175A4B1.2030707@jitsi.org> Date: Mon, 22 Apr 2013 22:59:29 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Peter Saint-Andre References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> In-Reply-To: <5175A133.5040309@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkQhEf6q2ZfSO8RQqwTzl+XXA0WpJK3OaQjzGNwCEPsYPwqu5exYCiX9AEXgt6OmD9cGCi0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 20:59:35 -0000 On 22.04.13, 22:44, Peter Saint-Andre wrote: > On 4/21/13 2:43 PM, Emil Ivov wrote: >> Hey all, >> >> I have been looking at RFC4575 and wondering what the best way would be >> for a mixer to announce that a conference has an associated chatroom >> (e.g. an XMPP MUC) available at a certain address. This would allow UAs >> that support MUCs can join there too. >> >> From what I see the most reasonable way to do this would be a >> , like this for example: >> >> >> >> sip:conf545@h323.example.com >> TTI Bridge >> participation >> >> >> xmpp:conf545@conference.example.com >> Multi-User Chat 545 >> impp-participation >> >> >> >> Another option would be to use the same but place it ina a >> element instead: >> >> >> >> http://sharepoint/salesgroup/ >> web-page >> >> >> xmpp:conf545@conference.example.com >> Multi-User Chat 545 >> impp-participation >> >> >> >> Does any of the above make sense? In case no other mechanism allows for >> the same thing in a simpler way, then could we maybe put one of the two >> on paper? > > Somehow "impp-participation" doesn't sound right to me. That was just a stab really. I don't really have a preference for the name ... unless it would mean less overhead: if for example we could have just reused the "impp" purpose from draft-saintandre-impp-call-info then that would have been great. However, as you point out, it currently only applies to Call-Info and we would need another draft that looks pretty much the same way (like Rifaat suggested). > What you're > talking about is a multiparty text conference that is associated with or > auxiliary to the main conference. It seems to me that the text > conference could be an XMPP MUC room, an IRC channel, an MSRP multiparty > chat session, etc. Correct. > So I would suggest something like "groupchat" (since > the primary purpose here is multiparty text chat, not one-to-one IM and > presence as they are traditionally understood). Well, it seems to me that a URI with an "impp" purpose that has a 1-to-1 relation with a conference can only be a group chat and it would also give us some uniformity in the naming conventions. But again, I don't really mind what the exact name would be as long as a name is defined. Cheers, Emil > > Peter > > > Peter > > -- https://jitsi.org From stpeter@stpeter.im Mon Apr 22 14:06:58 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815C921E804D for ; Mon, 22 Apr 2013 14:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfq5VqfD8c5C for ; Mon, 22 Apr 2013 14:06:52 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DA64321E8045 for ; Mon, 22 Apr 2013 14:06:51 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D389E41026; Mon, 22 Apr 2013 15:17:38 -0600 (MDT) Message-ID: <5175A669.7060805@stpeter.im> Date: Mon, 22 Apr 2013 15:06:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Emil Ivov References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A4B1.2030707@jitsi.org> In-Reply-To: <5175A4B1.2030707@jitsi.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 21:06:58 -0000 On 4/22/13 2:59 PM, Emil Ivov wrote: > > > On 22.04.13, 22:44, Peter Saint-Andre wrote: >> On 4/21/13 2:43 PM, Emil Ivov wrote: >>> Hey all, >>> >>> I have been looking at RFC4575 and wondering what the best way would be >>> for a mixer to announce that a conference has an associated chatroom >>> (e.g. an XMPP MUC) available at a certain address. This would allow UAs >>> that support MUCs can join there too. >>> >>> From what I see the most reasonable way to do this would be a >>> , like this for example: >>> >>> >>> >>> sip:conf545@h323.example.com >>> TTI Bridge >>> participation >>> >>> >>> xmpp:conf545@conference.example.com >>> Multi-User Chat 545 >>> impp-participation >>> >>> >>> >>> Another option would be to use the same but place it ina a >>> element instead: >>> >>> >>> >>> http://sharepoint/salesgroup/ >>> web-page >>> >>> >>> xmpp:conf545@conference.example.com >>> Multi-User Chat 545 >>> impp-participation >>> >>> >>> >>> Does any of the above make sense? In case no other mechanism allows for >>> the same thing in a simpler way, then could we maybe put one of the two >>> on paper? >> >> Somehow "impp-participation" doesn't sound right to me. > > That was just a stab really. I don't really have a preference for the > name ... unless it would mean less overhead: if for example we could > have just reused the "impp" purpose from draft-saintandre-impp-call-info > then that would have been great. However, as you point out, it currently > only applies to Call-Info and we would need another draft that looks > pretty much the same way (like Rifaat suggested). > >> What you're >> talking about is a multiparty text conference that is associated with or >> auxiliary to the main conference. It seems to me that the text >> conference could be an XMPP MUC room, an IRC channel, an MSRP multiparty >> chat session, etc. > > Correct. > >> So I would suggest something like "groupchat" (since >> the primary purpose here is multiparty text chat, not one-to-one IM and >> presence as they are traditionally understood). > > Well, it seems to me that a URI with an "impp" purpose that has a 1-to-1 > relation with a conference can only be a group chat and it would also > give us some uniformity in the naming conventions. But again, I don't > really mind what the exact name would be as long as a name is defined. The "impp" acronym goes back to the IMPP WG and its main output, RFC 2778 and RFC 2779, which talked about one-to-one IM and one-to-one presence. IMHO groupchat / multiparty text conferencing / whatever you want to call it is quite a different beast. Peter From emil@sip-communicator.org Mon Apr 22 14:14:11 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F21921F8F38 for ; Mon, 22 Apr 2013 14:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jW2Y4F9Qxdw2 for ; Mon, 22 Apr 2013 14:14:11 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9D44A21F8E2C for ; Mon, 22 Apr 2013 14:14:10 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id s10so1966981wey.7 for ; Mon, 22 Apr 2013 14:14:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=qSKoQCjLnAHUnaQ/nqkPY89Dwh0UmudpoxhDEu6E3jk=; b=o1Jmc/Ohg/yi+ozNqPvMacYXBrF1bXoAMBTy7z/+loeQO1dzZQvbgooEWvI8taeep8 6F357ELDIJtIOdDy5rSgkQRHNHjrU/S8DOEildVzpPyC096KfixCwkJxWF9ylVCKk9QX 8TeiE/vo+0dI8Y3uwZXhtywg6yZC2aGmlsQflKH69qiRY+gDxuNsk+wS9AFA6hWstkbD VbRoCnJt92pwcSbJMsF8jikuG03qBiFZNYIHq9E75PpDMu2JbDh7vj2/qLMbKzserkC2 lbrlkQQH/2ZAUjbeAFJx1SVYUyhiszxSe5BPbB9GkTxTUThseUd8pRdjztdlmP4/FpRM 3piA== X-Received: by 10.194.63.109 with SMTP id f13mr56281944wjs.11.1366665249641; Mon, 22 Apr 2013 14:14:09 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:f9a2:880:ce04:7cbc]) by mx.google.com with ESMTPS id d8sm24678948wiv.10.2013.04.22.14.14.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Apr 2013 14:14:08 -0700 (PDT) Message-ID: <5175A81F.5050201@jitsi.org> Date: Mon, 22 Apr 2013 23:14:07 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Peter Saint-Andre References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A4B1.2030707@jitsi.org> <5175A669.7060805@stpeter.im> In-Reply-To: <5175A669.7060805@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlEnqBFeIn5CpL57Q+I71zw4BCagyUr8yskLG6dm9s0bmAY5NsuivC6C3KZYsFb4/zPFvPw Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 21:14:11 -0000 On 22.04.13, 23:06, Peter Saint-Andre wrote: >> Well, it seems to me that a URI with an "impp" purpose that has a 1-to-1 >> relation with a conference can only be a group chat and it would also >> give us some uniformity in the naming conventions. But again, I don't >> really mind what the exact name would be as long as a name is defined. > > The "impp" acronym goes back to the IMPP WG and its main output, RFC > 2778 and RFC 2779, which talked about one-to-one IM and one-to-one > presence. IMHO groupchat / multiparty text conferencing / whatever you > want to call it is quite a different beast. OK then, so can we agree that a "groupchat" purpose would be a reasonable resolution to this and that a short draft specifying it would make sense? Some guidance from the chairs would be very much appreciated ;) Cheers, Emil -- https://jitsi.org From pkyzivat@alum.mit.edu Mon Apr 22 14:21:20 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D19E21E809C for ; Mon, 22 Apr 2013 14:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbqCnCXf7zv6 for ; Mon, 22 Apr 2013 14:21:19 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 17BFB21E804D for ; Mon, 22 Apr 2013 14:21:18 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta15.westchester.pa.mail.comcast.net with comcast id T0KX1l0060EZKEL5F9MBia; Mon, 22 Apr 2013 21:21:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id T9MA1l0153ZTu2S3M9MAXq; Mon, 22 Apr 2013 21:21:11 +0000 Message-ID: <5175A9C6.9010707@alum.mit.edu> Date: Mon, 22 Apr 2013 17:21:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> In-Reply-To: <5175A133.5040309@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366665671; bh=s/j3sragnFKNmFO5cgnTk+B5cwbt2+umbaOfJa6jYaA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=J9u+FMpk5tGDEfES8LHWIxTr5iHAmNwg83G7aWCQw59cqAzdXlA0cmd1t/XmYo/5B D133XW3WNnzV3idGD4DeF1Yr7KTaRwqTBVrGuyb/bvqLb0Sg9Wl0iDtJjRSK7X/4Ou SkkCzEJwD59zsimV1zh9LSV0ukoDqdT9MxSRxq20MUyzcILOnvJpjVS4ZnhCkxWOe+ AdIa2wdnzcBPDOt/2RfaVlh1Oh5ROExX+gib6USVNSdYiLqsJ7ngeVab1qo1ulYyqZ KHxgp87/34Ez5e0SKHBqlboKYlwnIgPyagWTQmPyIDwAPZFQ2BNqP0ee4Fj7Td3SKJ xEGXqnN75jTaQ== Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 21:21:20 -0000 On 4/22/13 4:44 PM, Peter Saint-Andre wrote: > On 4/21/13 2:43 PM, Emil Ivov wrote: >> Hey all, >> >> I have been looking at RFC4575 and wondering what the best way would be >> for a mixer to announce that a conference has an associated chatroom >> (e.g. an XMPP MUC) available at a certain address. This would allow UAs >> that support MUCs can join there too. >> >> From what I see the most reasonable way to do this would be a >> , like this for example: >> >> >> >> sip:conf545@h323.example.com >> TTI Bridge >> participation >> >> >> xmpp:conf545@conference.example.com >> Multi-User Chat 545 >> impp-participation >> >> >> >> Another option would be to use the same but place it ina a >> element instead: >> >> >> >> http://sharepoint/salesgroup/ >> web-page >> >> >> xmpp:conf545@conference.example.com >> Multi-User Chat 545 >> impp-participation >> >> >> >> Does any of the above make sense? In case no other mechanism allows for >> the same thing in a simpler way, then could we maybe put one of the two >> on paper? > > Somehow "impp-participation" doesn't sound right to me. What you're > talking about is a multiparty text conference that is associated with or > auxiliary to the main conference. It seems to me that the text > conference could be an XMPP MUC room, an IRC channel, an MSRP multiparty > chat session, etc. So I would suggest something like "groupchat" (since > the primary purpose here is multiparty text chat, not one-to-one IM and > presence as they are traditionally understood). Yes, any of these could be possible, though probably if it was MSRP it wouldn't be a separate URI from the main conference URL. So the mechanism should be work for any of those. groupchat together with the URI scheme to distinguish among them should work. (As long as we believe everyone knows that "chat" means "type" rather than "talk informally".) Thanks, Paul From jonathan@vidyo.com Tue Apr 23 07:41:56 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4B621F8FAB for ; Tue, 23 Apr 2013 07:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZiDUhS-0lZH for ; Tue, 23 Apr 2013 07:41:56 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.252]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEA721F8E9E for ; Tue, 23 Apr 2013 07:41:56 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 5528241690A; Tue, 23 Apr 2013 10:41:54 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 76A8E416A11; Tue, 23 Apr 2013 10:41:53 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Tue, 23 Apr 2013 10:40:45 -0400 From: Jonathan Lennox To: Paul Kyzivat Date: Tue, 23 Apr 2013 10:41:54 -0400 Thread-Topic: [dispatch] Announcing a MUC with RFC4575 Thread-Index: Ac5AMKaxto0PL9duRYi+ze5cE8TPxA== Message-ID: <8393F7ED-51FD-4CE1-B8A3-FD95EA185016@vidyo.com> References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A9C6.9010707@alum.mit.edu> In-Reply-To: <5175A9C6.9010707@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 14:41:56 -0000 On Apr 22, 2013, at 5:21 PM, Paul Kyzivat wrote: > On 4/22/13 4:44 PM, Peter Saint-Andre wrote: >>=20 >> Somehow "impp-participation" doesn't sound right to me. What you're >> talking about is a multiparty text conference that is associated with or >> auxiliary to the main conference. It seems to me that the text >> conference could be an XMPP MUC room, an IRC channel, an MSRP multiparty >> chat session, etc. So I would suggest something like "groupchat" (since >> the primary purpose here is multiparty text chat, not one-to-one IM and >> presence as they are traditionally understood). >=20 > Yes, any of these could be possible, though probably if it was MSRP it=20 > wouldn't be a separate URI from the main conference URL. >=20 > So the mechanism should be work for any of those.=20 > groupchat together with the URI scheme to distinguish= =20 > among them should work. (As long as we believe everyone knows that=20 > "chat" means "type" rather than "talk informally".) Maybe something with "text" in the name would be clearer -- "grouptextchat"= ? (Also, I think the bike shed should be orange.) -- Jonathan Lennox jonathan@vidyo.com From mary.ietf.barnes@gmail.com Tue Apr 23 07:50:54 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47ECE21F9609 for ; Tue, 23 Apr 2013 07:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LVCJEOuxQaF for ; Tue, 23 Apr 2013 07:50:53 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 168E421F93B0 for ; Tue, 23 Apr 2013 07:50:40 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id k19so356772qcs.13 for ; Tue, 23 Apr 2013 07:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iFwApItW4yrjjvsKkPLnI92Yd/8a5u0UdnCX3lrYhmM=; b=igBzjdRGw0obz6pQoVKXWae3zJdKlQgJy7IgruldMnjdZcx996Kz3EbcpHAoJ0dcbd Lm3E6tFSZaTzcGGCIl+WSR8xddVyt8DedwvBL7ZkyAC6fRM8tXn9cPmSvXXQ1gWBWWQF uEv1A/UNr7I6mLh04v1CE5RrUlRxgEYnX/z7riYUtC0BLPQ5FWL/s7CWjUt9JF/LML6H ToESFKfVZyHDLFQXMYGvDyX4O1ZQhPeWWlWeudv+CZrQQFkuQHOfbCDA4q+/P4fUeP5p zo2/FB7gJvGgU8qcVOYxTSYo0gt9imcJIBJskOOlAnLIzLglKBz6ruDwkdl4t7ftz6s5 vYPg== MIME-Version: 1.0 X-Received: by 10.224.147.83 with SMTP id k19mr7430725qav.72.1366728640621; Tue, 23 Apr 2013 07:50:40 -0700 (PDT) Received: by 10.49.117.163 with HTTP; Tue, 23 Apr 2013 07:50:40 -0700 (PDT) In-Reply-To: <8393F7ED-51FD-4CE1-B8A3-FD95EA185016@vidyo.com> References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A9C6.9010707@alum.mit.edu> <8393F7ED-51FD-4CE1-B8A3-FD95EA185016@vidyo.com> Date: Tue, 23 Apr 2013 09:50:40 -0500 Message-ID: From: Mary Barnes To: Jonathan Lennox Content-Type: text/plain; charset=ISO-8859-1 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 14:50:54 -0000 This would also be something useful for the XCON chat, which is defined in draft-boulton-xcon-session-chat (we will shortly be updating this and posting for discussion on this mailing list). I think "grouptextchat" would work, although I don't find it particularly readable, but I don't think abbreviating is useful, so I don't have another suggestion. Mary. On Tue, Apr 23, 2013 at 9:41 AM, Jonathan Lennox wrote: > > On Apr 22, 2013, at 5:21 PM, Paul Kyzivat wrote: > >> On 4/22/13 4:44 PM, Peter Saint-Andre wrote: >>> >>> Somehow "impp-participation" doesn't sound right to me. What you're >>> talking about is a multiparty text conference that is associated with or >>> auxiliary to the main conference. It seems to me that the text >>> conference could be an XMPP MUC room, an IRC channel, an MSRP multiparty >>> chat session, etc. So I would suggest something like "groupchat" (since >>> the primary purpose here is multiparty text chat, not one-to-one IM and >>> presence as they are traditionally understood). >> >> Yes, any of these could be possible, though probably if it was MSRP it >> wouldn't be a separate URI from the main conference URL. >> >> So the mechanism should be work for any of those. >> groupchat together with the URI scheme to distinguish >> among them should work. (As long as we believe everyone knows that >> "chat" means "type" rather than "talk informally".) > > Maybe something with "text" in the name would be clearer -- "grouptextchat"? > > (Also, I think the bike shed should be orange.) > > -- > Jonathan Lennox > jonathan@vidyo.com > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From emil@sip-communicator.org Tue Apr 23 08:33:18 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43CB21F9690 for ; Tue, 23 Apr 2013 08:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3k4xH6l9M97J for ; Tue, 23 Apr 2013 08:33:18 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0A97421F9687 for ; Tue, 23 Apr 2013 08:33:17 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id h11so946487wiv.13 for ; Tue, 23 Apr 2013 08:33:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=skbMBZneKRDWpTHpjlH5g1awZOcsQ4NXT2x2fMBz3LA=; b=aqe41I8nfJfU07xsgVCBdYIuFagr4WPLPKdUTgPXQbsUOWw29JxjQJVeKhYnmStt8+ qEIYYwlwjwW/Ymvt8tbuh90UgGwttuJC/QgA0oX9w/WLHlM2IyHA75kplASVrft+VLHZ d1cGejYEpmkS4eP7NqxX4osLburNk8YfhQtwRY7UmqmvqzJ/xpUJtV7LeYVxrerPAq1u yrQtSBgnv90skI47KeUBiZagEaYjCcI0TWUVflc5EJcIJoGKqR3wRGC0oDVxNIX/MGIE oBnLMu/04UWbF4hCkoyLuzyaPaCAKZ7PHbMShdSDzWJLuvlHS0EkOOkoURE7HOh/1yu+ 0bug== X-Received: by 10.194.176.195 with SMTP id ck3mr40814211wjc.5.1366731197218; Tue, 23 Apr 2013 08:33:17 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPS id g9sm29643480wix.1.2013.04.23.08.33.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Apr 2013 08:33:15 -0700 (PDT) Message-ID: <5176A9B9.3050105@jitsi.org> Date: Tue, 23 Apr 2013 17:33:13 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mary Barnes References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A9C6.9010707@alum.mit.edu> <8393F7ED-51FD-4CE1-B8A3-FD95EA185016@vidyo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnIHa3p61+Zv0BPGMe4PR3nqQ7FeeNKVHHKOCpqVeQPlElbiI10d0yRZkj44MwRN0KTvwlv Cc: Jonathan Lennox , "dispatch@ietf.org" Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 15:33:18 -0000 Hey Mary, On 23.04.13, 16:50, Mary Barnes wrote: > This would also be something useful for the XCON chat, which is > defined in draft-boulton-xcon-session-chat (we will shortly be > updating this and posting for discussion on this mailing list). I > think "grouptextchat" would work, although I don't find it > particularly readable, but I don't think abbreviating is useful, so I > don't have another suggestion. I suppose I am once again missing something so I'd better ask :) Are you saying that you would find a draft that defines the value helpful for draft-boulton-xcon-session-chat or are you planning on adding the definition in the draft itself? The former could be quicker I suppose and I'd be happy to write the document, but the latter also works for me. Cheers, Emil > > Mary. > > On Tue, Apr 23, 2013 at 9:41 AM, Jonathan Lennox wrote: >> >> On Apr 22, 2013, at 5:21 PM, Paul Kyzivat wrote: >> >>> On 4/22/13 4:44 PM, Peter Saint-Andre wrote: >>>> >>>> Somehow "impp-participation" doesn't sound right to me. What you're >>>> talking about is a multiparty text conference that is associated with or >>>> auxiliary to the main conference. It seems to me that the text >>>> conference could be an XMPP MUC room, an IRC channel, an MSRP multiparty >>>> chat session, etc. So I would suggest something like "groupchat" (since >>>> the primary purpose here is multiparty text chat, not one-to-one IM and >>>> presence as they are traditionally understood). >>> >>> Yes, any of these could be possible, though probably if it was MSRP it >>> wouldn't be a separate URI from the main conference URL. >>> >>> So the mechanism should be work for any of those. >>> groupchat together with the URI scheme to distinguish >>> among them should work. (As long as we believe everyone knows that >>> "chat" means "type" rather than "talk informally".) >> >> Maybe something with "text" in the name would be clearer -- "grouptextchat"? >> >> (Also, I think the bike shed should be orange.) >> >> -- >> Jonathan Lennox >> jonathan@vidyo.com >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- https://jitsi.org From mary.ietf.barnes@gmail.com Tue Apr 23 08:36:09 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4A721F969D for ; Tue, 23 Apr 2013 08:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAWTC+I7qhBF for ; Tue, 23 Apr 2013 08:36:09 -0700 (PDT) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 16D9421F969C for ; Tue, 23 Apr 2013 08:36:09 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id 1so472295qec.38 for ; Tue, 23 Apr 2013 08:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yiGkhx4OzFcVkzS1rS1r++VL61OGpsapxO5RFQ18MxA=; b=ftCsatz3XYJr7RddPiIUQd2zz4S4Lx7NBeR116CZuIn4rLk7W3XyxLiqoXrLF/QyZA PgXD6AksdaiHF+WPAFfptEjkWGrjo4QV1DBvn02xALrQyt6Ni0aXO8lkf0lA+B8PaeJW pcBERja4mSaku3jlTOiTvG34DiDGAptqs9QZBi4frDO1Xn7FIRVQNnDCdZwxABfwbVXM kJsKXJEIXOUJU87Mx0CWaozbrOrb7IFNzkVjeXNmyL+l+wGBIT/rGicZ/TPjoLma8Ufb /I/875dOQj622u5CgYD0icy8qzWSQBVmu/VJjaZLfboQ0OipD6QgDsG6FygStUoDZhin mqHw== MIME-Version: 1.0 X-Received: by 10.224.190.6 with SMTP id dg6mr26396594qab.85.1366731368624; Tue, 23 Apr 2013 08:36:08 -0700 (PDT) Received: by 10.49.117.163 with HTTP; Tue, 23 Apr 2013 08:36:08 -0700 (PDT) In-Reply-To: <5176A9B9.3050105@jitsi.org> References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A9C6.9010707@alum.mit.edu> <8393F7ED-51FD-4CE1-B8A3-FD95EA185016@vidyo.com> <5176A9B9.3050105@jitsi.org> Date: Tue, 23 Apr 2013 10:36:08 -0500 Message-ID: From: Mary Barnes To: Emil Ivov Content-Type: text/plain; charset=ISO-8859-1 Cc: Jonathan Lennox , "dispatch@ietf.org" Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 15:36:10 -0000 On Tue, Apr 23, 2013 at 10:33 AM, Emil Ivov wrote: > Hey Mary, > > On 23.04.13, 16:50, Mary Barnes wrote: >> This would also be something useful for the XCON chat, which is >> defined in draft-boulton-xcon-session-chat (we will shortly be >> updating this and posting for discussion on this mailing list). I >> think "grouptextchat" would work, although I don't find it >> particularly readable, but I don't think abbreviating is useful, so I >> don't have another suggestion. > > I suppose I am once again missing something so I'd better ask :) > > Are you saying that you would find a draft that defines the value > helpful for draft-boulton-xcon-session-chat or are you planning on > adding the definition in the draft itself? > > The former could be quicker I suppose and I'd be happy to write the > document, but the latter also works for me. [MB] I agree with you. I think we can write a simple doc to define this and it can be referenced by these other docs as necessary (since it isn't unique to any of these chat applications). [/MB] > > Cheers, > Emil > >> >> Mary. >> >> On Tue, Apr 23, 2013 at 9:41 AM, Jonathan Lennox wrote: >>> >>> On Apr 22, 2013, at 5:21 PM, Paul Kyzivat wrote: >>> >>>> On 4/22/13 4:44 PM, Peter Saint-Andre wrote: >>>>> >>>>> Somehow "impp-participation" doesn't sound right to me. What you're >>>>> talking about is a multiparty text conference that is associated with or >>>>> auxiliary to the main conference. It seems to me that the text >>>>> conference could be an XMPP MUC room, an IRC channel, an MSRP multiparty >>>>> chat session, etc. So I would suggest something like "groupchat" (since >>>>> the primary purpose here is multiparty text chat, not one-to-one IM and >>>>> presence as they are traditionally understood). >>>> >>>> Yes, any of these could be possible, though probably if it was MSRP it >>>> wouldn't be a separate URI from the main conference URL. >>>> >>>> So the mechanism should be work for any of those. >>>> groupchat together with the URI scheme to distinguish >>>> among them should work. (As long as we believe everyone knows that >>>> "chat" means "type" rather than "talk informally".) >>> >>> Maybe something with "text" in the name would be clearer -- "grouptextchat"? >>> >>> (Also, I think the bike shed should be orange.) >>> >>> -- >>> Jonathan Lennox >>> jonathan@vidyo.com >>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > -- > https://jitsi.org From stpeter@stpeter.im Tue Apr 23 10:57:55 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1805921F9629 for ; Tue, 23 Apr 2013 10:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayHrRz4jK-KJ for ; Tue, 23 Apr 2013 10:57:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A6F8D21F9627 for ; Tue, 23 Apr 2013 10:57:54 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B769140E4B; Tue, 23 Apr 2013 12:08:44 -0600 (MDT) Message-ID: <5176CBA0.6000602@stpeter.im> Date: Tue, 23 Apr 2013 11:57:52 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mary Barnes References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A9C6.9010707@alum.mit.edu> <8393F7ED-51FD-4CE1-B8A3-FD95EA185016@vidyo.com> <5176A9B9.3050105@jitsi.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jonathan Lennox , "dispatch@ietf.org" , Emil Ivov Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 17:57:55 -0000 On 4/23/13 9:36 AM, Mary Barnes wrote: > On Tue, Apr 23, 2013 at 10:33 AM, Emil Ivov > wrote: >> Hey Mary, >> >> On 23.04.13, 16:50, Mary Barnes wrote: >>> This would also be something useful for the XCON chat, which >>> is defined in draft-boulton-xcon-session-chat (we will shortly >>> be updating this and posting for discussion on this mailing >>> list). I think "grouptextchat" would work, although I don't >>> find it particularly readable, but I don't think abbreviating >>> is useful, so I don't have another suggestion. >> >> I suppose I am once again missing something so I'd better ask :) >> >> Are you saying that you would find a draft that defines the >> value helpful for draft-boulton-xcon-session-chat or are you >> planning on adding the definition in the draft itself? >> >> The former could be quicker I suppose and I'd be happy to write >> the document, but the latter also works for me. > [MB] I agree with you. I think we can write a simple doc to > define this and it can be referenced by these other docs as > necessary (since it isn't unique to any of these chat > applications). [/MB] +1 Peter From emil@sip-communicator.org Tue Apr 23 19:10:40 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7254C21F9660 for ; Tue, 23 Apr 2013 19:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7dDeP4tBo-0 for ; Tue, 23 Apr 2013 19:10:39 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 678F421F9627 for ; Tue, 23 Apr 2013 19:10:39 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x12so613155wgg.16 for ; Tue, 23 Apr 2013 19:10:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=akRVQrm1HNVwFTkerA3XCSWQnCWqSgtF0dIeDrEDnS0=; b=RL3pPyYo/BfZl+Uc7fjf8cZPK/5lYe61UcmhoOS+G1tM60X1mZBLoGIO3P2wynq29j rcjnl+DgcI8RJkLaHIlBCMdNZEk0Olh6YRR3GUjwliaPL22A4CKMJcpFiEKuMp8j0hG7 PzegiHyQ9xYBli8wPRK+gpRkvK+1ANu78qwleDfmU4D1UgZqj8cUFHw+r37VwPF23Vww K9Yo61yw+J/U0DxDHj91TA9mmzeNfqHjJfdpWKpIEZd9tv6WnP0Ize0et5aKqqIoFDS5 XRudfdUPgHUlHAnhxlzDMYzu1PuEvUkWBhkzp3HjNIxXWmtF9s/9e8kT4zopfCOb3Or6 wpUA== X-Received: by 10.180.189.205 with SMTP id gk13mr78150561wic.25.1366769437999; Tue, 23 Apr 2013 19:10:37 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:d117:8846:9f22:53cf]) by mx.google.com with ESMTPSA id s2sm1064249wib.4.2013.04.23.19.10.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Apr 2013 19:10:37 -0700 (PDT) Message-ID: <51773F1B.3020907@jitsi.org> Date: Wed, 24 Apr 2013 04:10:35 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Peter Saint-Andre References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A9C6.9010707@alum.mit.edu> <8393F7ED-51FD-4CE1-B8A3-FD95EA185016@vidyo.com> <5176A9B9.3050105@jitsi.org> <5176CBA0.6000602@stpeter.im> In-Reply-To: <5176CBA0.6000602@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm4mBv1RJrEUdsInZZkhMBYYVz454zpkM2gf9j3KUsssw7qclinkBvNVAmgUAN48D7ycsY7 Cc: "dispatch@ietf.org" , Jonathan Lennox Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 02:10:40 -0000 There it is then: http://tools.ietf.org/html/draft-ivov-grouptextchat-purpose Cheers, Emil -------- Original Message -------- Subject: New Version Notification for draft-ivov-grouptextchat-purpose-00.txt Date: Tue, 23 Apr 2013 19:09:01 -0700 From: internet-drafts@ietf.org To: Emil Ivov A new version of I-D, draft-ivov-grouptextchat-purpose-00.txt has been successfully submitted by Emil Ivov and posted to the IETF repository. Filename: draft-ivov-grouptextchat-purpose Revision: 00 Title: A Group Text Chat Purpose for Conference and Service URIs in the Session Initiation Protocol (SIP) Event Package for Conference State Creation date: 2013-04-24 Group: Individual Submission Number of pages: 5 URL: http://www.ietf.org/internet-drafts/draft-ivov-grouptextchat-purpose-00.txt Status: http://datatracker.ietf.org/doc/draft-ivov-grouptextchat-purpose Htmlized: http://tools.ietf.org/html/draft-ivov-grouptextchat-purpose-00 Abstract: This document defines and registers a value of "grouptextchat" ("Group Text Chat") value for the URI element of SIP's Conference Event Package [RFC4575]. The IETF Secretariat On 23.04.13, 19:57, Peter Saint-Andre wrote: > On 4/23/13 9:36 AM, Mary Barnes wrote: >> On Tue, Apr 23, 2013 at 10:33 AM, Emil Ivov >> wrote: >>> Hey Mary, >>> >>> On 23.04.13, 16:50, Mary Barnes wrote: >>>> This would also be something useful for the XCON chat, which >>>> is defined in draft-boulton-xcon-session-chat (we will shortly >>>> be updating this and posting for discussion on this mailing >>>> list). I think "grouptextchat" would work, although I don't >>>> find it particularly readable, but I don't think abbreviating >>>> is useful, so I don't have another suggestion. >>> >>> I suppose I am once again missing something so I'd better ask :) >>> >>> Are you saying that you would find a draft that defines the >>> value helpful for draft-boulton-xcon-session-chat or are you >>> planning on adding the definition in the draft itself? >>> >>> The former could be quicker I suppose and I'd be happy to write >>> the document, but the latter also works for me. >> [MB] I agree with you. I think we can write a simple doc to >> define this and it can be referenced by these other docs as >> necessary (since it isn't unique to any of these chat >> applications). [/MB] > > +1 > > Peter > > > -- https://jitsi.org From saul@ag-projects.com Tue Apr 23 23:48:31 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA1821F8FE9 for ; Tue, 23 Apr 2013 23:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcFDhcOG7PXu for ; Tue, 23 Apr 2013 23:48:30 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6E321F8FE3 for ; Tue, 23 Apr 2013 23:48:29 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id DAFC8B35DE; Wed, 24 Apr 2013 08:48:28 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id B32A8B017C for ; Wed, 24 Apr 2013 08:48:27 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1085) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <51773F1B.3020907@jitsi.org> Date: Wed, 24 Apr 2013 08:48:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7D085BFC-2171-486D-8439-B78543A85934@ag-projects.com> References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A9C6.9010707@alum.mit.edu> <8393F7ED-51FD-4CE1-B8A3-FD95EA185016@vidyo.com> <5176A9B9.3050105@jitsi.org> <5176CBA0.6000602@stpeter.im> <51773F1B.3020907@jitsi.org> To: dispatch@ietf.org X-Mailer: Apple Mail (2.1085) Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 06:48:31 -0000 On Apr 24, 2013, at 4:10 AM, Emil Ivov wrote: > There it is then: >=20 > http://tools.ietf.org/html/draft-ivov-grouptextchat-purpose >=20 +1 > Cheers, > Emil >=20 > -------- Original Message -------- > Subject: New Version Notification for > draft-ivov-grouptextchat-purpose-00.txt > Date: Tue, 23 Apr 2013 19:09:01 -0700 > From: internet-drafts@ietf.org > To: Emil Ivov >=20 >=20 > A new version of I-D, draft-ivov-grouptextchat-purpose-00.txt > has been successfully submitted by Emil Ivov and posted to the > IETF repository. >=20 > Filename: draft-ivov-grouptextchat-purpose > Revision: 00 > Title: A Group Text Chat Purpose for Conference and = Service URIs in > the Session Initiation Protocol (SIP) Event Package for Conference = State > Creation date: 2013-04-24 > Group: Individual Submission > Number of pages: 5 > URL: > = http://www.ietf.org/internet-drafts/draft-ivov-grouptextchat-purpose-00.tx= t > Status: > http://datatracker.ietf.org/doc/draft-ivov-grouptextchat-purpose > Htmlized: > http://tools.ietf.org/html/draft-ivov-grouptextchat-purpose-00 >=20 >=20 > Abstract: > This document defines and registers a value of "grouptextchat" > ("Group Text Chat") value for the URI element of SIP's > Conference Event Package [RFC4575]. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > On 23.04.13, 19:57, Peter Saint-Andre wrote: >> On 4/23/13 9:36 AM, Mary Barnes wrote: >>> On Tue, Apr 23, 2013 at 10:33 AM, Emil Ivov >>> wrote: >>>> Hey Mary, >>>>=20 >>>> On 23.04.13, 16:50, Mary Barnes wrote: >>>>> This would also be something useful for the XCON chat, which >>>>> is defined in draft-boulton-xcon-session-chat (we will shortly >>>>> be updating this and posting for discussion on this mailing >>>>> list). I think "grouptextchat" would work, although I don't >>>>> find it particularly readable, but I don't think abbreviating >>>>> is useful, so I don't have another suggestion. >>>>=20 >>>> I suppose I am once again missing something so I'd better ask :) >>>>=20 >>>> Are you saying that you would find a draft that defines the >>>> value helpful for draft-boulton-xcon-session-chat or are you >>>> planning on adding the definition in the draft itself? >>>>=20 >>>> The former could be quicker I suppose and I'd be happy to write >>>> the document, but the latter also works for me. >>> [MB] I agree with you. I think we can write a simple doc to >>> define this and it can be referenced by these other docs as >>> necessary (since it isn't unique to any of these chat >>> applications). [/MB] >>=20 >> +1 >>=20 >> Peter >>=20 >>=20 >>=20 >=20 > --=20 > https://jitsi.org > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Sa=FAl Ibarra Corretg=E9 AG Projects From salvatore.loreto@ericsson.com Wed Apr 24 05:04:14 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E702721F87B1 for ; Wed, 24 Apr 2013 05:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-2+nmzw5V8X for ; Wed, 24 Apr 2013 05:04:13 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6B221F8E9A for ; Wed, 24 Apr 2013 05:04:07 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-c8-5177ca33973a Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F5.92.19728.33AC7715; Wed, 24 Apr 2013 14:04:04 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Wed, 24 Apr 2013 14:04:03 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 48E7A2388 for ; Wed, 24 Apr 2013 15:04:03 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C4FA054D55 for ; Wed, 24 Apr 2013 15:04:02 +0300 (EEST) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 784A154508 for ; Wed, 24 Apr 2013 15:04:02 +0300 (EEST) Message-ID: <5177CA32.3000500@ericsson.com> Date: Wed, 24 Apr 2013 15:04:02 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A9C6.9010707@alum.mit.edu> <8393F7ED-51FD-4CE1-B8A3-FD95EA185016@vidyo.com> <5176A9B9.3050105@jitsi.org> <5176CBA0.6000602@stpeter.im> <51773F1B.3020907@jitsi.org> <7D085BFC-2171-486D-8439-B78543A85934@ag-projects.com> In-Reply-To: <7D085BFC-2171-486D-8439-B78543A85934@ag-projects.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUyM+Jvra7JqfJAg4suFksnLWB1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGqX3LGAsuM1ac2vuHpYFxOWMXIyeHhICJxI72F1C2mMSFe+vZ uhi5OIQETjFKHHs1lR0kISSwgVFixztriMRlRon1E14xQjjHGCVmv/3CBOHsY5TYcuc8C0gL r4C2xOtdHWA2i4CqxKT3m9lAbDYBM4nnD7cwdzFycIgKJEv83+ENUS4ocXLmE7ByEQFRifkr FoFtFhYwlfhy4T/U/A3MEr0TNrCCJDgFnCXO7NwKdjezgK3EhTnXWSBseYnmrbOZIf5Rk7h6 bhMzxAtaEr1nO5kmMIrMQrJvFpL2WUjaFzAyr2Jkz03MzEkvN9rECAzlg1t+q+5gvHNO5BCj NAeLkjhvuOuFACGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MRZMfcxo8izrYpRS0bv+CX5p/ 7m634tvd5NyfrmC7K7o2sPPN2RWGrQ0OXFsjN246r5Qk9U/2ivUpT8Wq2EpxncXSOauyDThD 49lvXZm4XeyDbJHkv3ds1gl7816Isz2ec1y1YNVs8XfHtRymLpx22G6xoNhmoX+5+Vt9L8Z5 3s8tkDjZcHGOEktxRqKhFnNRcSIAGCRazTMCAAA= Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 12:04:14 -0000 On 4/24/13 9:48 AM, Saúl Ibarra Corretgé wrote: > On Apr 24, 2013, at 4:10 AM, Emil Ivov wrote: > >> There it is then: >> >> http://tools.ietf.org/html/draft-ivov-grouptextchat-purpose great! /Sal From fluffy@cisco.com Wed Apr 24 07:29:54 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055DC21F91BC for ; Wed, 24 Apr 2013 07:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMlqgN66Q729 for ; Wed, 24 Apr 2013 07:29:53 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 595B521F8AD8 for ; Wed, 24 Apr 2013 07:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=501; q=dns/txt; s=iport; t=1366813793; x=1368023393; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tRjhR/0k/z/LQtHpDK+qVNDm7t96mqsx0xweu/uMIfY=; b=Kqi9A0DJnypZFfv5nkQ0HEwNNWek5pIHR7ydDYHIcAKTQXXgHIeJ5X4V cMtEcl1e4sTqgjKgAb88RIsMvjjT3pvQOTRvJVvLy4N7Uuaf5qmguAejE i/JilUYI0H3jLit8MaMUZXXAJ54yUQNYJSUHuPwwDoaEfMg8L5iWAeX8C I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAJHrd1GtJV2b/2dsb2JhbABRgwY2gmu7bH8WdIIfAQEBAwE6PwULAgEIDhQUEDIlAgQOBQiIBgYMvg2OfQIxB4JqYQOYQY97gw6CKA X-IronPort-AV: E=Sophos;i="4.87,542,1363132800"; d="scan'208";a="202511931" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 24 Apr 2013 14:29:52 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3OETpBH031684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Apr 2013 14:29:52 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 24 Apr 2013 09:29:51 -0500 From: "Cullen Jennings (fluffy)" To: Emil Ivov Thread-Topic: [dispatch] Announcing a MUC with RFC4575 Thread-Index: AQHOQPgtsXsBwnwzIkmYZoUML1GjAw== Date: Wed, 24 Apr 2013 14:29:50 +0000 Message-ID: References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A9C6.9010707@alum.mit.edu> <8393F7ED-51FD-4CE1-B8A3-FD95EA185016@vidyo.com> <5176A9B9.3050105@jitsi.org> <5176CBA0.6000602@stpeter.im> <51773F1B.3020907@jitsi.org> In-Reply-To: <51773F1B.3020907@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <9E93024A9E5EBA469EC8F352094876A5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 14:29:54 -0000 On Apr 23, 2013, at 8:10 PM, Emil Ivov wrote: > There it is then: >=20 > http://tools.ietf.org/html/draft-ivov-grouptextchat-purpose >=20 > Cheers, > Emil I like it.=20 Now how would people like to dispatch this? My preference would probably be= if one of the authors could talk to ADs about AD sponsoring this and if th= ey seem like they might be OK with that, just do a quick call on the dispat= ch list for any objects then send it that way.=20 Cullen=20 From mary.ietf.barnes@gmail.com Wed Apr 24 07:32:16 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C0A21F930E for ; Wed, 24 Apr 2013 07:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrXf+IqdKKgF for ; Wed, 24 Apr 2013 07:32:16 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1255521F92C4 for ; Wed, 24 Apr 2013 07:32:15 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id w7so1247714qeb.17 for ; Wed, 24 Apr 2013 07:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=z2OZ7Jk9s6IELLoV/e7I0peSTT9NcMeyIg/hLbl0Ldk=; b=ut/giBy/DIFTOzEHDRrlOKtjZNC2OCOtLji7zOPRVyk6VlhP7+2aOg8PxiOlPFvskF LhBxXIU8vVneHvO08okvCNzzyzxBpkXZW8o8itKbA/UynT358p95cQ+z/89rTXi1V3T9 jnznbRobQhqK2+iAyEneB7CWE+8tPNsjYGobMQB6X+H3XB/WIzF0M473isxonfutYYJz itYj2zzhi5t5dbuqWRkVuk89Px25AxuqMbt5IC6/ulmGKMmOtNYCzaZYDmjRykyolP97 EKXzFyxsg6QUUGZg2IqIwr+YpHwyhaZWjyJLp6yZmzhpyexCutsamJv3s+sxBV9WQkUw N+ww== MIME-Version: 1.0 X-Received: by 10.224.53.11 with SMTP id k11mr30657079qag.3.1366813930672; Wed, 24 Apr 2013 07:32:10 -0700 (PDT) Received: by 10.49.117.163 with HTTP; Wed, 24 Apr 2013 07:32:10 -0700 (PDT) In-Reply-To: References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A9C6.9010707@alum.mit.edu> <8393F7ED-51FD-4CE1-B8A3-FD95EA185016@vidyo.com> <5176A9B9.3050105@jitsi.org> <5176CBA0.6000602@stpeter.im> <51773F1B.3020907@jitsi.org> Date: Wed, 24 Apr 2013 09:32:10 -0500 Message-ID: From: Mary Barnes To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rai-ads@tools.ietf.org" , "dispatch@ietf.org" , Emil Ivov Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 14:32:16 -0000 On Wed, Apr 24, 2013 at 9:29 AM, Cullen Jennings (fluffy) wrote: > > On Apr 23, 2013, at 8:10 PM, Emil Ivov wrote: > >> There it is then: >> >> http://tools.ietf.org/html/draft-ivov-grouptextchat-purpose >> >> Cheers, >> Emil > > I like it. > > Now how would people like to dispatch this? My preference would probably = be if one of the authors could talk to ADs about AD sponsoring this and if = they seem like they might be OK with that, just do a quick call on the disp= atch list for any objects then send it that way. > > Cullen [MB] My thoughts exactly. I've cc'ed the RAI ADs to see if they have any issues with this approach. [/MB] Mary > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@iii.ca Wed Apr 24 07:37:45 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F3B21F8FEB for ; Wed, 24 Apr 2013 07:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NemPd2HBKwZ for ; Wed, 24 Apr 2013 07:37:45 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 22BCA21F8D92 for ; Wed, 24 Apr 2013 07:37:45 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 685EE22E1F4; Wed, 24 Apr 2013 10:37:37 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Wed, 24 Apr 2013 08:37:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <347FE501-2813-4F8E-8D9D-631F9ABEA6D8@iii.ca> References: To: Olle E. Johansson X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org list" Subject: [dispatch] Brigining SIP+DANE to Dispatch X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 14:37:45 -0000 I'm keen on someone writing a draft that specifies how to do DANE with = SIP and bringing that draft to dispatch.=20 However, I don't think you want to do that as un update to 5922. I think = you want it to be just a new draft that is an extension to SIP and does = not update or replace any of the existing draft.=20 I think Dispatch would be a good place to start the discussion around it = and decide how if this was a sip core thing, or a new small WG, or = something else. There are a few different problems that can be tacked. = One is validating that the TLS connection has the right cert. The other = is more 4474 style identity issues. I think it will be good to see = discussion on the dispatch list of the scope of problems we want to = solve with DANE.=20 Cullen On Apr 21, 2013, at 5:25 AM, Olle E. Johansson wrote: > Hi! >=20 > Looking at DANE for SIP, I mailed out some thoughts on the DANE = mailing list. If we come to > the conclusion that RFC 5922 will need to be updated - will this work = be done in Dispatch > or Dane or somewhere else? >=20 > DANE also has impacts on SIP Identity as an alternative discovery = mechanism for > domain certificates (replacing HTTPS). >=20 > /O >=20 > Vidarebefordrat brev: >=20 >> Fr=E5n: "Olle E. Johansson" >> =C4mne: DANE SRV draft and SIP >> Datum: 21 april 2013 12:27:47 CEST >> Till: dane WG list >> Kopia: "Olle E. Johansson" >>=20 >> Hi! >>=20 >> Looking at the DANE SRV draft with my SIP eyes I realize that there's = a lot of work to be done to get this >> to work with SIP.=20 >>=20 >> SIP has no StartTLS, we use NAPTR records to select transport. The = NAPTR points to a SRV >> name that resolves into a set of host names. >>=20 >> The SIP Domain certificates RFC - http://tools.ietf.org/html/rfc5922 = - specificies matching a=20 >> given SIP URI with a certificate. The matching is done on service = domain either with=20 >> a ALT name URI, like sip:ietf.org or a DNS name, like ietf.org - but = not the host name. >>=20 >> I personally agree with the policy in the DANE SRV draft that we = should match on the >> SRV hostname used to get A/AAAA records when using DNSsec. For this = to work, >> the path from the SIP URI over NAPTR to SRV and hostnames needs to be = fully >> signed in and verified in the DNS. This is going to require an update = to 5922. >>=20 >> The final question is how to handle this without SNI. The = certificates for both >> DANE verification and RFC 5922 plus "old-style" verification with the = sip >> domain in the CN seems like a complicated mess to manage. >>=20 >> Food for thought on a sunny Sunday. >>=20 >> The SRV draft is not clear on how to use Subject AltNames of various = types, >> and doesn't mention NAPTR. I am not personally aware of other = protocols using >> this setup, so maybe this requires a very SIP specfic draft, = following the wake of the >> smtp work. >>=20 >> /O >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From oej@edvina.net Wed Apr 24 08:26:22 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B122921F8ECE for ; Wed, 24 Apr 2013 08:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCByc6SnPMH1 for ; Wed, 24 Apr 2013 08:25:50 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8DA21F8900 for ; Wed, 24 Apr 2013 08:25:46 -0700 (PDT) Received: from [192.168.40.23] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E9ABD93C1AF; Wed, 24 Apr 2013 15:25:44 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <347FE501-2813-4F8E-8D9D-631F9ABEA6D8@iii.ca> Date: Wed, 24 Apr 2013 17:25:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2CAFE22F-1A16-4242-986A-CDFE05947496@edvina.net> References: <347FE501-2813-4F8E-8D9D-631F9ABEA6D8@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Brigining SIP+DANE to Dispatch X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 15:26:26 -0000 24 apr 2013 kl. 16:37 skrev Cullen Jennings : >=20 > I'm keen on someone writing a draft that specifies how to do DANE with = SIP and bringing that draft to dispatch.=20 >=20 > However, I don't think you want to do that as un update to 5922. I = think you want it to be just a new draft that is an extension to SIP and = does not update or replace any of the existing draft.=20 >=20 > I think Dispatch would be a good place to start the discussion around = it and decide how if this was a sip core thing, or a new small WG, or = something else. There are a few different problems that can be tacked. = One is validating that the TLS connection has the right cert. The other = is more 4474 style identity issues. I think it will be good to see = discussion on the dispatch list of the scope of problems we want to = solve with DANE.=20 >=20 Ok, thanks for the feedback. There's some discussion already on the DANE = list to coordinate with the work on SMTP and XMPP. I'm trying to collect my thoughts here and will come back with some = ideas for discussion. /O > Cullen >=20 >=20 >=20 > On Apr 21, 2013, at 5:25 AM, Olle E. Johansson wrote: >=20 >> Hi! >>=20 >> Looking at DANE for SIP, I mailed out some thoughts on the DANE = mailing list. If we come to >> the conclusion that RFC 5922 will need to be updated - will this work = be done in Dispatch >> or Dane or somewhere else? >>=20 >> DANE also has impacts on SIP Identity as an alternative discovery = mechanism for >> domain certificates (replacing HTTPS). >>=20 >> /O >>=20 >> Vidarebefordrat brev: >>=20 >>> Fr=E5n: "Olle E. Johansson" >>> =C4mne: DANE SRV draft and SIP >>> Datum: 21 april 2013 12:27:47 CEST >>> Till: dane WG list >>> Kopia: "Olle E. Johansson" >>>=20 >>> Hi! >>>=20 >>> Looking at the DANE SRV draft with my SIP eyes I realize that = there's a lot of work to be done to get this >>> to work with SIP.=20 >>>=20 >>> SIP has no StartTLS, we use NAPTR records to select transport. The = NAPTR points to a SRV >>> name that resolves into a set of host names. >>>=20 >>> The SIP Domain certificates RFC - http://tools.ietf.org/html/rfc5922 = - specificies matching a=20 >>> given SIP URI with a certificate. The matching is done on service = domain either with=20 >>> a ALT name URI, like sip:ietf.org or a DNS name, like ietf.org - but = not the host name. >>>=20 >>> I personally agree with the policy in the DANE SRV draft that we = should match on the >>> SRV hostname used to get A/AAAA records when using DNSsec. For this = to work, >>> the path from the SIP URI over NAPTR to SRV and hostnames needs to = be fully >>> signed in and verified in the DNS. This is going to require an = update to 5922. >>>=20 >>> The final question is how to handle this without SNI. The = certificates for both >>> DANE verification and RFC 5922 plus "old-style" verification with = the sip >>> domain in the CN seems like a complicated mess to manage. >>>=20 >>> Food for thought on a sunny Sunday. >>>=20 >>> The SRV draft is not clear on how to use Subject AltNames of various = types, >>> and doesn't mention NAPTR. I am not personally aware of other = protocols using >>> this setup, so maybe this requires a very SIP specfic draft, = following the wake of the >>> smtp work. >>>=20 >>> /O >>>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From rlb@ipv.sx Wed Apr 24 14:32:09 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A8921F8E79 for ; Wed, 24 Apr 2013 14:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eF6QgzBZTdKy for ; Wed, 24 Apr 2013 14:32:08 -0700 (PDT) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAD921F8E5F for ; Wed, 24 Apr 2013 14:32:08 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id n9so2207235oag.20 for ; Wed, 24 Apr 2013 14:32:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=BnSdxhGOcsZWgIBRZAlipKbfjBWQCCJFATV90JyMDNs=; b=dNctjEtgicDMWnYRmeumz/XYqUz6n7ExBxU9w4cGQ0bwfsSf8220WOse3Vcx0S4FIW N0XfOQa9xnvdmZ6YAbiyiFGC+MAL6SPU3Qc3YE4elv0NEf/EaVq+XOfH47zltz2cLGJ7 KVZ/Zv/0lxf4QgS8Qp0f2a2kFuaQEueIlVCtVbYterseP9urHDGhMBSi2WYzCwxDBfyS AAwco9ZxHfURsHEzPKUrB834Pc7KnyHmlaO6RFXjHdmOK1L9Nux0A4ID75S9XiCp0+6D J7UbqAY3V37HAPIlVBEyGb48JpKK8L+K82A/P9Zo7M0mEMFTnWg+/nVuaSMYfovr9zrJ rmFA== MIME-Version: 1.0 X-Received: by 10.60.59.197 with SMTP id b5mr2491913oer.4.1366839128164; Wed, 24 Apr 2013 14:32:08 -0700 (PDT) Received: by 10.60.41.225 with HTTP; Wed, 24 Apr 2013 14:32:08 -0700 (PDT) X-Originating-IP: [128.89.253.75] In-Reply-To: References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A9C6.9010707@alum.mit.edu> <8393F7ED-51FD-4CE1-B8A3-FD95EA185016@vidyo.com> <5176A9B9.3050105@jitsi.org> <5176CBA0.6000602@stpeter.im> <51773F1B.3020907@jitsi.org> Date: Wed, 24 Apr 2013 17:32:08 -0400 Message-ID: From: Richard Barnes To: Mary Barnes Content-Type: multipart/alternative; boundary=089e0149d1b6b31ee304db2208d3 X-Gm-Message-State: ALoCoQkV7H2K8gxqp9k38dE30po0nV/ND7azk3C8br90Wtt1EAAHQ57WQ0R7SfF9wqxzUi8xbT9J Cc: "Cullen Jennings \(fluffy\)" , "rai-ads@tools.ietf.org" , "dispatch@ietf.org" , Emil Ivov Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 21:32:09 -0000 --089e0149d1b6b31ee304db2208d3 Content-Type: text/plain; charset=ISO-8859-1 That sounds fine to me. --Richard On Wed, Apr 24, 2013 at 10:32 AM, Mary Barnes wrote: > On Wed, Apr 24, 2013 at 9:29 AM, Cullen Jennings (fluffy) > wrote: > > > > On Apr 23, 2013, at 8:10 PM, Emil Ivov wrote: > > > >> There it is then: > >> > >> http://tools.ietf.org/html/draft-ivov-grouptextchat-purpose > >> > >> Cheers, > >> Emil > > > > I like it. > > > > Now how would people like to dispatch this? My preference would probably > be if one of the authors could talk to ADs about AD sponsoring this and if > they seem like they might be OK with that, just do a quick call on the > dispatch list for any objects then send it that way. > > > > Cullen > [MB] My thoughts exactly. I've cc'ed the RAI ADs to see if they have > any issues with this approach. [/MB] > > Mary > > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > --089e0149d1b6b31ee304db2208d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That sounds fine to me. =A0
--Richard


On Wed, Apr = 24, 2013 at 10:32 AM, Mary Barnes <mary.ietf.barnes@gmail.com= > wrote:
On Wed, Apr 24, 2013 at 9:= 29 AM, Cullen Jennings (fluffy)
<fluffy@cisco.com> wrote:
>
> On Apr 23, 2013, at 8:10 PM, Emil Ivov <emcho@jitsi.org> wrote:
>
>> There it is then:
>>
>> http://tools.ietf.org/html/draft-ivov-grouptextchat= -purpose
>>
>> Cheers,
>> Emil
>
> I like it.
>
> Now how would people like to dispatch this? My preference would probab= ly be if one of the authors could talk to ADs about AD sponsoring this and = if they seem like they might be OK with that, just do a quick call on the d= ispatch list for any objects then send it that way.
>
> Cullen
[MB] My thoughts exactly. =A0I've cc'ed the RAI ADs to see if= they have
any issues with this approach. [/MB]

Mary

>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

--089e0149d1b6b31ee304db2208d3-- From johnsonhammond2@hushmail.com Sat Apr 27 10:08:10 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7324621F983B for ; Sat, 27 Apr 2013 10:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA75lFBPMqk6 for ; Sat, 27 Apr 2013 10:08:10 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by ietfa.amsl.com (Postfix) with ESMTP id 3978021F9837 for ; Sat, 27 Apr 2013 10:08:10 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id EBF0F1B5325 for ; Sat, 27 Apr 2013 17:07:48 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp10.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:07:48 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id B4D3514DBDE; Sat, 27 Apr 2013 17:07:48 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:07:48 -0400 To: dispatch@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427170748.B4D3514DBDE@smtp.hushmail.com> Subject: [dispatch] Biggest Fake Conference in Computer Science X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:10:12 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From prvs=183141684c=aallen@blackberry.com Sun Apr 28 23:29:24 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7BE21F9CE6 for ; Sun, 28 Apr 2013 23:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wcs4MjKelwBu for ; Sun, 28 Apr 2013 23:29:23 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF8021F955A for ; Sun, 28 Apr 2013 23:29:20 -0700 (PDT) X-AuditID: 0a41282f-b7f326d000005ad9-46-517e133afae6 Received: from XCT103ADS.rim.net (xct103ads.rim.net [10.67.111.44]) by mhs060cnc.rim.net (SBG) with SMTP id 43.D2.23257.A331E715; Mon, 29 Apr 2013 01:29:14 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.02.0328.009; Mon, 29 Apr 2013 01:29:13 -0500 From: Andrew Allen To: "dispatch@ietf.org" Thread-Topic: Notes and Summary of April 17 call on draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid Thread-Index: Ac5DsEOLJ60tgoO0QGKMbkCcTXG9NA== Date: Mon, 29 Apr 2013 06:29:12 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338D602E7XMB104ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBKsWRmVeSWpSXmKPExsXC5Zyvo2slXBdo8GCVsMXSSQtYHRg9liz5 yRTAGNXAaJOUWFIWnJmep29nk5iXl1+SWJKqkJJanGyr5JOanpijEFCUWZaYXKngklmcnJOY mZtapKSQmWKrZKKkUJCTmJyam5pXYquUWFCQmpeiZMelgAFsgMoy8xRS85LzUzLz0m2VPIP9 dS0sTC11DZXsdBM6eTKuPYwpOB1WMW/hMvYGxtUeXYwcHBICJhLvn/N1MXICmWISF+6tZ+ti 5OIQEljJKPH0z2EmCGczo8Sxqc+ZQarYBLQk9h+ezgRiiwhoSxxd1cUMUiQs0MQocWn9UhaI RDujRPvvKghbT2LJ1teMIDaLgKrEk3uT2UFsXgEPiQnX2sCGMgrISuw+ex1sKLOAuMStJ/OZ IE4SkFiy5zwzhC0q8fLxP1YIW1Fixp75rBD1+RLT512FmikocXLmE5YJjEKzkIyahaRsFpIy iLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvopRMDej2MDMIDkvWa8oM1cvL7VkEyMo9h01 9Hcwvn1vcYhRgINRiYf3E0NdoBBrYllxZe4hRgkOZiUR3tm3awOFeFMSK6tSi/Lji0pzUosP MQYBQ2UisxR3cj4wLeWVxBsbGBDJURLnrXKrDBQSSAempezU1ILUIpihTBycIEu5pESKgckl tSixtCQjHpQC44uBSVCqgVF9Q1eGyAGT259nPpsQN5+p/EJYS/U5xe+m7Pq3bc00GxrnHppu pbb2Oa+2buwOzpW2O5eVHzr2T/SBR7vyPYaTTx4bXdnJrV772mJR1g31s5yF/lnNZ6Zd9myp O8nw+cG/t9yX/3J2enKkbUu0mxB03/PIlTKuhfEJckWfpxsqd+rs2qb5UE+JpTgj0VCLuag4 EQDJAYRfSwMAAA== Subject: [dispatch] Notes and Summary of April 17 call on draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 06:29:24 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338D602E7XMB104ADSrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable In order to make progress on draft-montemurro-gsma-imei-urn and draft-allen-= dispatch-imei-urn-as-instanceid a conference call was held on Wednesday April 17 attended by Culllen Jennings, Atle Monrad, John Luc Bakker and myse= lf. Below are the combined notes and summary from Cullen and I of this call on t= he IMEI drafts: 1) change draft-allen-dispatch-imei-urn-as-instanceid to say IMEI is only us= ed in either a register request or also in an emergency invite request Cullen will then be OK with it from a privacy point of view as long as it ex= plains the trade offs. It should be highlighted in draft-montemurro-gsma-imei-urn that using the IM= EI as a security credential is a bad thing even though some popular commerci= al applications are actually doing this and some service providers are using= knowledge of the IMEI to verify the legitimacy of caller being the authoriz= ed user/owner of the device. The IMEI is usually extremely easy to obtain by= anyone who has very brief physical access to the device as it is often prin= ted on the device beneath the battery and can be displayed by using a well-k= nown key press sequence. Change draft-allen-dispatch-imei-urn-as-instanceid to not be open to any ext= ension to URN but instead require a draft updating this draft if any paramet= er other than ver=3D0 was to be included. Also add text in draft-montemurro= -gsma-imei-urn and, draft-aindicating that extensions to the IMEI parameters= will require an update of draft-allen-dispatch-imei-urn-as-instanceid. 2) Write a new separate draft that tries to deal with the OMA push to talk c= ase. This would have the UA include the IMEI in an INVITE request in very particu= lar instances where the UA knew that request was going to the POC server and= that the POC server would remove it. I'm not sure what I would think of thi= s draft - Cullen might hate it - but regardless of if folks thought it was g= ood or bad, splitting it into a separate problem can allow the use in the fi= rst draft to proceed. Cullen would want this draft to be very clear on how a= UA knew it was "safe" to put the IMEI in a INVITE and Cullen does not think= the IME should ever be in an anonymous INVITE. The current text around you= only include the IMEI if you know it is safe does not seem implementable so= Cullen would prefer something where it was really clear when the UA did it= and when it did not. Cullen thinks this is much easier to do in the specifi= c case of push to talk than trying to solve it for all uses of an INVITE so= this should be easier to get people on board with than the current draft. Response to Cullen on the IME should never be in an anonymous INVITE point.= - in 3GPP networks there is really no such thing as an anonymous INVITE sin= ce the P-CSCF always knows the identity of the UE and will always include a= P-Asserted-Identity header field. There are instead requests where privacy= is requested and the P-Asserted-Identity header field is removed at the ed= ge of the trust domain. Thus in my view there is no need for a UE in the PoC= case where it knows the PoC Server will remove the instance ID to prohibit= inclusion of the IMEI. Cullen any comments to that? 3) Update draft-montemurro-gsma-imei-urn security section to clarify that th= e IMEI-SV is not updated based on the OS version or when new applications ar= e added but represents the software version of lower layer software that has= completed certification testing. I am in the process of updating the drafts as described above. Comments on the above are of course welcome Andrew --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD2338D602E7XMB104ADSrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

 

In order to make progress on draft-montemurro-gsma= -imei-urn and draft-allen-dispatch-imei-urn-as-instanceid a conference call= was held on Wednesday

April 17 attended by Culllen Jennings, Atle Monrad= , John Luc Bakker and myself.

 

Below are the combined notes and summary from Cull= en and I of this call on the IMEI drafts:

 

 

1) change draft-allen-dispatch-imei-urn-as-instanc= eid to say IMEI is only used in either a register request or also in an emer= gency invite request

 

Cullen will then be OK with it from a privacy poin= t of view as long as it explains the trade offs.

 

It should be highlighted in draft-montemurro-gsma-= imei-urn that using the IMEI as a security credential is a bad thing even th= ough some popular commercial applications are actually doing this and some s= ervice providers are using knowledge of the IMEI to verify the legitimacy of caller being the authorized user/ow= ner of the device. The IMEI is usually extremely easy to obtain by anyone wh= o has very brief physical access to the device as it is often printed on the= device beneath the battery and can be displayed by using a well-known key press sequence.

 

Change draft-allen-dispatch-imei-urn-as-instanceid= to not be open to any extension to URN but instead require a draft updating= this draft if any parameter other than ver=3D0 was to be included.  Al= so add text in draft-montemurro-gsma-imei-urn and, draft-aindicating that extensions to the IMEI parameters will require= an update of draft-allen-dispatch-imei-urn-as-instanceid.

 

 

2) Write a new separate draft that tries to deal w= ith the OMA push to talk case.

 

This would have the UA include the IMEI in an INVI= TE request in very particular instances where the UA knew that request was g= oing to the POC server and that the POC server would remove it. I'm not sure= what I would think of this draft - Cullen might hate it - but regardless of if folks thought it was good or= bad, splitting it into a separate problem can allow the use in the first dr= aft to proceed. Cullen would want this draft to be very clear on how a UA kn= ew it was "safe" to put the IMEI in a INVITE and Cullen does not think the IME should ever be in an anonymou= s INVITE.  The current text around you only include the IMEI if you kno= w it is safe does not seem implementable so Cullen would prefer something wh= ere it was really clear when the UA did it and when it did not. Cullen thinks this is much easier to do in the= specific case of push to talk than trying to solve it for all uses of an IN= VITE so this should be easier to get people on board with than the current d= raft.

 

Response to Cullen on the IME should never be in a= n anonymous INVITE point. - in 3GPP networks there is really no such thing a= s an anonymous INVITE since the P-CSCF always knows the identity of the UE a= nd will always include a P-Asserted-Identity header field. There are instead requests where privacy is requested and the=   P-Asserted-Identity header field is removed at the edge of the trust= domain. Thus in my view there is no need for a UE in the PoC case where it= knows the PoC Server will remove the instance ID to prohibit inclusion of the IMEI. Cullen any comments to that?=

 

3) Update draft-montemurro-gsma-imei-urn security= section to clarify that the IMEI-SV is not updated based on the OS version= or when new applications are added but represents the software version of l= ower layer software that has completed certification testing.

 

I am in the process of updating the drafts as desc= ribed above.

 

Comments on the above are of course welcome

 

Andrew

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD2338D602E7XMB104ADSrimnet_-- From oej@edvina.net Mon Apr 29 02:31:19 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC2D21F9977 for ; Mon, 29 Apr 2013 02:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFsrI0vALiUU for ; Mon, 29 Apr 2013 02:31:19 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id DAB4A21F9929 for ; Mon, 29 Apr 2013 02:31:17 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1001] (unknown [IPv6:2001:16d8:cc57:1000::42:1001]) by smtp7.webway.se (Postfix) with ESMTPA id 47A6F93C2A1; Mon, 29 Apr 2013 09:31:15 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Apr 2013 11:31:21 +0200 Message-Id: <086C68EE-BA5B-43D2-9A59-51D3B48FF602@edvina.net> To: "dispatch@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [dispatch] URL on Tools give error message X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 09:31:19 -0000 I don't know if this is the proper mailing list, but I will start here = anyway :-) http://tools.ietf.org/html/rfc5626 This URL gives me=20 """ % args) IOError: [Errno 28] No space left on device /O= From oej@edvina.net Mon Apr 29 02:49:37 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF6E21F9D41 for ; Mon, 29 Apr 2013 02:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf2vUXz91Mm8 for ; Mon, 29 Apr 2013 02:49:37 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0293E21F9D40 for ; Mon, 29 Apr 2013 02:49:35 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1001] (unknown [IPv6:2001:16d8:cc57:1000::42:1001]) by smtp7.webway.se (Postfix) with ESMTPA id C531493C1AF; Mon, 29 Apr 2013 09:49:34 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Apr 2013 11:49:40 +0200 Message-Id: To: "dispatch@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 09:49:37 -0000 In the Kamailio project, we've worked on a registrar and edge-proxy = implementation of SIP outbound (RFC 5626) for a while. We now stumble into the handling of in-dialog requests. The RFC is clear how to handle dialog-forming requests and failover in = regards to these. But it doesn't really say anything clear on how to handle in-dialog requests in case of a failed flow. The route set, based on the Path header at registration, now contains a = flow token for a failed flow. This route set can not change, even though we know that we have a secondary flow to the = same instance ID that works (another Reg-id). The dialog has to die since we can not route according to the route set. I do remember a discussion about this on a SIPit event but don't = remember if we found a solution. Any ideas on how to handle this situation? Anyone working on this issue? /O= From keith.drage@alcatel-lucent.com Mon Apr 29 05:34:38 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2D321F9D92 for ; Mon, 29 Apr 2013 05:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbdMu5RtGWOs for ; Mon, 29 Apr 2013 05:34:36 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id A3BB321F9D8F for ; Mon, 29 Apr 2013 05:34:36 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r3TCYOdB003959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 29 Apr 2013 07:34:24 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r3TCYKA0029396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Apr 2013 08:34:23 -0400 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 29 Apr 2013 08:34:20 -0400 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 29 Apr 2013 14:33:59 +0200 From: "DRAGE, Keith (Keith)" To: Cullen Jennings , "Olle E. Johansson" Thread-Topic: [dispatch] Brigining SIP+DANE to Dispatch Thread-Index: AQHOQPl69jViXagjoEi5sQniIbuWFJjtKVKg Date: Mon, 29 Apr 2013 12:33:59 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B02FFBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <347FE501-2813-4F8E-8D9D-631F9ABEA6D8@iii.ca> In-Reply-To: <347FE501-2813-4F8E-8D9D-631F9ABEA6D8@iii.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Brigining SIP+DANE to Dispatch X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 12:34:38 -0000 I regarded the destination group as a given, i.e. SIPCORE. I agree that a draft would be useful to confirm that, but then I see the ke= y DISPATCH decision as to whether it is dispatchable, rather than where it = is going. Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: 24 April 2013 15:38 > To: Olle E. Johansson > Cc: dispatch@ietf.org list > Subject: [dispatch] Brigining SIP+DANE to Dispatch >=20 >=20 > I'm keen on someone writing a draft that specifies how to do DANE with SI= P > and bringing that draft to dispatch. >=20 > However, I don't think you want to do that as un update to 5922. I think > you want it to be just a new draft that is an extension to SIP and does > not update or replace any of the existing draft. >=20 > I think Dispatch would be a good place to start the discussion around it > and decide how if this was a sip core thing, or a new small WG, or > something else. There are a few different problems that can be tacked. On= e > is validating that the TLS connection has the right cert. The other is > more 4474 style identity issues. I think it will be good to see discussio= n > on the dispatch list of the scope of problems we want to solve with DANE. >=20 > Cullen >=20 >=20 >=20 > On Apr 21, 2013, at 5:25 AM, Olle E. Johansson wrote: >=20 > > Hi! > > > > Looking at DANE for SIP, I mailed out some thoughts on the DANE mailing > list. If we come to > > the conclusion that RFC 5922 will need to be updated - will this work b= e > done in Dispatch > > or Dane or somewhere else? > > > > DANE also has impacts on SIP Identity as an alternative discovery > mechanism for > > domain certificates (replacing HTTPS). > > > > /O > > > > Vidarebefordrat brev: > > > >> Fr=E5n: "Olle E. Johansson" > >> =C4mne: DANE SRV draft and SIP > >> Datum: 21 april 2013 12:27:47 CEST > >> Till: dane WG list > >> Kopia: "Olle E. Johansson" > >> > >> Hi! > >> > >> Looking at the DANE SRV draft with my SIP eyes I realize that there's = a > lot of work to be done to get this > >> to work with SIP. > >> > >> SIP has no StartTLS, we use NAPTR records to select transport. The > NAPTR points to a SRV > >> name that resolves into a set of host names. > >> > >> The SIP Domain certificates RFC - http://tools.ietf.org/html/rfc5922 - > specificies matching a > >> given SIP URI with a certificate. The matching is done on service > domain either with > >> a ALT name URI, like sip:ietf.org or a DNS name, like ietf.org - but > not the host name. > >> > >> I personally agree with the policy in the DANE SRV draft that we shoul= d > match on the > >> SRV hostname used to get A/AAAA records when using DNSsec. For this to > work, > >> the path from the SIP URI over NAPTR to SRV and hostnames needs to be > fully > >> signed in and verified in the DNS. This is going to require an update > to 5922. > >> > >> The final question is how to handle this without SNI. The certificates > for both > >> DANE verification and RFC 5922 plus "old-style" verification with the > sip > >> domain in the CN seems like a complicated mess to manage. > >> > >> Food for thought on a sunny Sunday. > >> > >> The SRV draft is not clear on how to use Subject AltNames of various > types, > >> and doesn't mention NAPTR. I am not personally aware of other protocol= s > using > >> this setup, so maybe this requires a very SIP specfic draft, following > the wake of the > >> smtp work. > >> > >> /O > >> > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Mon Apr 29 05:45:58 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAC821F9D92 for ; Mon, 29 Apr 2013 05:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+kR6nfmn0qG for ; Mon, 29 Apr 2013 05:45:58 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 169E921F9D8B for ; Mon, 29 Apr 2013 05:45:58 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id p6so1004834qad.12 for ; Mon, 29 Apr 2013 05:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=e6oigbtL8zJPLPjRetyPpKFW+or89D0Srs70MIY4XHI=; b=RU8zjfTU5IwbQ2xgK71raacQnzqRAFf+prKpTVekPz1g+ZjMYRVIgT/wvPrbuRVj2K 6xn4Za73qKSKvw09qzYC1iLr2J41Wj/Y9t61Z9mXedG2kHV6mzV/G/Cy6bzCytNKOg/J nXZ+Oz0INKNFv8gKUL8GHKcOkbpNwwj07lr/1dV8MMvxUYO+4+V3Aa7HQI7c7QJ1oRci +MzrPC4pjNBxu6FM7qjxgaSRo2vXBr4pMWq8/1dWx/UgAYv2Ky1gD2qEG7ydbLM4novL ujiwj9GXCTVWHqQS4e+SJ19mizPkmtbLlMoDZ9ov5BTwsWwVxC0T26NrrXVT17XDyfEs Cfjg== MIME-Version: 1.0 X-Received: by 10.49.38.200 with SMTP id i8mr29087626qek.1.1367239557555; Mon, 29 Apr 2013 05:45:57 -0700 (PDT) Received: by 10.49.117.163 with HTTP; Mon, 29 Apr 2013 05:45:57 -0700 (PDT) In-Reply-To: <086C68EE-BA5B-43D2-9A59-51D3B48FF602@edvina.net> References: <086C68EE-BA5B-43D2-9A59-51D3B48FF602@edvina.net> Date: Mon, 29 Apr 2013 07:45:57 -0500 Message-ID: From: Mary Barnes To: "Olle E. Johansson" Content-Type: text/plain; charset=ISO-8859-1 Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] URL on Tools give error message X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 12:45:58 -0000 I sent an email to ietf-action (@ietf.org) for the problem. On Mon, Apr 29, 2013 at 4:31 AM, Olle E. Johansson wrote: > I don't know if this is the proper mailing list, but I will start here anyway :-) > > http://tools.ietf.org/html/rfc5626 > > This URL gives me > """ % args) IOError: [Errno 28] No space left on device > > /O > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Mon Apr 29 07:24:53 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262FF21F9E10 for ; Mon, 29 Apr 2013 07:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.163 X-Spam-Level: X-Spam-Status: No, score=0.163 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_34=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvdiIxAt1uY7 for ; Mon, 29 Apr 2013 07:24:51 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id C877221F9DF0 for ; Mon, 29 Apr 2013 07:24:50 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta09.westchester.pa.mail.comcast.net with comcast id Vo8j1l0010vyq2s59qQp71; Mon, 29 Apr 2013 14:24:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id VqQp1l00E3ZTu2S3RqQp7z; Mon, 29 Apr 2013 14:24:49 +0000 Message-ID: <517E82B1.2060506@alum.mit.edu> Date: Mon, 29 Apr 2013 10:24:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <347FE501-2813-4F8E-8D9D-631F9ABEA6D8@iii.ca> <949EF20990823C4C85C18D59AA11AD8B02FFBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B02FFBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367245489; bh=RPlhJqRymUh9juwAX5XqKgQr9K7AtEMlVMUBxHowplw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tAZruYFR9k9ZwTWikH+iNVSWDjLWaTrwK/5ydbN3+W7m70RdBp+5ui+W+gZeyZPIO SjlJLARX2di6wOHAko6pVvggKhJCeInrWzrRYklDCbFssAi5GKPivtwsLfKKwYMLD+ Vvs9gSd+ijEOqtm/e48qv0Z6+mYTCIgWQRY5eiXTXqaifQN1JUbqFyxaVAgFw7kbDU dZgneUfR5QEjuyEGU9+zLNN6l2NQ8TZJ84OKMqyUktTjpYirSYGVbb2h9tr1wkBKtK NhskilPLCXaREeMnHSrofr38REnwKDvfc3Ob7QTihGwafDCOBzH/ZzgU5VomKzc6od DPyhP6L6NbpTw== Subject: Re: [dispatch] Brigining SIP+DANE to Dispatch X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 14:24:54 -0000 On 4/29/13 8:33 AM, DRAGE, Keith (Keith) wrote: > I regarded the destination group as a given, i.e. SIPCORE. > > I agree that a draft would be useful to confirm that, but then I see the key DISPATCH decision as to whether it is dispatchable, rather than where it is going. I agree that the point where this should be addressed, if dispatched, is sipcore. Thanks, Paul (as co-chair of sipcore) > Keith > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Cullen Jennings >> Sent: 24 April 2013 15:38 >> To: Olle E. Johansson >> Cc: dispatch@ietf.org list >> Subject: [dispatch] Brigining SIP+DANE to Dispatch >> >> >> I'm keen on someone writing a draft that specifies how to do DANE with SIP >> and bringing that draft to dispatch. >> >> However, I don't think you want to do that as un update to 5922. I think >> you want it to be just a new draft that is an extension to SIP and does >> not update or replace any of the existing draft. >> >> I think Dispatch would be a good place to start the discussion around it >> and decide how if this was a sip core thing, or a new small WG, or >> something else. There are a few different problems that can be tacked. One >> is validating that the TLS connection has the right cert. The other is >> more 4474 style identity issues. I think it will be good to see discussion >> on the dispatch list of the scope of problems we want to solve with DANE. >> >> Cullen >> >> >> >> On Apr 21, 2013, at 5:25 AM, Olle E. Johansson wrote: >> >>> Hi! >>> >>> Looking at DANE for SIP, I mailed out some thoughts on the DANE mailing >> list. If we come to >>> the conclusion that RFC 5922 will need to be updated - will this work be >> done in Dispatch >>> or Dane or somewhere else? >>> >>> DANE also has impacts on SIP Identity as an alternative discovery >> mechanism for >>> domain certificates (replacing HTTPS). >>> >>> /O >>> >>> Vidarebefordrat brev: >>> >>>> Från: "Olle E. Johansson" >>>> Ämne: DANE SRV draft and SIP >>>> Datum: 21 april 2013 12:27:47 CEST >>>> Till: dane WG list >>>> Kopia: "Olle E. Johansson" >>>> >>>> Hi! >>>> >>>> Looking at the DANE SRV draft with my SIP eyes I realize that there's a >> lot of work to be done to get this >>>> to work with SIP. >>>> >>>> SIP has no StartTLS, we use NAPTR records to select transport. The >> NAPTR points to a SRV >>>> name that resolves into a set of host names. >>>> >>>> The SIP Domain certificates RFC - http://tools.ietf.org/html/rfc5922 - >> specificies matching a >>>> given SIP URI with a certificate. The matching is done on service >> domain either with >>>> a ALT name URI, like sip:ietf.org or a DNS name, like ietf.org - but >> not the host name. >>>> >>>> I personally agree with the policy in the DANE SRV draft that we should >> match on the >>>> SRV hostname used to get A/AAAA records when using DNSsec. For this to >> work, >>>> the path from the SIP URI over NAPTR to SRV and hostnames needs to be >> fully >>>> signed in and verified in the DNS. This is going to require an update >> to 5922. >>>> >>>> The final question is how to handle this without SNI. The certificates >> for both >>>> DANE verification and RFC 5922 plus "old-style" verification with the >> sip >>>> domain in the CN seems like a complicated mess to manage. >>>> >>>> Food for thought on a sunny Sunday. >>>> >>>> The SRV draft is not clear on how to use Subject AltNames of various >> types, >>>> and doesn't mention NAPTR. I am not personally aware of other protocols >> using >>>> this setup, so maybe this requires a very SIP specfic draft, following >> the wake of the >>>> smtp work. >>>> >>>> /O >>>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From oej@edvina.net Mon Apr 29 07:34:30 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3FB21F9DCF for ; Mon, 29 Apr 2013 07:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3m5rCJvcXYZ for ; Mon, 29 Apr 2013 07:34:29 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id D549E21F9E3B for ; Mon, 29 Apr 2013 07:34:28 -0700 (PDT) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 02B2E93C2A1; Mon, 29 Apr 2013 14:34:27 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <517E82B1.2060506@alum.mit.edu> Date: Mon, 29 Apr 2013 16:34:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <347FE501-2813-4F8E-8D9D-631F9ABEA6D8@iii.ca> <949EF20990823C4C85C18D59AA11AD8B02FFBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <517E82B1.2060506@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1503) Cc: dispatch@ietf.org Subject: Re: [dispatch] Brigining SIP+DANE to Dispatch X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 14:34:30 -0000 29 apr 2013 kl. 16:24 skrev Paul Kyzivat : > On 4/29/13 8:33 AM, DRAGE, Keith (Keith) wrote: >> I regarded the destination group as a given, i.e. SIPCORE. >>=20 >> I agree that a draft would be useful to confirm that, but then I see = the key DISPATCH decision as to whether it is dispatchable, rather than = where it is going. >=20 > I agree that the point where this should be addressed, if dispatched, = is sipcore. Sounds like there is a plan. Now let's focus on getting this process = done :-) Thanks for all the feedback! /O >=20 > Thanks, > Paul (as co-chair of sipcore) >=20 >> Keith >>=20 >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] = On >>> Behalf Of Cullen Jennings >>> Sent: 24 April 2013 15:38 >>> To: Olle E. Johansson >>> Cc: dispatch@ietf.org list >>> Subject: [dispatch] Brigining SIP+DANE to Dispatch >>>=20 >>>=20 >>> I'm keen on someone writing a draft that specifies how to do DANE = with SIP >>> and bringing that draft to dispatch. >>>=20 >>> However, I don't think you want to do that as un update to 5922. I = think >>> you want it to be just a new draft that is an extension to SIP and = does >>> not update or replace any of the existing draft. >>>=20 >>> I think Dispatch would be a good place to start the discussion = around it >>> and decide how if this was a sip core thing, or a new small WG, or >>> something else. There are a few different problems that can be = tacked. One >>> is validating that the TLS connection has the right cert. The other = is >>> more 4474 style identity issues. I think it will be good to see = discussion >>> on the dispatch list of the scope of problems we want to solve with = DANE. >>>=20 >>> Cullen >>>=20 >>>=20 >>>=20 >>> On Apr 21, 2013, at 5:25 AM, Olle E. Johansson = wrote: >>>=20 >>>> Hi! >>>>=20 >>>> Looking at DANE for SIP, I mailed out some thoughts on the DANE = mailing >>> list. If we come to >>>> the conclusion that RFC 5922 will need to be updated - will this = work be >>> done in Dispatch >>>> or Dane or somewhere else? >>>>=20 >>>> DANE also has impacts on SIP Identity as an alternative discovery >>> mechanism for >>>> domain certificates (replacing HTTPS). >>>>=20 >>>> /O >>>>=20 >>>> Vidarebefordrat brev: >>>>=20 >>>>> Fr=E5n: "Olle E. Johansson" >>>>> =C4mne: DANE SRV draft and SIP >>>>> Datum: 21 april 2013 12:27:47 CEST >>>>> Till: dane WG list >>>>> Kopia: "Olle E. Johansson" >>>>>=20 >>>>> Hi! >>>>>=20 >>>>> Looking at the DANE SRV draft with my SIP eyes I realize that = there's a >>> lot of work to be done to get this >>>>> to work with SIP. >>>>>=20 >>>>> SIP has no StartTLS, we use NAPTR records to select transport. The >>> NAPTR points to a SRV >>>>> name that resolves into a set of host names. >>>>>=20 >>>>> The SIP Domain certificates RFC - = http://tools.ietf.org/html/rfc5922 - >>> specificies matching a >>>>> given SIP URI with a certificate. The matching is done on service >>> domain either with >>>>> a ALT name URI, like sip:ietf.org or a DNS name, like ietf.org - = but >>> not the host name. >>>>>=20 >>>>> I personally agree with the policy in the DANE SRV draft that we = should >>> match on the >>>>> SRV hostname used to get A/AAAA records when using DNSsec. For = this to >>> work, >>>>> the path from the SIP URI over NAPTR to SRV and hostnames needs to = be >>> fully >>>>> signed in and verified in the DNS. This is going to require an = update >>> to 5922. >>>>>=20 >>>>> The final question is how to handle this without SNI. The = certificates >>> for both >>>>> DANE verification and RFC 5922 plus "old-style" verification with = the >>> sip >>>>> domain in the CN seems like a complicated mess to manage. >>>>>=20 >>>>> Food for thought on a sunny Sunday. >>>>>=20 >>>>> The SRV draft is not clear on how to use Subject AltNames of = various >>> types, >>>>> and doesn't mention NAPTR. I am not personally aware of other = protocols >>> using >>>>> this setup, so maybe this requires a very SIP specfic draft, = following >>> the wake of the >>>>> smtp work. >>>>>=20 >>>>> /O >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From ibc@aliax.net Mon Apr 29 12:47:52 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD6821F9BAB for ; Mon, 29 Apr 2013 12:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLyre1T-7sNj for ; Mon, 29 Apr 2013 12:47:52 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id DD22D21F9BA9 for ; Mon, 29 Apr 2013 12:47:51 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id d10so3362152qca.9 for ; Mon, 29 Apr 2013 12:47:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=qHjXzOZCLUl2nRG4OijfcWaYFj8/J0CKX/LWXrkzqrM=; b=XMGBYvkUaKWHoYmccj7qCTfX96g9rSHvvvLJzPU/T2iqUEf2vts1RpjCSWU+ktZCYt 7CAUw/4xrAqQqyuStYZXc+kNbdYWzEr3b3gDZwqJXC+Qv3ssSFYuXbhhbPKfb/iLwAfT QosnzkmL5mjLGlhH5q5GiF+VKFyrdiD5bPCx9Hfe978o34QjOsDaNDH+RiLMKTba3P35 fCby1ubJLza4v28l5+SwewngumZ/3BcBRveodP/DZFKo3kPtm0pJG59AX44pl5iewM2C p9+ijbS+PKmH9uBaXkZODFdkjn/X/tCXEXICXlAyvckay2YeBlYQWd8Z0hF/HcS9Z7zC Buhg== X-Received: by 10.49.71.165 with SMTP id w5mr20053004qeu.36.1367264871333; Mon, 29 Apr 2013 12:47:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Mon, 29 Apr 2013 12:47:31 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 29 Apr 2013 21:47:31 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl5Tfd0e8dWfq17akuxdEYuZOEdRIYxtCzZhZU/Qequ9rhmDsI0WRrmkNAaB+3Ir+WDOOVC Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 19:47:52 -0000 2013/4/29 Olle E. Johansson : > The route set, based on the Path header at registration, now contains a f= low token for a failed flow. This route set can > not change, even though we know that we have a secondary flow to the same= instance ID that works (another Reg-id). > The dialog has to die since we can not route according to the route set. > > I do remember a discussion about this on a SIPit event but don't remember= if we found a solution. > > Any ideas on how to handle this situation? Anyone working on this issue? The only solution is using GRUU so if the client looses the connection during a dialog, it registers again and the location-server (i.e. the registrar) would route in-dialog requests via the new Route set. Tested ;) -- I=C3=B1aki Baz Castillo From oej@edvina.net Mon Apr 29 12:56:54 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28B321F9A4E for ; Mon, 29 Apr 2013 12:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oqt18tlTQ085 for ; Mon, 29 Apr 2013 12:56:54 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0D99221F99FD for ; Mon, 29 Apr 2013 12:56:51 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1001] (unknown [IPv6:2001:16d8:cc57:1000::42:1001]) by smtp7.webway.se (Postfix) with ESMTPA id B7D3C93C1AF; Mon, 29 Apr 2013 19:56:49 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: Date: Mon, 29 Apr 2013 21:56:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> References: To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 19:56:54 -0000 29 apr 2013 kl. 21:47 skrev I=F1aki Baz Castillo : > 2013/4/29 Olle E. Johansson : >> The route set, based on the Path header at registration, now contains = a flow token for a failed flow. This route set can >> not change, even though we know that we have a secondary flow to the = same instance ID that works (another Reg-id). >> The dialog has to die since we can not route according to the route = set. >>=20 >> I do remember a discussion about this on a SIPit event but don't = remember if we found a solution. >>=20 >> Any ideas on how to handle this situation? Anyone working on this = issue? >=20 > The only solution is using GRUU so if the client looses the connection > during a dialog, it registers again and the location-server (i.e. the > registrar) would route in-dialog requests via the new Route set. Which means that you actually change the in-dialog route set? /O= From ibc@aliax.net Mon Apr 29 13:49:49 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B298D21F9BB2 for ; Mon, 29 Apr 2013 13:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfUkH4NIPmck for ; Mon, 29 Apr 2013 13:49:49 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADFD21F9BAF for ; Mon, 29 Apr 2013 13:49:48 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id q2so3329168qch.2 for ; Mon, 29 Apr 2013 13:49:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=fVomoGkc9YrP0LATj7W3P6Et8q0CkrQhWlok1JE/920=; b=eM4tHcDhzeigUOFAZS+LuQMxFURxrl4jqQWAXVGLVCQnkvBvtrOYRmPH3JdBzOYcdt wZ1vYJmIS9ZYvQBkSRicW/8HXjTcKB8Ctx0u/7R8q5pCFEYmy6iYpLilRoYXYej4p+3g I+iCq5TKO9D9KD/EDoLR4fJyChRJEBxblInE15Yttovip3VyxMzd3lV7G6hquTE8N4VM dqwlZgt5kyyYluwu7HFWkhb3g9oG1KYG82CkVK/+INruwJ8IQbMhQRxo1llx9hihymPR RhZcR3HDeGAYrwphuzseN/18Vd1KU5uctWNeIj8crIvlnggVXMfuBRQHFYKXUMbfCrbS Yfhg== MIME-Version: 1.0 X-Received: by 10.224.32.137 with SMTP id c9mr53998586qad.66.1367268577708; Mon, 29 Apr 2013 13:49:37 -0700 (PDT) Received: by 10.49.81.175 with HTTP; Mon, 29 Apr 2013 13:49:37 -0700 (PDT) Received: by 10.49.81.175 with HTTP; Mon, 29 Apr 2013 13:49:37 -0700 (PDT) In-Reply-To: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> Date: Mon, 29 Apr 2013 22:49:37 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Olle E Johansson Content-Type: multipart/alternative; boundary=047d7b5d57dae3376104db860575 X-Gm-Message-State: ALoCoQmeaIvJ83e4cbdnU9PWuCASb1Y0Glrzgner5aDdMXALS1R5/oQSzgYFPCkM2mSL6NSkRKon Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 20:49:49 -0000 --047d7b5d57dae3376104db860575 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes! And it breaks RFC3261 :) -- I=C3=B1aki Baz Castillo El 29/04/2013 21:56, "Olle E. Johansson" escribi=C3=B3: > > 29 apr 2013 kl. 21:47 skrev I=C3=B1aki Baz Castillo : > > > 2013/4/29 Olle E. Johansson : > >> The route set, based on the Path header at registration, now contains = a > flow token for a failed flow. This route set can > >> not change, even though we know that we have a secondary flow to the > same instance ID that works (another Reg-id). > >> The dialog has to die since we can not route according to the route se= t. > >> > >> I do remember a discussion about this on a SIPit event but don't > remember if we found a solution. > >> > >> Any ideas on how to handle this situation? Anyone working on this issu= e? > > > > The only solution is using GRUU so if the client looses the connection > > during a dialog, it registers again and the location-server (i.e. the > > registrar) would route in-dialog requests via the new Route set. > > Which means that you actually change the in-dialog route set? > > /O --047d7b5d57dae3376104db860575 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yes! And it breaks RFC3261 :)

--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

El 29/04/2013 21:56, "Olle E. Johansson&quo= t; <oej@edvina.net> escribi=C3= =B3:

29 apr 2013 kl. 21:47 skrev I=C3=B1aki Baz Castillo <ibc@aliax.net>:

> 2013/4/29 Olle E. Johansson <oej@= edvina.net>:
>> The route set, based on the Path header at registration, now conta= ins a flow token for a failed flow. This route set can
>> not change, even though we know that we have a secondary flow to t= he same instance ID that works (another Reg-id).
>> The dialog has to die since we can not route according to the rout= e set.
>>
>> I do remember a discussion about this on a SIPit event but don'= ;t remember if we found a solution.
>>
>> Any ideas on how to handle this situation? Anyone working on this = issue?
>
> The only solution is using GRUU so if the client looses the connection=
> during a dialog, it registers again and the location-server (i.e. the<= br> > registrar) would route in-dialog requests via the new Route set.

Which means that you actually change the in-dialog route set?

/O
--047d7b5d57dae3376104db860575-- From oej@edvina.net Mon Apr 29 23:26:34 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BED21F9AE4 for ; Mon, 29 Apr 2013 23:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHTvWNmK7w4T for ; Mon, 29 Apr 2013 23:26:33 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id D3C2C21F9AD2 for ; Mon, 29 Apr 2013 23:26:31 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1001] (unknown [IPv6:2001:16d8:cc57:1000::42:1001]) by smtp7.webway.se (Postfix) with ESMTPA id BE25E93C2A1; Tue, 30 Apr 2013 06:26:27 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_A11FBC95-D7E5-4927-96E3-FB2846834428" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 30 Apr 2013 08:26:27 +0200 Message-Id: <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 06:26:34 -0000 --Apple-Mail=_A11FBC95-D7E5-4927-96E3-FB2846834428 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 29 apr 2013 kl. 22:49 skrev I=F1aki Baz Castillo : > Yes! And it breaks RFC3261 :) >=20 That's what we agreed on the Kamailio developer mailing lists too. Is this the only response that is out there? To break RFC 3261 and apply = a route change to an existing dialog? Or follow RFC 3261 and let the dialog fail? /O > -- > I=F1aki Baz Castillo > >=20 > El 29/04/2013 21:56, "Olle E. Johansson" escribi=F3: >=20 > 29 apr 2013 kl. 21:47 skrev I=F1aki Baz Castillo : >=20 > > 2013/4/29 Olle E. Johansson : > >> The route set, based on the Path header at registration, now = contains a flow token for a failed flow. This route set can > >> not change, even though we know that we have a secondary flow to = the same instance ID that works (another Reg-id). > >> The dialog has to die since we can not route according to the route = set. > >> > >> I do remember a discussion about this on a SIPit event but don't = remember if we found a solution. > >> > >> Any ideas on how to handle this situation? Anyone working on this = issue? > > > > The only solution is using GRUU so if the client looses the = connection > > during a dialog, it registers again and the location-server (i.e. = the > > registrar) would route in-dialog requests via the new Route set. >=20 > Which means that you actually change the in-dialog route set? >=20 > /O --Apple-Mail=_A11FBC95-D7E5-4927-96E3-FB2846834428 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 ibc@aliax.net>:

Yes! And it breaks RFC3261 = :)

That's what we agreed on the Kamailio = developer mailing lists too.

Is this the only = response that is out there? To break RFC 3261 and apply a route change = to an existing dialog?
Or follow RFC 3261 and let the dialog = fail?

/O

--
I=F1aki Baz Castillo
<ibc@aliax.net>

El 29/04/2013 21:56, "Olle E. Johansson" = <oej@edvina.net> = escribi=F3:

29 apr 2013 kl. 21:47 skrev I=F1aki Baz Castillo <ibc@aliax.net>:

> 2013/4/29 Olle E. Johansson <oej@edvina.net>:
>> The route set, based on the Path header at registration, now = contains a flow token for a failed flow. This route set can
>> not change, even though we know that we have a secondary flow = to the same instance ID that works (another Reg-id).
>> The dialog has to die since we can not route according to the = route set.
>>
>> I do remember a discussion about this on a SIPit event but = don't remember if we found a solution.
>>
>> Any ideas on how to handle this situation? Anyone working on = this issue?
>
> The only solution is using GRUU so if the client looses the = connection
> during a dialog, it registers again and the location-server (i.e. = the
> registrar) would route in-dialog requests via the new Route = set.

Which means that you actually change the in-dialog route set?

/O

= --Apple-Mail=_A11FBC95-D7E5-4927-96E3-FB2846834428-- From ibc@aliax.net Tue Apr 30 02:42:10 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2E421F9B44 for ; Tue, 30 Apr 2013 02:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoUU1Kur3RhO for ; Tue, 30 Apr 2013 02:42:05 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3751121F9B38 for ; Tue, 30 Apr 2013 02:42:04 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id x7so156558qeu.6 for ; Tue, 30 Apr 2013 02:42:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=AZNOzJOA+iSEc35fbP89BFxztCFlzCOuPyBMe6qopSQ=; b=l4CeKkO0dh9suiZQlHoJFu7eZIZtKcndndXuHnfTAuxxdt+5KI6Azq6ar3Yv9ScZsv l+qpMMCLBVWdlSxkXrURp5pyzu4hRwjLePme6j5HhOFmCezojoulXXGHi2MojwB5GesG RelmZCQirn4/Y7Vyn9b7NhGMVv8hZzWqHhE7BPv/aouUJVCQHiY7Fny21D6iAwGE0XhO 965enFukmp4PpBKFfcZU2qLa0XLjfo4d4C47SiXRzm+qGZ0g1dQLFEBNEUAp48Gjshzg GhQKWjyq+MpshZ3LUKrpXhXgF6eDADTARj7gmi+EVl/ZRH19JAf/7FBZidZ5EgBWIZMW EXyw== X-Received: by 10.224.3.135 with SMTP id 7mr56159926qan.10.1367314924222; Tue, 30 Apr 2013 02:42:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Tue, 30 Apr 2013 02:41:43 -0700 (PDT) In-Reply-To: <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 30 Apr 2013 11:41:43 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkDBDejBtqcpP7fnV6OEX7jPBgFqGfbhxoBu9mO82PCosS76wdTs6o6/tnI2ZR9mBLfL58T Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 09:42:10 -0000 2013/4/30 Olle E. Johansson : > Is this the only response that is out there? To break RFC 3261 and apply = a > route change to an existing dialog? Is not cool enough? :) Right, RFC 5627 should say "something" about it. -- I=C3=B1aki Baz Castillo