From nobody Mon Mar 2 05:43:09 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3805B1A876B for ; Mon, 2 Mar 2015 05:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.721 X-Spam-Level: X-Spam-Status: No, score=0.721 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCJxRwaOfFWa for ; Mon, 2 Mar 2015 05:43:02 -0800 (PST) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F5E1A8769 for ; Mon, 2 Mar 2015 05:43:01 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id q107so13442131qgd.7 for ; Mon, 02 Mar 2015 05:43:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=2pfa/C84FHHdDch+84UFlRAs8X3aBT5jBg9APJQcTtU=; b=Uhak54hGK9N9LiJaPFTBS5NZAifaqCy80URxZRodfBB56V/0YzET98xn8BWMpJqyTt EoTg2u7mJkYYSe0I6eCF+Oywse4f0wqVC6Vf8kpT5fdgdTO5OO9BW8UfZKalH3UGXX9Z NdLtIAXWpcwldGBXLOvGkESWT5t+5ogkUWtl07lxYfRuFwffuek1QtLHYK6nSLxqwAvZ nuOY762uYVuPFM3QfjpFN0zKjxADYi85Ccvq40pC1kf5ba/fHrUCCVUbUoW8TLalMvck RvF8jP8/cvuae5NQA9uicV5gFgaBjuV2jJMZbrugI2iUkac5GMJ4tA20G/DJbI65hmSX VDuw== X-Gm-Message-State: ALoCoQmQ0gEUMWlbREA+YodDo+6bWi3BLu1N4Gqh7Sr84hReA3q3SFhyTvRUPGiF2sDWVHl73rtA X-Received: by 10.140.218.202 with SMTP id o193mr52793304qhb.13.1425303781036; Mon, 02 Mar 2015 05:43:01 -0800 (PST) From: Brett Tate References: <39B5E4D390E9BD4890E2B310790061011278E192@ESESSMB301.ericsson.se> <128feace0c9075f945faa5117a915841@mail.gmail.com> <54F10467.5070706@nostrum.com> In-Reply-To: <54F10467.5070706@nostrum.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHJG9cbz7m2Lf6iOn3n7mZ6ZTN9RAKVa2C4AdTu1X2c9FCCEA== Date: Mon, 2 Mar 2015 08:43:00 -0500 Message-ID: <669a5f0de51b8beeb71f03d13dab2023@mail.gmail.com> To: Adam Roach , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] Comments to draft-roach-sipcore-6665-clarification-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 13:43:08 -0000 > Sounds good to me, except that 6665 deprecates in-dialog subscriptions. How does a GRUU generator know that the GRUU is globally routable by every device which can receive it? From nobody Mon Mar 2 06:17:31 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9651A8775 for ; Mon, 2 Mar 2015 06:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXTQNmWRxZdW for ; Mon, 2 Mar 2015 06:17:28 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14201A8768 for ; Mon, 2 Mar 2015 06:17:28 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t22EHNW8020543 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2015 08:17:24 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54F470F3.9070308@nostrum.com> Date: Mon, 02 Mar 2015 08:17:23 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Brett Tate , sipcore@ietf.org References: <39B5E4D390E9BD4890E2B310790061011278E192@ESESSMB301.ericsson.se> <128feace0c9075f945faa5117a915841@mail.gmail.com> <54F10467.5070706@nostrum.com> <669a5f0de51b8beeb71f03d13dab2023@mail.gmail.com> In-Reply-To: <669a5f0de51b8beeb71f03d13dab2023@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Comments to draft-roach-sipcore-6665-clarification-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 14:17:29 -0000 On 3/2/15 07:43, Brett Tate wrote: >> Sounds good to me, except that 6665 deprecates in-dialog subscriptions. > How does a GRUU generator know that the GRUU is globally routable by every > device which can receive it? How does it know that in-dialog messages do? I'm not looking to turn this three-sentence clarification into a referendum on whether GRUUs work in the face of intermediaries whose configured purpose is to break GRUUs. If you want to start a separate thread/draft/initiative on "how SBCs ruin everything forever," I'm happy to help. /a From nobody Mon Mar 2 06:29:13 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312D31A8783 for ; Mon, 2 Mar 2015 06:29:12 -0800 (PST) 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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0anDrv7wjE5h for ; Mon, 2 Mar 2015 06:29:11 -0800 (PST) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A481A877F for ; Mon, 2 Mar 2015 06:29:11 -0800 (PST) Received: by mail-qg0-f52.google.com with SMTP id l89so13055729qgf.11 for ; Mon, 02 Mar 2015 06:29:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=nDeMd7DYChzGlZUrRY+Ojwfw5Qq8a1HH7R8Zg8XKmks=; b=Z98kaUM3ZUGDvWaVWWRYqdOCNeSPeURv5Y3ofVR9dJqvoRg0wDJqzwpjIhgP5zr2MR OtHPhC/W14wD1d0C2TAN5XTy6nho5Ksp/kcNzW1JYANLcMpnlojL1ZKrcpAdrucdKmhu g8DOqvLkakehbly2lYIiCnwn4JW7sbVu8TwyBlIOXef14twz6T53Jlgg0X9/nUpg+BAY HHNJayLSYsPmcre9vCzebzuG6oFlr///5v3sV8VgIW1TgYDFzdHn1OjQvD/1CSLVYUyZ s7goTRn+0BoAqVonMuAsz+liHvqOWKwRPgjGTDSFnXG+Q3IbtGmIGtpIZ5QDcAra64a5 KN1w== X-Gm-Message-State: ALoCoQnOYIfVjUvyfxtFQ3ZFXLw18Y+xPugADUO20UDQ8456iBsih2g9eA6vZ0eMekCy339HVSRT X-Received: by 10.140.165.209 with SMTP id l200mr52253350qhl.84.1425306550222; Mon, 02 Mar 2015 06:29:10 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBU9TlePWhJRyNdTJuFWEkTWuupIw== Date: Mon, 2 Mar 2015 09:29:09 -0500 Message-ID: <71ae1df037ed6663e5d1d3fde2d494c4@mail.gmail.com> To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [sipcore] How does a GRUU generator know that the GRUU is globally routable? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 14:29:12 -0000 Hi, How does a GRUU generator know that the GRUU is globally routable by every device which can receive it? Thanks, Brett From nobody Mon Mar 2 07:13:14 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CAF1A88CF for ; Mon, 2 Mar 2015 07:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywQjKkRZlkrf for ; Mon, 2 Mar 2015 07:13:10 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C6871A8874 for ; Mon, 2 Mar 2015 07:03:00 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t22F2t1d024424 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2015 09:02:56 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54F47B9F.6090000@nostrum.com> Date: Mon, 02 Mar 2015 09:02:55 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Brett Tate , sipcore@ietf.org References: <71ae1df037ed6663e5d1d3fde2d494c4@mail.gmail.com> In-Reply-To: <71ae1df037ed6663e5d1d3fde2d494c4@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] How does a GRUU generator know that the GRUU is globally routable? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 15:13:12 -0000 On 3/2/15 08:29, Brett Tate wrote: > How does a GRUU generator know that the GRUU is globally routable by every > device which can receive it? This is functionally the same question as asking "how do we know that an AOR can route to the associated user's registered device(s)?" Fundamentally, both of them are a matter of proper administrative configuration that ensures that the domain portion of a GRUU (or AOR) resolves to the IP address of a responsible node when RFC 3263 procedures are applied to it. >From that point, all that's required is properly functioning logic in that node to resolve an AOR to a user's device(s), or a GRUU to a specific device. They're fundamentally the same operation, except that AORs can correspond to multiple devices, while GRUUs cannot. But I suspect you know all this. There are lots of complaints to be leveled at the behavior of network intermediaries that change things in ways that are incongruent with behavior described in RFCs. I'm not entirely certain which one you're trying to highlight here, so you'll have to be clearer. Describe a scenario in which properly configured network elements can hand out a GRUU which then does not route to the corresponding device, and we can talk about what went wrong and how one might go about addressing the situation. /a From nobody Mon Mar 2 07:19:19 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9651A87D2 for ; Mon, 2 Mar 2015 07:19:18 -0800 (PST) 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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CVnc75aGZjd for ; Mon, 2 Mar 2015 07:19:16 -0800 (PST) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38171A887D for ; Mon, 2 Mar 2015 07:18:29 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id x12so23304848qac.0 for ; Mon, 02 Mar 2015 07:18:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=/huZ7OdyzOWNVfHZCGag7npusVlVGG1Wit6DrLGy3GM=; b=jvSODy+Hy1JrURWLV8csxXHlBo6KmZy8ACxx6kRDa1NUHoZpjcW65EvC+AZgOoN9iq ep9IkVircfYn4RlUSa/Jzn3hFtJNZf5scPCuELO3T+3Xt0W5AUZRhiSOk+EWLTVY/BWI nzuhBkGT1eNps6CzoyNJLSf/+h7vgPZazGMSOla8i3BvUoxXfpy7mkB9/eRUmQnR5UZj NJZaqPN4mvbasOTzX6AoQzAlg13vH76ViOP74SQ/frx60Wl26IpjqS6ppB4N7qqbBNnt arSm5tINGEYezUA8JI7O/twqWe55S8nz35+XSUwd3yANYMffErwrud8NpQ/XZBg/kgnr AvSw== X-Gm-Message-State: ALoCoQkcdPibx9D+XMIMDMW3rxyG8jZfjI07Iph9s6IL8Mi4e1Ng5zyT4Hv7Zn94Fhr9N0SSsTHl X-Received: by 10.140.165.209 with SMTP id l200mr52538479qhl.84.1425309509137; Mon, 02 Mar 2015 07:18:29 -0800 (PST) From: Brett Tate References: <39B5E4D390E9BD4890E2B310790061011278E192@ESESSMB301.ericsson.se> <128feace0c9075f945faa5117a915841@mail.gmail.com> <54F10467.5070706@nostrum.com> <669a5f0de51b8beeb71f03d13dab2023@mail.gmail.com> <54F470F3.9070308@nostrum.com> In-Reply-To: <54F470F3.9070308@nostrum.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHJG9cbz7m2Lf6iOn3n7mZ6ZTN9RAKVa2C4AdTu1X0BkaiaXQI9bmV5nNXn73A= Date: Mon, 2 Mar 2015 10:18:28 -0500 Message-ID: To: Adam Roach , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] Comments to draft-roach-sipcore-6665-clarification-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 15:19:18 -0000 > >> Sounds good to me, except that 6665 deprecates in-dialog > >> subscriptions. > > > > How does a GRUU generator know that the GRUU is globally > > routable by every device which can receive it? > > How does it know that in-dialog messages do? It doesn't claim to. It does the best it can. If an intermediary used during call setup drops out, things can fail. With the use of GRUU, some of the needed/original intermediaries may be bypassed; thus things may fail more often. > I'm not looking to turn this three-sentence clarification > into a referendum on whether GRUUs work in the face of > intermediaries whose configured purpose is to break GRUUs. > If you want to start a separate thread/draft/initiative on > "how SBCs ruin everything forever," I'm happy to help. I opened a separate thread. Thanks, Brett From nobody Mon Mar 2 09:43:42 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C441A8851 for ; Mon, 2 Mar 2015 09:43:40 -0800 (PST) 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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQuyWKhzs8-c for ; Mon, 2 Mar 2015 09:43:39 -0800 (PST) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798371A87EF for ; Mon, 2 Mar 2015 09:43:39 -0800 (PST) Received: by mail-qg0-f47.google.com with SMTP id q107so4993716qgd.6 for ; Mon, 02 Mar 2015 09:43:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=yZyo/6fxWjmYJ8ZzR1ezOQOn9wdNqgXBPJp1NNX9x44=; b=jtwXZ5YJUnq3Q8//5p51oMdSwrb3rdKwpOLCATVpoezq54QAmZTseiCR1eaqS2cpMf h+rTHOo+9dtL/mVTfrPa2DoK/YxxM29t5EOu8FQKyI0rSyjmmPhFidcyU1IbgDEJlP3J +PLVqnasPE2nB7t6Bsnfp9snCFX3fnY0uXWqIRhXX2OSVXkIaBibP7BkA2YMuNyuX0/s v/sfCvQXID4Y8QsgduLfraXpFWtTBs8gzcIm5yTJrWIkQN6mPKBIH6kqIxfiRWpL3k2y PnnCdOVbBldMeXdQ5T7t7z+YPBltBepO0jGp83eDmcc1kaMsfA+RO/CMd8stHqhHJZji zG/w== X-Gm-Message-State: ALoCoQltHw/ZKVNIBZ7uzLEBTlIRNUdZBfFMjxKN13eedzVCVgXeG3HaXzisLvK+1pHWQFODdxjz X-Received: by 10.55.41.219 with SMTP id p88mr7511392qkp.50.1425318218771; Mon, 02 Mar 2015 09:43:38 -0800 (PST) From: Brett Tate References: <71ae1df037ed6663e5d1d3fde2d494c4@mail.gmail.com> <54F47B9F.6090000@nostrum.com> In-Reply-To: <54F47B9F.6090000@nostrum.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHnDVUBqnc/5lpgji0vVgAnjGRohwKiYaxqnMbUqeA= Date: Mon, 2 Mar 2015 12:43:38 -0500 Message-ID: To: Adam Roach , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] How does a GRUU generator know that the GRUU is globally routable? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 17:43:40 -0000 > Describe a scenario in which properly configured network > elements can hand out a GRUU which then does not route > to the corresponding device, and we can talk about what > went wrong and how one might go about addressing the > situation. I'm concerned about the issues raised within draft-kaplan-dispatch-gruu-problematic-00. For instance, section "5. Problems with Global Reachability" highlights issues concerning Access-Restricted Domains, Routing-Restricted Domains, and IPv6 Reachability. Thanks, Brett From nobody Mon Mar 2 09:55:32 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959AF1A8879 for ; Mon, 2 Mar 2015 09:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFdbUvpvPva4 for ; Mon, 2 Mar 2015 09:55:23 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D53E1A8877 for ; Mon, 2 Mar 2015 09:55:23 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t22HtMk4041156 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 2 Mar 2015 11:55:23 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54F4A405.1090703@nostrum.com> Date: Mon, 02 Mar 2015 11:55:17 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D71E5A8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D71E5A8@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------010103090009050407050703" Archived-At: Subject: Re: [sipcore] Concluded: WGLC / Call for Adoption: REFER-related work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 17:55:30 -0000 This is a multi-part message in MIME format. --------------010103090009050407050703 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Thanks for the two pointers, Christer. I've been on vacation (!) for a couple of weeks - I'm back now, and will reply to those messages in their threads. Are there any other unaddressed comments you are aware of? RjS On 2/28/15 6:02 PM, Christer Holmberg wrote: > > http://www.ietf.org/mail-archive/web/sipcore/current/msg06488.html > > *From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of > *Christer Holmberg > *Sent:* 28 February 2015 08:11 > *To:* Adam Roach; 'SIPCORE'; Ivo Sedlacek; Brett Tate > *Subject:* Re: [sipcore] Concluded: WGLC / Call for Adoption: > REFER-related work > > Hi Adam, > > A while ago I had a comment on the refer-clarification draft, which > Robert said he was going to address during the WGLC. > > Regards, > > Christer > > > Sent from my Windows Phone > > ------------------------------------------------------------------------ > > *From: *Adam Roach > *Sent: *‎28/‎02/‎2015 02:08 > *To: *Christer Holmberg ; > 'SIPCORE' ; Ivo Sedlacek > ; Brett Tate > > *Subject: *Concluded: WGLC / Call for Adoption: REFER-related work > > [as chair] > > The adoption and WGLC period for the three documents has ended. Given > the expressed support (meager as it was) and lack of objection, we're > going to consider the 6665-clarifications draft adopted. > > There were no additional comments on refer-clarifications or > refer-explicit-subscription, so we will begin preparing them for IESG > review. > > [as author] > > A new version that I believe addresses the outstanding comments on the > 6665 clarification document is available here: > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-6665-clarification/ > > Ivo / Brett: as you were the people who provided the feedback that I've > incorporated, please look over this latest text to let me know whether > it addresses the specific concern that had been raised. Thanks! > > /a > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --------------010103090009050407050703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Thanks for the two pointers, Christer.
I've been on vacation (!) for a couple of weeks - I'm back now, and will reply to those messages in their threads.

Are there any other unaddressed comments you are aware of?

RjS

On 2/28/15 6:02 PM, Christer Holmberg wrote:

http://www.ietf.org/mail-archive/web/sipcore/current/msg06488.html

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 28 February 2015 08:11
To: Adam Roach; 'SIPCORE'; Ivo Sedlacek; Brett Tate
Subject: Re: [sipcore] Concluded: WGLC / Call for Adoption: REFER-related work

 

Hi Adam,

A while ago I had a comment on the refer-clarification draft, which Robert said he was going to address during the WGLC.

Regards,

Christer


Sent from my Windows Phone

From: Adam Roach
Sent: ‎28/‎02/‎2015 02:08
To: Christer Holmberg; 'SIPCORE'; Ivo Sedlacek; Brett Tate
Subject: Concluded: WGLC / Call for Adoption: REFER-related work

[as chair]

The adoption and WGLC period for the three documents has ended. Given
the expressed support (meager as it was) and lack of objection, we're
going to consider the 6665-clarifications draft adopted.

There were no additional comments on refer-clarifications or
refer-explicit-subscription, so we will begin preparing them for IESG
review.

[as author]

A new version that I believe addresses the outstanding comments on the
6665 clarification document is available here:

https://datatracker.ietf.org/doc/draft-ietf-sipcore-6665-clarification/

Ivo / Brett: as you were the people who provided the feedback that I've
incorporated, please look over this latest text to let me know whether
it addresses the specific concern that had been raised. Thanks!

/a



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

--------------010103090009050407050703-- From nobody Mon Mar 2 10:08:17 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210141A8898 for ; Mon, 2 Mar 2015 10:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG9EH29sBXOv for ; Mon, 2 Mar 2015 10:08:14 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CDD11A8888 for ; Mon, 2 Mar 2015 10:08:14 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t22I89UR042400 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Mar 2015 12:08:09 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54F4A704.7060200@nostrum.com> Date: Mon, 02 Mar 2015 12:08:04 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Christer Holmberg , "sipcore@ietf.org" References: <20150121210526.24004.59206.idtracker@ietfa.amsl.com> <54C01742.8080802@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D679B06@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D679B06@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 18:08:16 -0000 On 1/23/15 6:10 AM, Christer Holmberg wrote: > Hi Robert, > > The document looks good, and I also think it's ready for WGLC. I do have an editorial comment, though: > > The second last paragraph in section 4 says: > > "If a user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request (such as by requiring > an extension that disallows any such subscription > [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request > MAY be sent within an existing dialog. Such a REFER will be > constructed with its Contact header field populated with the dialog's > Local URI as specified in section 12 of [RFC3261]." > > Since the draft earlier talks about having to send REFERs out-of-dialog if the remote Contact is a GRUU, I think it would be good to explicitly clarify that in this case sending an in-dialog REFER is allowed even if the remote Contact is a GRUU. > > (Because, there may many non-REFER related reasons why the remote UA provided a GRUU.) I've made this change OLD: MAY be sent within an existing dialog. NEW: MAY be sent within an existing dialog (whether or not the remote target is a GRUU). > > Regards, > > Christer > > > > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert Sparks > Sent: 21. tammikuuta 2015 23:17 > To: sipcore@ietf.org > Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-01.txt > > I think this, and refer-explicit-subscriptions are ready for WGLC. > Let me know if I've missed anything. > > RjS > > On 1/21/15 3:05 PM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. >> >> Title : Clarifications for the use of REFER with RFC6665 >> Authors : Robert Sparks >> Adam Roach >> Filename : draft-ietf-sipcore-refer-clarifications-01.txt >> Pages : 6 >> Date : 2015-01-21 >> >> Abstract: >> The SIP REFER method relies on the SIP-Specific Event Notification >> Framework. That framework was revised by RFC6665. This document >> highlights the implications of the requirement changes in RFC6665, >> and updates the definition of the REFER method, RFC3515, to clarify >> and disambiguate the impact of those changes. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarificatio >> ns/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-refer-clarificatio >> ns-01 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Mar 2 10:31:15 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC681A8884 for ; Mon, 2 Mar 2015 10:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Zw6bX2Lr2IZ for ; Mon, 2 Mar 2015 10:31:12 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0DD1A8871 for ; Mon, 2 Mar 2015 10:31:12 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t22IVBDl044635 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 2 Mar 2015 12:31:11 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54F4AC6A.2010507@nostrum.com> Date: Mon, 02 Mar 2015 12:31:06 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D6936FD@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060505060501010208070706" Archived-At: Subject: Re: [sipcore] draft-explicit-subscription-00: URI SHOULD be sent using TLS or DTLS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 18:31:14 -0000 This is a multi-part message in MIME format. --------------060505060501010208070706 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit So, I think the thing to do here is to point to RFC3261. I've made this modification: For instance, SIP messages containing this URI SHOULD be sent using TLS or DTLS (see the security considerations section of for considerations when using other security mechanisms). Does that cover your concern? RjS On 2/5/15 10:05 AM, Andrew Allen wrote: > > +1 > > What Christer propose is what we quite normally have. We know there > are many deployments that use other security mechanisms other than TLD > or DTLS. > > *From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of > *Christer Holmberg > *Sent:* Thursday, February 05, 2015 10:17 AM > *To:* sipcore@ietf.org > *Subject:* [sipcore] draft-explicit-subscription-00: URI SHOULD be > sent using TLS or DTLS > > Hi, > > The text in section 8 (Security Considerations) of > draft-ietf-sipcore-refer-explicit-subscription-00 says: > > “For instance, SIP messages containing this URI SHOULD be sent using > TLS or DTLS.” > > Now, while I realize that a “SHOULD” does allow for other mechanisms, > I think it would be good to explicitly say that other mechanisms, > providing similar protection, can also be used. > > Regards, > > Christer > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --------------060505060501010208070706 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit So, I think the thing to do here is to point to RFC3261.

I've made this modification:

For instance, SIP messages containing this URI SHOULD be sent
using TLS or DTLS (see the security considerations section of <xref
target="RFC3261"/> for considerations when using other security mechanisms).

Does that cover your concern?

RjS

On 2/5/15 10:05 AM, Andrew Allen wrote:

+1

 

What Christer propose is what we quite normally have. We know there are many deployments that use other security mechanisms other than TLD or DTLS.

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Thursday, February 05, 2015 10:17 AM
To: sipcore@ietf.org
Subject: [sipcore] draft-explicit-subscription-00: URI SHOULD be sent using TLS or DTLS

 

Hi,

 

The text in section 8 (Security Considerations) of draft-ietf-sipcore-refer-explicit-subscription-00 says:

 

“For instance, SIP messages containing this URI SHOULD be sent using TLS or DTLS.”

 

Now, while I realize that a “SHOULD” does allow for other mechanisms, I think it would be good to explicitly say that other mechanisms, providing similar protection, can also be used.

 

Regards,

 

Christer

 

 

 

 



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

--------------060505060501010208070706-- From nobody Mon Mar 2 10:42:23 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CEE1A889F for ; Mon, 2 Mar 2015 10:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89EUNiErWNy3 for ; Mon, 2 Mar 2015 10:42:18 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A767A1A889D for ; Mon, 2 Mar 2015 10:42:13 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t22IgA5m045698 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2015 12:42:11 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54F4AF02.8010004@nostrum.com> Date: Mon, 02 Mar 2015 12:42:10 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Brett Tate , sipcore@ietf.org References: <71ae1df037ed6663e5d1d3fde2d494c4@mail.gmail.com> <54F47B9F.6090000@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] How does a GRUU generator know that the GRUU is globally routable? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 18:42:22 -0000 On 3/2/15 11:43, Brett Tate wrote: > I'm concerned about the issues raised within > draft-kaplan-dispatch-gruu-problematic-00. For instance, section "5. > Problems with Global Reachability" highlights issues concerning > Access-Restricted Domains, Which the document freely acknowledges only arises due to a misconfiguration (one which I find highly questionable, by the way -- if the network were broken in the way described, then AORs couldn't route either). > Routing-Restricted Domains, Which is again described as an issue of configuration, and again questionable: the implementations I've seen use the same domain for GRUUs as they do for AORs. If you can't route to the GRUU, then you can't set up the call in the first place. > and IPv6 Reachability. The problem in that section also applies to AORs (and pretty much all other SIP URIs, for that matter); and any solution that can be applied to fix the AOR problem fixes the GRUU problem. You need to keep in mind that this document is basically an apologia for one specific behavior that Hadriel wanted to have a fig leaf of cover to continue to do; to wit: "B2BUAs should continue to replace Contact URIs, regardless of them being a GRUU or not." The logic in here is difficult to follow; and, when you do untangle it, largely nonsense. If you can offer real world examples that aren't of the form "I saw a misconfigured network fail to work," I'd be happy to engage. This document contains none. Any plausible example would need to explain why "sip:adam@example.com" could route to my phone, but "sip:62860991-6586-4dbc-90bc-b32abd3c771b@example.com;gr" could not. /a From nobody Tue Mar 3 00:17:39 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267101A1A46 for ; Tue, 3 Mar 2015 00:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2bcHjipzbqK for ; Tue, 3 Mar 2015 00:17:36 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCFBD1A1A38 for ; Tue, 3 Mar 2015 00:17:35 -0800 (PST) X-AuditID: c1b4fb25-f79446d000003f3f-b1-54f56e1d5a4b Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AD.0C.16191.D1E65F45; Tue, 3 Mar 2015 09:17:34 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0210.002; Tue, 3 Mar 2015 09:17:33 +0100 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-01.txt Thread-Index: AQHQNb4QXdNpSzFLNk6rGVkHu2+UK5zLAuQAgAKaUuCAPA4xAIAA/egA Date: Tue, 3 Mar 2015 08:17:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D722F48@ESESSMB209.ericsson.se> References: <20150121210526.24004.59206.idtracker@ietfa.amsl.com> <54C01742.8080802@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D679B06@ESESSMB209.ericsson.se> <54F4A704.7060200@nostrum.com> In-Reply-To: <54F4A704.7060200@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvja5c3tcQg9n/2CyuzWlks/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJVxftdv9oIXchXPv69mbWBcKNHFyMkhIWAi 8ffDf1YIW0ziwr31bF2MXBxCAkcYJU69fc0I4SxmlPj/4zZQhoODTcBCovufNkiDiECgxMJJ S1hAbGGBYIl7zx+zQ8RDJG68/cUGYbtJfFu1nBnEZhFQkTj+9TjYMl4BX4mnk1+yQ8w/zihx 7spxsAZOAW2JlmfbwRoYgS76fmoNE4jNLCAucevJfCaISwUkluw5zwxhi0q8fPwP6gNFiY+v 9jFC1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo2hxanFS brqRsV5qUWZycXF+nl5easkmRmCkHNzyW3UH4+U3jocYBTgYlXh4Nyh/DRFiTSwrrsw9xCjN waIkzmtnfChESCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2Pe55fZn+s0mbxF3hbvu1Hz6peX vJtULAPnjJ8q21cW9Pv++rRA2FNy5uzTe84d2cX3YHbKXCPLenGhgpfyXZcd/TlTtO64xQZu z1TnNpjTH7fzWs+Gl9Fqgn+N5dsVZ+9pzTUXmNigLuoZklX3zvt7oObKVN8/KrEnl4aZbZ0X LSfXuTzOWImlOCPRUIu5qDgRABMHd551AgAA Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 08:17:38 -0000 Hi Robert, I am happy with your suggested change. Thanks! Regards, Christer -----Original Message----- From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Sent: 2. maaliskuuta 2015 20:08 To: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 01.txt On 1/23/15 6:10 AM, Christer Holmberg wrote: > Hi Robert, > > The document looks good, and I also think it's ready for WGLC. I do have = an editorial comment, though: > > The second last paragraph in section 4 says: > > "If a user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request (such as by requiring > an extension that disallows any such subscription > [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request > MAY be sent within an existing dialog. Such a REFER will be > constructed with its Contact header field populated with the dialog'= s > Local URI as specified in section 12 of [RFC3261]." > > Since the draft earlier talks about having to send REFERs out-of-dialog i= f the remote Contact is a GRUU, I think it would be good to explicitly clar= ify that in this case sending an in-dialog REFER is allowed even if the rem= ote Contact is a GRUU. > > (Because, there may many non-REFER related reasons why the remote UA=20 > provided a GRUU.) I've made this change OLD: MAY be sent within an existing dialog. NEW: MAY be sent within an existing dialog (whether or not the remote target is = a GRUU). > > Regards, > > Christer > > > > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert=20 > Sparks > Sent: 21. tammikuuta 2015 23:17 > To: sipcore@ietf.org > Subject: Re: [sipcore] I-D Action:=20 > draft-ietf-sipcore-refer-clarifications-01.txt > > I think this, and refer-explicit-subscriptions are ready for WGLC. > Let me know if I've missed anything. > > RjS > > On 1/21/15 3:05 PM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Session Initiation Protocol Core Wor= king Group of the IETF. >> >> Title : Clarifications for the use of REFER with RFC= 6665 >> Authors : Robert Sparks >> Adam Roach >> Filename : draft-ietf-sipcore-refer-clarifications-01.txt >> Pages : 6 >> Date : 2015-01-21 >> >> Abstract: >> The SIP REFER method relies on the SIP-Specific Event Notification >> Framework. That framework was revised by RFC6665. This document >> highlights the implications of the requirement changes in RFC6665, >> and updates the definition of the REFER method, RFC3515, to clarify >> and disambiguate the impact of those changes. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarificati >> o >> ns/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-refer-clarificati >> o >> ns-01 >> >> >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at tools.ie= tf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Mar 3 00:25:40 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0E61A1A6F for ; Tue, 3 Mar 2015 00:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfpZ0T4ULCoI for ; Tue, 3 Mar 2015 00:25:37 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658A01A1A67 for ; Tue, 3 Mar 2015 00:25:36 -0800 (PST) X-AuditID: c1b4fb25-f79446d000003f3f-d0-54f56ffeffa2 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 43.FD.16191.EFF65F45; Tue, 3 Mar 2015 09:25:34 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0210.002; Tue, 3 Mar 2015 09:25:34 +0100 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-explicit-subscription-00: URI SHOULD be sent using TLS or DTLS Thread-Index: AdBBVsCp8+spI+foR6KQfx5FBSKWdQABpgmABOxUPgAAHzj/sA== Date: Tue, 3 Mar 2015 08:25:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D722F9E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6936FD@ESESSMB209.ericsson.se> <54F4AC6A.2010507@nostrum.com> In-Reply-To: <54F4AC6A.2010507@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D722F9EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvje6//K8hBruuaFhcm9PIZvH1xyY2 ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugSvj9ZQ3rAWtIRULj35gbWA849XFyMEhIWAi ca5Xq4uRE8gUk7hwbz1bFyMXh5DAEUaJH/NWs0I4ixklOk6cYAFpYBOwkOj+pw3SICIQKLFw 0hIWEFtYIFbiSdMKRoh4nMTfS4+YQcpFBJwkFm0PAgmzCKhI7Lg0HaycV8BX4tT6+YwQ49cy SrTf+gOW4BTQlliz4j4riM0IdND3U2uYQGxmAXGJW0/mM0EcKiCxZM95ZghbVOLl43+sELai xMdX+xgh6vMlNv7YyQixTFDi5MwnLBMYRWYhGTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHP HHjMhCy+gJF9FaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgVB3c8lt1B+PlN46HGAU4GJV4 eDcofw0RYk0sK67MPcQozcGiJM5rZ3woREggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANja/WJ 8xe1a5vNZqX653So3l2cstlBacOpaQwdh5STpK1MH2z7qWa1P1FqRUip2/mdTWU3OPakN5f1 /r5brSV1Y+kc8d9277Pc/2oHt05J2tGhnaPv/3VDxt9675hXGWsyuir++9SX+K7llU7elVy0 2bPH+3fL1M1cN/PlQt6+jjbMN7yg06fEUpyRaKjFXFScCABo1KLPiwIAAA== Archived-At: Subject: Re: [sipcore] draft-explicit-subscription-00: URI SHOULD be sent using TLS or DTLS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 08:25:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D722F9EESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, I am happy with your suggested modification. Thanks! Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert Sparks Sent: 2. maaliskuuta 2015 20:31 To: sipcore@ietf.org Subject: Re: [sipcore] draft-explicit-subscription-00: URI SHOULD be sent u= sing TLS or DTLS So, I think the thing to do here is to point to RFC3261. I've made this modification: For instance, SIP messages containing this URI SHOULD be sent using TLS or DTLS (see the security considerations section of for considerations when using other security mechanism= s). Does that cover your concern? RjS On 2/5/15 10:05 AM, Andrew Allen wrote: +1 What Christer propose is what we quite normally have. We know there are man= y deployments that use other security mechanisms other than TLD or DTLS. From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: Thursday, February 05, 2015 10:17 AM To: sipcore@ietf.org Subject: [sipcore] draft-explicit-subscription-00: URI SHOULD be sent using= TLS or DTLS Hi, The text in section 8 (Security Considerations) of draft-ietf-sipcore-refer= -explicit-subscription-00 says: "For instance, SIP messages containing this URI SHOULD be sent using TLS or= DTLS." Now, while I realize that a "SHOULD" does allow for other mechanisms, I thi= nk it would be good to explicitly say that other mechanisms, providing simi= lar protection, can also be used. Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B1D722F9EESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robe= rt,

&n= bsp;

I am ha= ppy with your suggested modification.

&n= bsp;

Thanks!=

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

From:= sipcore [mailto:sip= core-bounces@ietf.org] On Behalf Of Robert Sparks
Sent: 2. maaliskuuta 2015 20:31
To: sipcore@ietf.org
Subject: Re: [sipcore] draft-explicit-subscription-00: URI SHOULD be= sent using TLS or DTLS

 

So, I think the thing= to do here is to point to RFC3261.

I've made this modification:

For instance, SIP messages containing this URI SHOULD be sent
using TLS or DTLS (see the security considerations section of <xref
target=3D"RFC3261"/> for considerations when using other secur= ity mechanisms).

Does that cover your concern?

RjS

On 2/5/15 10:05 AM, Andrew Allen wrote:

+1

 

What Christer propose = is what we quite normally have. We know there are many deployments that use= other security mechanisms other than TLD or DTLS.

 

From: sipcore = [mailto:sipcore-bounces@ietf.or= g] On Behalf Of Christer Holmberg
Sent: Thursday, February 05, 2015 10:17 AM
To: sipcore@ietf.org
Subject: [sipcore] draft-explicit-subscription-00: URI SHOULD be sen= t using TLS or DTLS

 

Hi,

 

The text in section 8 (Security= Considerations) of draft-ietf-sipcore-refer-explicit-subscription-00 says:=

 

&#= 8220;For instance, SIP messages containing this URI SHOULD be sent using TL= S or DTLS.”

&n= bsp;

Now, while I realize that a = 220;SHOULD” does allow for other mechanisms, I think it would be good= to explicitly say that other mechanisms, providing similar protection, can= also be used.

 

Regards,

 

Christer

 

 

 

 




_______________________________________________
sipcore mailing list
sipcore@ietf.org

https://www.=
ietf.org/mailman/listinfo/sipcore

 

--_000_7594FB04B1934943A5C02806D1A2204B1D722F9EESESSMB209erics_-- From nobody Tue Mar 3 00:28:05 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9498B1A1A6F for ; Tue, 3 Mar 2015 00:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgMqo97eGHia for ; Tue, 3 Mar 2015 00:28:03 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C1E1A1A6E for ; Tue, 3 Mar 2015 00:28:02 -0800 (PST) X-AuditID: c1b4fb2d-f79aa6d00000359d-5d-54f57090735e Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 92.FC.13725.09075F45; Tue, 3 Mar 2015 09:28:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0210.002; Tue, 3 Mar 2015 09:28:00 +0100 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] Concluded: WGLC / Call for Adoption: REFER-related work Thread-Index: AQHQVRIWByBHpeWx2EWFM2dI2hnnFp0Kaghw Date: Tue, 3 Mar 2015 08:27:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D722FE1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D71E5A8@ESESSMB209.ericsson.se> <54F4A405.1090703@nostrum.com> In-Reply-To: <54F4A405.1090703@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+Jvje6Egq8hBs33VC2uzWlks/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJWxrDmsYJ9YxebpPg2MX0S7GDk5JARMJPqW z2SGsMUkLtxbz9bFyMUhJHCEUaJj4QZ2CGcxo8TaFx+Aqjg42AQsJLr/aYM0iAgESiyctIQF xBYWCJD41feBCSZ+6OY5VpByEQEjiYblWSBhFgEViZXfXrGD2LwCvhLfD05nA7GFBPIkZkz/ DjaGU0BbYlbLF1YQmxHonu+n1oCNZBYQl7j1ZD4TxJ0CEkv2nIe6WVTi5eN/rBC2osTHV/sY QdYyC2hKrN+lD9GqKDGl+yHUWkGJkzOfsExgFJ2FZOoshI5ZSDpmIelYwMiyilG0OLW4ODfd yFgvtSgzubg4P08vL7VkEyMwOg5u+a27g3H1a8dDjAIcjEo8vBuUv4YIsSaWFVfmHmKU5mBR Eue1Mz4UIiSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRLGXOtKJtBfOPpaTFHNLe7pLBw8B7 fnFF03LrK65Wm098E/mpaWJixrzuY9MDPpXJjpOO2Lhz9J1ecM/BRLZaaOlhl12Tba8wb3a8 2aE/45P21WzBC67TVCwfawtErHlUyB/4/12aS8bWa98f9RytPnFKInPKhvSkWY9nLUvZ8Mvv pAfPHft4JZbijERDLeai4kQAqh37tG8CAAA= Archived-At: Subject: Re: [sipcore] Concluded: WGLC / Call for Adoption: REFER-related work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 08:28:04 -0000 SGksDQoNCj4gVGhhbmtzIGZvciB0aGUgdHdvIHBvaW50ZXJzLCBDaHJpc3Rlci4NCj4gSSd2ZSBi ZWVuIG9uIHZhY2F0aW9uICghKSBmb3IgYSBjb3VwbGUgb2Ygd2Vla3MgLSBJJ20gYmFjayBub3cs IGFuZCB3aWxsIHJlcGx5IHRvIHRob3NlIG1lc3NhZ2VzIGluIHRoZWlyIHRocmVhZHMuDQo+DQo+ IEFyZSB0aGVyZSBhbnkgb3RoZXIgdW5hZGRyZXNzZWQgY29tbWVudHMgeW91IGFyZSBhd2FyZSBv Zj8NCg0KSSBoYXZlIG5vIGZ1cnRoZXIgY29tbWVudHMsIGFuZCB0aGUgb25seSBjb21tZW50cyBJ IGFtIGF3YXJlIG9mIGFyZSB0aGUgb25lcyBJdm8gYW5kIEJyZXR0IGhhZCBvbiB0aGUgNjY2NS1j bGFyaWZpY2F0aW9uIGRyYWZ0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNClJqUw0KT24g Mi8yOC8xNSA2OjAyIFBNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCmh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNnMDY0ODguaHRtbA0KwqAN CkZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2VudDogMjggRmVicnVhcnkgMjAxNSAwODoxMQ0KVG86 IEFkYW0gUm9hY2g7ICdTSVBDT1JFJzsgSXZvIFNlZGxhY2VrOyBCcmV0dCBUYXRlDQpTdWJqZWN0 OiBSZTogW3NpcGNvcmVdIENvbmNsdWRlZDogV0dMQyAvIENhbGwgZm9yIEFkb3B0aW9uOiBSRUZF Ui1yZWxhdGVkIHdvcmsNCsKgDQpIaSBBZGFtLA0KDQpBIHdoaWxlIGFnbyBJIGhhZCBhIGNvbW1l bnQgb24gdGhlIHJlZmVyLWNsYXJpZmljYXRpb24gZHJhZnQsIHdoaWNoIFJvYmVydCBzYWlkIGhl IHdhcyBnb2luZyB0byBhZGRyZXNzIGR1cmluZyB0aGUgV0dMQy4gDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmUNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEFkYW0gUm9hY2gNClNlbnQ6IOKAjjI4L+KA jjAyL+KAjjIwMTUgMDI6MDgNClRvOiBDaHJpc3RlciBIb2xtYmVyZzsgJ1NJUENPUkUnOyBJdm8g U2VkbGFjZWs7IEJyZXR0IFRhdGUNClN1YmplY3Q6IENvbmNsdWRlZDogV0dMQyAvIENhbGwgZm9y IEFkb3B0aW9uOiBSRUZFUi1yZWxhdGVkIHdvcmsNClthcyBjaGFpcl0NCg0KVGhlIGFkb3B0aW9u IGFuZCBXR0xDIHBlcmlvZCBmb3IgdGhlIHRocmVlIGRvY3VtZW50cyBoYXMgZW5kZWQuIEdpdmVu DQp0aGUgZXhwcmVzc2VkIHN1cHBvcnQgKG1lYWdlciBhcyBpdCB3YXMpIGFuZCBsYWNrIG9mIG9i amVjdGlvbiwgd2UncmUNCmdvaW5nIHRvIGNvbnNpZGVyIHRoZSA2NjY1LWNsYXJpZmljYXRpb25z IGRyYWZ0IGFkb3B0ZWQuDQoNClRoZXJlIHdlcmUgbm8gYWRkaXRpb25hbCBjb21tZW50cyBvbiBy ZWZlci1jbGFyaWZpY2F0aW9ucyBvcg0KcmVmZXItZXhwbGljaXQtc3Vic2NyaXB0aW9uLCBzbyB3 ZSB3aWxsIGJlZ2luIHByZXBhcmluZyB0aGVtIGZvciBJRVNHDQpyZXZpZXcuDQoNClthcyBhdXRo b3JdDQoNCkEgbmV3IHZlcnNpb24gdGhhdCBJIGJlbGlldmUgYWRkcmVzc2VzIHRoZSBvdXRzdGFu ZGluZyBjb21tZW50cyBvbiB0aGUNCjY2NjUgY2xhcmlmaWNhdGlvbiBkb2N1bWVudCBpcyBhdmFp bGFibGUgaGVyZToNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1zaXBjb3JlLTY2NjUtY2xhcmlmaWNhdGlvbi8NCg0KSXZvIC8gQnJldHQ6IGFzIHlvdSB3ZXJl IHRoZSBwZW9wbGUgd2hvIHByb3ZpZGVkIHRoZSBmZWVkYmFjayB0aGF0IEkndmUNCmluY29ycG9y YXRlZCwgcGxlYXNlIGxvb2sgb3ZlciB0aGlzIGxhdGVzdCB0ZXh0IHRvIGxldCBtZSBrbm93IHdo ZXRoZXINCml0IGFkZHJlc3NlcyB0aGUgc3BlY2lmaWMgY29uY2VybiB0aGF0IGhhZCBiZWVuIHJh aXNlZC4gVGhhbmtzIQ0KDQovYQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0K From nobody Tue Mar 3 08:30:14 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8381A885C; Tue, 3 Mar 2015 08:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YNdnptOOCRP; Tue, 3 Mar 2015 08:30:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 514181A8846; Tue, 3 Mar 2015 08:30:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150303163007.15332.95868.idtracker@ietfa.amsl.com> Date: Tue, 03 Mar 2015 08:30:07 -0800 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 16:30:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Clarifications for the use of REFER with RFC6665 Authors : Robert Sparks Adam Roach Filename : draft-ietf-sipcore-refer-clarifications-03.txt Pages : 7 Date : 2015-03-03 Abstract: The SIP REFER method relies on the SIP-Specific Event Notification Framework. That framework was revised by RFC6665. This document highlights the implications of the requirement changes in RFC6665, and updates the definition of the REFER method, RFC3515, to clarify and disambiguate the impact of those changes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-refer-clarifications-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 3 08:30:41 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC071A8853; Tue, 3 Mar 2015 08:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1mpvLN-gYEC; Tue, 3 Mar 2015 08:30:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBE41A92AD; Tue, 3 Mar 2015 08:30:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150303163030.12195.22236.idtracker@ietfa.amsl.com> Date: Tue, 03 Mar 2015 08:30:30 -0800 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-refer-explicit-subscription-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 16:30:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Explicit Subscriptions for the REFER Method Author : Robert Sparks Filename : draft-ietf-sipcore-refer-explicit-subscription-01.txt Pages : 14 Date : 2015-03-03 Abstract: The Session Initiation Protocol (SIP) REFER request, as defined by RFC3515, triggers an implicit SIP-Specific Event Notification framework subscription. Conflating the start of the subscription with handling the REFER request makes negotiating SUBSCRIBE extensions impossible, and complicates avoiding SIP dialog sharing. This document defines extensions to REFER to remove the implicit subscription and, if desired, replace it with an explicit one. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-explicit-subscription/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-refer-explicit-subscription-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-refer-explicit-subscription-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 3 08:36:15 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58011ABC74 for ; Tue, 3 Mar 2015 08:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3N9vBmNL5DLp for ; Tue, 3 Mar 2015 08:36:12 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4160A1A92FC for ; Tue, 3 Mar 2015 08:36:10 -0800 (PST) X-AuditID: c1b4fb25-f79446d000003f3f-0e-54f5e2f864be Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0D.D6.16191.8F2E5F45; Tue, 3 Mar 2015 17:36:09 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.39]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0210.002; Tue, 3 Mar 2015 17:36:08 +0100 From: Ivo Sedlacek To: Adam Roach , Christer Holmberg , 'SIPCORE' , Brett Tate Thread-Topic: Concluded: WGLC / Call for Adoption: REFER-related work Thread-Index: AQHQUuqrW8ODMIaCKUSZtOrUKro6Lp0K7J/A Date: Tue, 3 Mar 2015 16:36:07 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112831A5D@ESESSMB301.ericsson.se> References: <54DA3735.30807@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D6C9D62@ESESSMB209.ericsson.se> <54F106F1.90302@nostrum.com> In-Reply-To: <54F106F1.90302@nostrum.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvje7PR19DDNZO5LTY83cRu0Xz/H+M Fl9/bGJzYPb4cTvQY8mSn0wes3Y+YQlgjuKySUnNySxLLdK3S+DKmHdkCWvBNu6Ke93PmBsY J3B3MXJySAiYSFyZsoQZwhaTuHBvPVsXIxeHkMARRok5z3ZBOYsYJXa2/GQCqWIT0JOYuOUI K0hCRGAmo8TS120sIAlhAReJxye+sYHYIgKuElt2f2eCsI0kZj2+A1TDwcEioCLxYDIjSJhX wFei/+ADRogF3YwS3y92sIMkOAU0JRYvfwY2k1FAVuLqn16wBmYBcYlbT+YzQZwqILFkz3mo s0UlXj7+xwphK0rsPNvODLKLGWjO+l36EK2KElO6H7JD7BWUODnzCcsERtFZSKbOQuiYhaRj FpKOBYwsqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjECI+fglt+qOxgvv3E8xCjAwajEw7tB +WuIEGtiWXFl7iFGaQ4WJXFeO+NDIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYXVafjLi7 1vKhmegloTnKS34eMTZquHdbYPUx9XJe1Yn/Dif+bs9jCTj2mXXGhhsGpgeOTdeYwbGfz/Gp 9YO2dbc/d5Stjrhvd9hXXz897FMPV/BFd74zXvWfvwvwC1WXWu12PdOy+9kmptd2rFsy/v1e +J3VRC+KS29Z+pvz8+d8MOXrupusr8RSnJFoqMVcVJwIALNrZ1p9AgAA Archived-At: Subject: Re: [sipcore] Concluded: WGLC / Call for Adoption: REFER-related work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 16:36:14 -0000 SGVsbG8sDQoNCmRyYWZ0LWlldGYtc2lwY29yZS02NjY1LWNsYXJpZmljYXRpb24tMDAgbmVhcmx5 IHJlc29sdmVzIHRoZSBpc3N1ZSBJIHJhaXNlZCBiZWZvcmUuIFRoYW5rcyBmb3IgdGFraW5nIG15 IGNvbW1lbnQgaW50byBjb25zaWRlcmF0aW9uLg0KDQpIb3dldmVyLCByZWFkaW5nIGRyYWZ0LWll dGYtc2lwY29yZS02NjY1LWNsYXJpZmljYXRpb24tMDAsICJzdWJzY3JpcHRpb24gcmVxdWVzdHMg KGltcGxpY2l0IG9yIGV4cGxpY2l0KSIgaW4gdGhlIGZvbGxvd2luZyB0ZXh0IGlzIHJhdGhlciBo YXJkIHRvIHVuZGVyc3RhbmQuIA0KLS0tLS0tLS0tLS0tDQpOb3RpZmllcnMgTVVTVCB1c2UgYSBH UlVVIGFzIHRoZWlyDQogICBsb2NhbCB0YXJnZXQgZm9yIGFsbCBkaWFsb2ctZm9ybWluZyBtZXRo b2RzIGFuZCBhbGwgdGFyZ2V0LXJlZnJlc2gNCiAgIG1ldGhvZHMsIGV4Y2VwdCBmb3IgdGhvc2Ug ZGlhbG9ncyBmb3Igd2hpY2ggdGhleSB3aWxsIHJlamVjdCBhbGwNCiAgID4+c3Vic2NyaXB0aW9u IHJlcXVlc3RzIChpbXBsaWNpdCBvciBleHBsaWNpdCk8PC4NCi0tLS0tLS0tLS0tLQ0KDQpJdCB3 b3VsZCBiZSBtb3JlIGFwcHJvcHJpYXRlIHRvIHN0YXRlICJyZXF1ZXN0cyB0aGF0IG1pZ2h0IGNy ZWF0ZSBhbiAoaW1wbGljaXQgb3IgZXhwbGljaXQpIHN1YnNjcmlwdGlvbiIgc2ltaWxhcmx5IGFz IHVzZWQgaW4gdGhlIGxhdGVyIHRleHQ6DQotLS0tLS0tLS0tLS0NCkZvciBjbGFyaXR5OiBhbg0K ICAgaW1wbGVtZW50YXRpb24gdGhhdCB1c2VzIGEgbm9uLUdSVVUgbG9jYWwgY29udGFjdCB1bmRl ciB0aGUgZXhjZXB0aW9uDQogICBkZXNjcmliZWQgYWJvdmUgTVVTVCByZWplY3QgYSA+PnJlcXVl c3QgdGhhdCBtaWdodCBjcmVhdGUgYQ0KICAgc3Vic2NyaXB0aW9uPDwgdG8gdGhlIGFzc29jaWF0 ZWQgZGlhbG9nLCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgc3VjaA0KICAgc3Vic2NyaXB0aW9uIHdv dWxkIGJlIGNyZWF0ZWQgYnkgYSBTVUJTQ1JJQkUgb3IgYSBSRUZFUiBtZXNzYWdlLg0KLS0tLS0t LS0tLS0tDQoNCktpbmQgcmVnYXJkcw0KDQpJdm8gU2VkbGFjZWsNCg0K From nobody Tue Mar 3 09:27:49 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343B61AC3E9 for ; Tue, 3 Mar 2015 09:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3ETfzV4Oq8l for ; Tue, 3 Mar 2015 09:27:40 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7A91A870A for ; Tue, 3 Mar 2015 09:27:40 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D09F122E262; Tue, 3 Mar 2015 12:27:34 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Cullen Jennings In-Reply-To: Date: Tue, 3 Mar 2015 10:27:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Olle E Johansson X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: SIPCORE Subject: Re: [sipcore] ;transport=tls X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 17:27:43 -0000 > On Feb 25, 2015, at 11:52 PM, Olle E. Johansson = wrote: >=20 > Like I said in my mail, we frequently use ";transport=3DTLS" to = indicate tls for the next hop in Kamailio. > It's a transport in via, but no longer approved in route headers. >=20 > How would you indicate a need for TLS in Path/Route and similar = headers that needs a SIP URI? >=20 > I think we may need to produce a draft that=20 > - finally kills SIPS: Why? It's dead and nothing the IETF can write on this will have any = impact beyond what they have already said in RFC 5630. Perhaps sipit = needs to tell people to read this but not clear anything we write will = be read any more than 5630 is read. I have seen literally thousands or = very real SIP deployments and I'm not seeing a single one of them use = SIPS so I'm not seeing some huge problem here that somehow causing = problems with the adoption IETF standards.=20 > - solves the problem how to indicate a requirement for TLS in a SIP = URI. RFC 5630 avoided this issue. (Keep in mind I argued for keeping ";transport=3DTLS" but ignoring that) = ... I think the way to make progress here is to state what the problem = is that you think drives the needs for "how to indicate a requirement = for TLS in a SIP URI". "how to indicate a requirement for TLS in a SIP = URI" is more of a solution that requirement or use case. Last time this = was looked at, some people felt that NAPTR or just policy config in = proxy was enough and there was not a need to do it in a URI.=20 So to try and help you, let me tell you what I suspect the problem is = you are trying to solve. Proxies have dial plans that match some pattern = on destination then suggest route to next hop. So you might say things = that are going to a phone number of +1* get routed to sip.att.com as = next hop. Some people wanted to be able to tell the proxy to send SIP = traffic to att over TLS. Some people wanted to be able to tell the proxy = to send over ipv6. So lets start with the obvious, that AT&T can control = what they accept and what their preferences are using DNS (NAPTRY, SRV, = A, AAAA). Here we are only talking about the proxies policy for what it = wants to do assuming it will ignore att preferences. One solution would = be to have the destination route URI have a flag in it saying use v6 = such as "sip:sip.att.com;usev6=3DYES". Another solutions would be just = have a flag in the internal data structure for the proxy that said that = use_v6 is true. Similarly one can indicate TLS by either putting the = flag in the destination URI or putting the flag in the same data = structure that stores the destination URI. But here is the important = point - this is an issue local to the proxy. Once the calls makes it to = att, it will be over v6, or not, or tls and nothing about what the = previous proxy policy matters. This whole thing is not really a matter = of standardization - the proxy can implement it in the URI or not in the = URI or whatever. People argued that trying to embed all possible proxy = policy into a standardized URI just seemed like a bad plan.=20 So is there a problem different from that which needs to be solve here ? >=20 > We may also need to produce a BCP covering how to do TLS in the SIP = protocol, since (just one note BCP are not really this - it would likely be an = informational doc )=20 > there are many documents, some quite contradicting and some = underspecified that Could you point out some the the specific stuff where they are = contradicting? That would be low hanging fruit to fix.=20 > talk about TLS and SIP. It's a maze of twisting passages you easily = get lost in, which > was clearly indicated at SIPit. A hitchhiker's guide to TLS and SIP if = you like. >=20 > If there is a solution, that you produced 10 years ago, = implementations show that you did a lousy > job of telling people, Cullen :-) >=20 > /O >=20 > On 26 Feb 2015, at 02:13, Cullen Jennings wrote: >=20 >>=20 >> I really don't know what there is to comment on. How about you try = and explain what problem you are trying to solve and why the existing = mechanism don't solve that problem.=20 >>=20 >> You email sort of of comes across as "our software uses stuff that = was deprecated 10 years ago and we are sad".=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Feb 19, 2015, at 8:44 PM, Olle E. Johansson = wrote: >>>=20 >>> Hello friends, >>> One week ago I sent this message and have seen no comments. I still = may be wrong, but if not, I think this is an issue that requires further = thought. >>>=20 >>> One of the reasons for bringing this up was a note in the SIPconnect = 2.0 specification about MUST NOT use ;transport=3Dtls that caught my = eye. This requirement doesn't work well with the implementations we = tested at SIPit and there >>> was a lot of discussions around it. While SIP Outbound may solve the = first hop, it doesn't tell me how I can use a URI in a route set or = configuration that implies TLS as a transport without using SIPS: >>>=20 >>> /O >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: "Olle E. Johansson" >>>> Subject: ;transport=3Dtls >>>> Date: 12 Feb 2015 08:02:16 GMT+1 >>>> To: SIPCORE >>>> Cc: Olle E Johansson >>>>=20 >>>> I just wanted to forward an issue discovered at SIPit 31 that I = don't think has been discussed here recently. Correct me if I'm wrong.=20= >>>>=20 >>>> =46rom the summary at https://www.sipit.net/SIPit31_summary >>>>=20 >>>>=20 >>>> "TLS focused testing showed that the use of 'transport=3Dtls' in = Route, >>>> Record-Route, and Contact header fields is still pervasive, if not = universal. >>>> The arguments against it in RFC5630 (was draft-ietf-sip-sips) are = not >>>> compelling to implementers and deployers. Several participants = pointed to the >>>> inconsistency of those arguments with the tokens that appear in Via = headers >>>> registered at >>>> = . >>>> SIPCORE should consider whether to re-instate transport=3Dtls or = provide stronger >>>> documentation for how to indicate TLS over TCP in those header = fields when it >>>> is necessary to do so. " >>>>=20 >>>>=20 >>>> In addition, many implementors added ";transport=3Dtls" to their = contact at registration. >>>> They did not understand that if they do, the SIP URI in the contact = has to match a certificate provided >>>> when the server connects to their UA. For registrations both me and = Robert pointed >>>> with all our available hands to SIP Outbound. >>>>=20 >>>> I guess that before we can deprecate SIPS: we need to go through = this and clarify >>>> a bit. >>>>=20 >>>> In the networks I build we frequently use ;transport=3Dtls to tell = the software used (Kamailio) >>>> to select a TLS transport for the next hop. SIPS: is not an = alternative here as it >>>> affects headers. We have not found any other option. >>>>=20 >>>> /O >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>=20 >=20 >=20 From nobody Tue Mar 3 09:51:18 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5469A1AC3F5 for ; Tue, 3 Mar 2015 09:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZdMoVcjyaCj for ; Tue, 3 Mar 2015 09:51:14 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955BD1AC3F2 for ; Tue, 3 Mar 2015 09:51:14 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t23HpDXF052899 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 3 Mar 2015 11:51:14 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54F5F48C.5030200@nostrum.com> Date: Tue, 03 Mar 2015 11:51:08 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] ;transport=tls X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 17:51:17 -0000 On 3/3/15 11:27 AM, Cullen Jennings wrote: >> On Feb 25, 2015, at 11:52 PM, Olle E. Johansson wrote= : >> >> Like I said in my mail, we frequently use ";transport=3DTLS" to indica= te tls for the next hop in Kamailio. >> It's a transport in via, but no longer approved in route headers. >> >> How would you indicate a need for TLS in Path/Route and similar header= s that needs a SIP URI? >> >> I think we may need to produce a draft that >> - finally kills SIPS: > Why? It's dead and nothing the IETF can write on this will have any imp= act beyond what they have already said in RFC 5630. Cullen - Where in RFC 5630 do you derive "It's dead" from? It's full of text talking about continuing to use sips: Please skim section 5 right quick and note all the clarifying=20 requirements on how to use sips: But, assuming we can derive from this document how to behave if we=20 _don't_ want to use sips:, it would help if you pointed to exactly where = in 5630 you find the best answer for how to populate URIs in a Path or=20 Service-Route header that you want to ensure use TLS. The end of section 3.1.3 is (I think) relying on the proxy having=20 existing state to refer to in order to remember that the sip: URI it=20 provided is associated with a connection that happens to be using TLS.=20 That won't help a proxy dealing with a Path or Service-Route. Below you suggest people use DNS names and rely on NAPTR, but where in=20 the document do we give this advice? The string NAPTR does not appear in = the document afaict. Note also that 3.1.4 still leaves transport=3Dtls in an undefined state. > Perhaps sipit needs to tell people to read this but not clear anything = we write will be read any more than 5630 is read. I have seen literally t= housands or very real SIP deployments and I'm not seeing a single one of = them use SIPS so I'm not seeing some huge problem here that somehow causi= ng problems with the adoption IETF standards. > >> - solves the problem how to indicate a requirement for TLS in a SIP UR= I. RFC 5630 avoided this issue. > (Keep in mind I argued for keeping ";transport=3DTLS" but ignoring that= ) ... I think the way to make progress here is to state what the problem = is that you think drives the needs for "how to indicate a requirement for= TLS in a SIP URI". "how to indicate a requirement for TLS in a SIP URI" = is more of a solution that requirement or use case. Last time this was lo= oked at, some people felt that NAPTR or just policy config in proxy was e= nough and there was not a need to do it in a URI. Lets try the Path and Service-Route part for that. Ole - what breaks if you require people to put in DNS named URIs here=20 that will use NAPTR to indicate TLS is the only thing that should be used= =2E (Also, please do reply to Cullen's question below) > > So to try and help you, let me tell you what I suspect the problem is y= ou are trying to solve. Proxies have dial plans that match some pattern o= n destination then suggest route to next hop. So you might say things tha= t are going to a phone number of +1* get routed to sip.att.com as next ho= p. Some people wanted to be able to tell the proxy to send SIP traffic to= att over TLS. Some people wanted to be able to tell the proxy to send ov= er ipv6. So lets start with the obvious, that AT&T can control what they = accept and what their preferences are using DNS (NAPTRY, SRV, A, AAAA). H= ere we are only talking about the proxies policy for what it wants to do = assuming it will ignore att preferences. One solution would be to have th= e destination route URI have a flag in it saying use v6 such as "sip:sip.= att.com;usev6=3DYES". Another solutions would be just have a flag in the = internal data structure for the proxy that said that use_v6 is true. Simi= larly one can indicate TLS by either putting the flag > in the destination URI or putting the flag in the same data structur= e that stores the destination URI. But here is the important point - this= is an issue local to the proxy. Once the calls makes it to att, it will = be over v6, or not, or tls and nothing about what the previous proxy poli= cy matters. This whole thing is not really a matter of standardization - = the proxy can implement it in the URI or not in the URI or whatever. Peop= le argued that trying to embed all possible proxy policy into a standardi= zed URI just seemed like a bad plan. > > So is there a problem different from that which needs to be solve here = ? > > >> We may also need to produce a BCP covering how to do TLS in the SIP pr= otocol, since > (just one note BCP are not really this - it would likely be an informat= ional doc ) >> there are many documents, some quite contradicting and some underspeci= fied that > Could you point out some the the specific stuff where they are contradi= cting? That would be low hanging fruit to fix. > >> talk about TLS and SIP. It's a maze of twisting passages you easily ge= t lost in, which >> was clearly indicated at SIPit. A hitchhiker's guide to TLS and SIP if= you like. >> >> If there is a solution, that you produced 10 years ago, implementation= s show that you did a lousy >> job of telling people, Cullen :-) > >> /O >> >> On 26 Feb 2015, at 02:13, Cullen Jennings wrote: >> >>> I really don't know what there is to comment on. How about you try an= d explain what problem you are trying to solve and why the existing mecha= nism don't solve that problem. >>> >>> You email sort of of comes across as "our software uses stuff that wa= s deprecated 10 years ago and we are sad". >>> >>> >>> >>> >>> >>>> On Feb 19, 2015, at 8:44 PM, Olle E. Johansson wrot= e: >>>> >>>> Hello friends, >>>> One week ago I sent this message and have seen no comments. I still = may be wrong, but if not, I think this is an issue that requires further = thought. >>>> >>>> One of the reasons for bringing this up was a note in the SIPconnect= 2.0 specification about MUST NOT use ;transport=3Dtls that caught my eye= =2E This requirement doesn't work well with the implementations we tested= at SIPit and there >>>> was a lot of discussions around it. While SIP Outbound may solve the= first hop, it doesn't tell me how I can use a URI in a route set or conf= iguration that implies TLS as a transport without using SIPS: >>>> >>>> /O >>>> >>>> Begin forwarded message: >>>> >>>>> From: "Olle E. Johansson" >>>>> Subject: ;transport=3Dtls >>>>> Date: 12 Feb 2015 08:02:16 GMT+1 >>>>> To: SIPCORE >>>>> Cc: Olle E Johansson >>>>> >>>>> I just wanted to forward an issue discovered at SIPit 31 that I don= 't think has been discussed here recently. Correct me if I'm wrong. >>>>> >>>>> From the summary at https://www.sipit.net/SIPit31_summary >>>>> >>>>> >>>>> "TLS focused testing showed that the use of 'transport=3Dtls' in Ro= ute, >>>>> Record-Route, and Contact header fields is still pervasive, if not = universal. >>>>> The arguments against it in RFC5630 (was draft-ietf-sip-sips) are n= ot >>>>> compelling to implementers and deployers. Several participants poin= ted to the >>>>> inconsistency of those arguments with the tokens that appear in Via= headers >>>>> registered at >>>>> . >>>>> SIPCORE should consider whether to re-instate transport=3Dtls or pr= ovide stronger >>>>> documentation for how to indicate TLS over TCP in those header fiel= ds when it >>>>> is necessary to do so. " >>>>> >>>>> >>>>> In addition, many implementors added ";transport=3Dtls" to their co= ntact at registration. >>>>> They did not understand that if they do, the SIP URI in the contact= has to match a certificate provided >>>>> when the server connects to their UA. For registrations both me and= Robert pointed >>>>> with all our available hands to SIP Outbound. >>>>> >>>>> I guess that before we can deprecate SIPS: we need to go through th= is and clarify >>>>> a bit. >>>>> >>>>> In the networks I build we frequently use ;transport=3Dtls to tell = the software used (Kamailio) >>>>> to select a TLS transport for the next hop. SIPS: is not an alterna= tive here as it >>>>> affects headers. We have not found any other option. >>>>> >>>>> /O >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Mar 4 00:11:22 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637191A066C for ; Wed, 4 Mar 2015 00:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzXtYQSx0Nky for ; Wed, 4 Mar 2015 00:11:15 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEEE31A039F for ; Wed, 4 Mar 2015 00:11:14 -0800 (PST) X-AuditID: c1b4fb30-f79c86d000000fc0-8e-54f6be20767d Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9F.C6.04032.02EB6F45; Wed, 4 Mar 2015 09:11:12 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.39]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0210.002; Wed, 4 Mar 2015 09:11:12 +0100 From: Ivo Sedlacek To: Adam Roach , Christer Holmberg , 'SIPCORE' , Brett Tate Thread-Topic: Concluded: WGLC / Call for Adoption: REFER-related work Thread-Index: AQHQUuqrW8ODMIaCKUSZtOrUKro6Lp0L/dMg Date: Wed, 4 Mar 2015 08:11:11 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112831FC8@ESESSMB301.ericsson.se> References: <54DA3735.30807@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D6C9D62@ESESSMB209.ericsson.se> <54F106F1.90302@nostrum.com> In-Reply-To: <54F106F1.90302@nostrum.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610112831FC8ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3Rldh37cQgxutuhZ7/i5it2ie/4/R 4uuPTWwOzB4/bgd6LFnyk8lj1s4nLAHMUVw2Kak5mWWpRfp2CVwZbR+XMBds8qh48s+xgXGD WxcjB4eEgInE3Kd6XYycQKaYxIV769m6GLk4hASOMEpcv/4AylnEKLF6xy5GkCo2AT2JiVuO sIIkRARmMkosfd3GApIQFnCReHziGxuILSLgKrFl93cmCNtIYu7hT8wgNouAisSR09dZQWxe AV+JKd+OMUNs6GaU+H6xgx0kwSmgKbF4+TOwoYwCshJX//SCbWYWEJe49WQ+E8StAhJL9pxn hrBFJV4+/scK8Y6SxLStaRDl+RK/HnYxQ+wSlDg58wnLBEaRWUgmzUJSNgtJ2SygScxAV6zf pQ9RoigxpfshO4StIdE6Zy47svgCRvZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIFxdnDL b4MdjC+fOx5iFOBgVOLhNSj9FiLEmlhWXJl7iFGag0VJnNfO+FCIkEB6YklqdmpqQWpRfFFp TmrxIUYmDk6pBkZerrdPyq4ksF1+YKg3lfuoCNOHFT9ZHGbIWu7Y/q3v47EAu1fTbjm3T171 STrHNu5AzqyPi9KaWZ+cvHG7eHM3y8+43c9WTl9rtG/Rmx073uieYQrebGvzbV/Wr693HIW1 rpU4OirZr5nZ837aroeZ83e871nE2G/wgOVnH+ON5TZsBzkK+oSslViKMxINtZiLihMB0wRY vZQCAAA= Archived-At: Subject: Re: [sipcore] Concluded: WGLC / Call for Adoption: REFER-related work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 08:11:21 -0000 --_000_39B5E4D390E9BD4890E2B3107900610112831FC8ESESSMB301erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCg0KDQpJIHJldmlld2VkIGRyYWZ0LWlldGYtc2lwY29yZS1yZWZlci1jbGFyaWZp Y2F0aW9ucy0wMyBhbmQgZHJhZnQtaWV0Zi1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0LXN1YnNjcmlw dGlvbi0wMCAgYW5kIGZvdW5kIG5vIGlzc3Vlcy4gT0sgdG8gcHJvZ3Jlc3MgdGhvc2UgZHJhZnRz Lg0KDQpJIHJldmlld2VkIGRyYWZ0LWlldGYtc2lwY29yZS02NjY1LWNsYXJpZmljYXRpb24tMDAg YW5kIHNlbnQgYSBjb21tZW50IHRvIHRoZSBTSVBDT1JFIGxpc3QgeWVzdGVyZGF5IChodHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50L21zZzA2NTYxLmh0 bWwpLiBJIHByZWZlciB0aGUgY29tbWVudCBiZWluZyBhZGRyZXNzZWQgYmVmb3JlIHByb2dyZXNz aW5nIHRoZSBkcmFmdC4NCg0KS2luZCByZWdhcmRzDQoNCkl2byBTZWRsYWNlaw0KDQoNCg0KVGhp cyBDb21tdW5pY2F0aW9uIGlzIENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZl IGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdCB3d3cuZXJpY3Nzb24u Y29tL2VtYWlsX2Rpc2NsYWltZXINCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBBZGFtIFJvYWNoIFttYWlsdG86YWRhbUBub3N0cnVtLmNvbV0NClNlbnQ6IDI4LiDDum5v cmEgMjAxNSAxOjA4DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmc7ICdTSVBDT1JFJzsgSXZvIFNlZGxh Y2VrOyBCcmV0dCBUYXRlDQpTdWJqZWN0OiBDb25jbHVkZWQ6IFdHTEMgLyBDYWxsIGZvciBBZG9w dGlvbjogUkVGRVItcmVsYXRlZCB3b3JrDQoNCg0KDQpbYXMgY2hhaXJdDQoNCg0KDQpUaGUgYWRv cHRpb24gYW5kIFdHTEMgcGVyaW9kIGZvciB0aGUgdGhyZWUgZG9jdW1lbnRzIGhhcyBlbmRlZC4g R2l2ZW4gdGhlIGV4cHJlc3NlZCBzdXBwb3J0IChtZWFnZXIgYXMgaXQgd2FzKSBhbmQgbGFjayBv ZiBvYmplY3Rpb24sIHdlJ3JlIGdvaW5nIHRvIGNvbnNpZGVyIHRoZSA2NjY1LWNsYXJpZmljYXRp b25zIGRyYWZ0IGFkb3B0ZWQuDQoNCg0KDQpUaGVyZSB3ZXJlIG5vIGFkZGl0aW9uYWwgY29tbWVu dHMgb24gcmVmZXItY2xhcmlmaWNhdGlvbnMgb3IgcmVmZXItZXhwbGljaXQtc3Vic2NyaXB0aW9u LCBzbyB3ZSB3aWxsIGJlZ2luIHByZXBhcmluZyB0aGVtIGZvciBJRVNHIHJldmlldy4NCg0KDQoN ClthcyBhdXRob3JdDQoNCg0KDQpBIG5ldyB2ZXJzaW9uIHRoYXQgSSBiZWxpZXZlIGFkZHJlc3Nl cyB0aGUgb3V0c3RhbmRpbmcgY29tbWVudHMgb24gdGhlDQoNCjY2NjUgY2xhcmlmaWNhdGlvbiBk b2N1bWVudCBpcyBhdmFpbGFibGUgaGVyZToNCg0KDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2lwY29yZS02NjY1LWNsYXJpZmljYXRpb24vDQoNCg0KDQpJ dm8gLyBCcmV0dDogYXMgeW91IHdlcmUgdGhlIHBlb3BsZSB3aG8gcHJvdmlkZWQgdGhlIGZlZWRi YWNrIHRoYXQgSSd2ZSBpbmNvcnBvcmF0ZWQsIHBsZWFzZSBsb29rIG92ZXIgdGhpcyBsYXRlc3Qg dGV4dCB0byBsZXQgbWUga25vdyB3aGV0aGVyIGl0IGFkZHJlc3NlcyB0aGUgc3BlY2lmaWMgY29u Y2VybiB0aGF0IGhhZCBiZWVuIHJhaXNlZC4gVGhhbmtzIQ0KDQoNCg0KL2ENCg== --_000_39B5E4D390E9BD4890E2B3107900610112831FC8ESESSMB301erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1z b1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBs YWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5IZWxsbyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ SSByZXZpZXdlZCBkcmFmdC1pZXRmLXNpcGNvcmUtcmVmZXItY2xhcmlmaWNhdGlvbnMtMDMgYW5k IGRyYWZ0LWlldGYtc2lwY29yZS1yZWZlci1leHBsaWNpdC1zdWJzY3JpcHRpb24tMDAmbmJzcDsg YW5kIGZvdW5kIG5vIGlzc3Vlcy4gT0sgdG8gcHJvZ3Jlc3MgdGhvc2UgZHJhZnRzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5JIHJldmlld2VkIGRyYWZ0LWlldGYtc2lwY29yZS02NjY1LWNsYXJp ZmljYXRpb24tMDAgYW5kIHNlbnQgYSBjb21tZW50IHRvIHRoZSBTSVBDT1JFIGxpc3QgeWVzdGVy ZGF5ICg8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwY29y ZS9jdXJyZW50L21zZzA2NTYxLmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNnMDY1NjEuaHRtbDwvYT4pLg0KIEkgcHJlZmVyIHRoZSBj b21tZW50IGJlaW5nIGFkZHJlc3NlZCBiZWZvcmUgcHJvZ3Jlc3NpbmcgdGhlIGRyYWZ0LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5LaW5kIHJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ SXZvIFNlZGxhY2VrIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGlzIENvbW11bmlj YXRpb24gaXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24g dGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0IHd3dy5lcmljc3Nvbi5jb20vZW1haWxf ZGlzY2xhaW1lcg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogQWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5j b21dIDxicj4NClNlbnQ6IDI4LiDDum5vcmEgMjAxNSAxOjA4PGJyPg0KVG86IENocmlzdGVyIEhv bG1iZXJnOyAnU0lQQ09SRSc7IEl2byBTZWRsYWNlazsgQnJldHQgVGF0ZTxicj4NClN1YmplY3Q6 IENvbmNsdWRlZDogV0dMQyAvIENhbGwgZm9yIEFkb3B0aW9uOiBSRUZFUi1yZWxhdGVkIHdvcms8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPlthcyBjaGFpcl08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+VGhlIGFkb3B0aW9uIGFuZCBXR0xDIHBlcmlvZCBmb3IgdGhlIHRocmVlIGRvY3VtZW50cyBo YXMgZW5kZWQuIEdpdmVuIHRoZSBleHByZXNzZWQgc3VwcG9ydCAobWVhZ2VyIGFzIGl0IHdhcykg YW5kIGxhY2sgb2Ygb2JqZWN0aW9uLCB3ZSdyZSBnb2luZyB0byBjb25zaWRlciB0aGUgNjY2NS1j bGFyaWZpY2F0aW9ucyBkcmFmdCBhZG9wdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5UaGVyZSB3ZXJlIG5vIGFkZGl0aW9uYWwgY29tbWVudHMgb24gcmVmZXItY2xhcmlmaWNhdGlv bnMgb3IgcmVmZXItZXhwbGljaXQtc3Vic2NyaXB0aW9uLCBzbyB3ZSB3aWxsIGJlZ2luIHByZXBh cmluZyB0aGVtIGZvciBJRVNHIHJldmlldy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ W2FzIGF1dGhvcl08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QSBuZXcgdmVyc2lvbiB0 aGF0IEkgYmVsaWV2ZSBhZGRyZXNzZXMgdGhlIG91dHN0YW5kaW5nIGNvbW1lbnRzIG9uIHRoZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+NjY2NSBjbGFyaWZpY2F0aW9u IGRvY3VtZW50IGlzIGF2YWlsYWJsZSBoZXJlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNp cGNvcmUtNjY2NS1jbGFyaWZpY2F0aW9uLyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtc2lwY29yZS02NjY1LWNsYXJpZmljYXRpb24vPC9zcGFuPjwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+SXZvIC8gQnJldHQ6IGFzIHlvdSB3ZXJlIHRoZSBwZW9wbGUg d2hvIHByb3ZpZGVkIHRoZSBmZWVkYmFjayB0aGF0IEkndmUgaW5jb3Jwb3JhdGVkLCBwbGVhc2Ug bG9vayBvdmVyIHRoaXMgbGF0ZXN0IHRleHQgdG8gbGV0IG1lIGtub3cgd2hldGhlciBpdCBhZGRy ZXNzZXMgdGhlIHNwZWNpZmljIGNvbmNlcm4gdGhhdCBoYWQgYmVlbiByYWlzZWQuIFRoYW5rcyE8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+L2E8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_39B5E4D390E9BD4890E2B3107900610112831FC8ESESSMB301erics_-- From nobody Wed Mar 4 09:41:30 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5B41A9142 for ; Wed, 4 Mar 2015 09:41:28 -0800 (PST) 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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nq7ZHd2i6rRd for ; Wed, 4 Mar 2015 09:41:27 -0800 (PST) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090F81A9166 for ; Wed, 4 Mar 2015 09:41:00 -0800 (PST) Received: by qgaj5 with SMTP id j5so834188qga.12 for ; Wed, 04 Mar 2015 09:41:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=amVzJAYPqfK8RV5yqq6u4dH8HpeSNbzZyUDi3GHCg/s=; b=ZHAY6Z1ySVC54q397VYGajsn6DUl/M4tICRCq4EQduKapgBK9NrQPcbfHMzVmS6kSY MkA7WfWghQ2hXhGNTDmzVDT5qj8EaHTzRMq4CIXadV4PRrut7iDfq0ZAaZmNoLgrFNI+ FKImUn3eDIS6ds7jNH/QB3rPfsL5J0WThbPP4eYwQYl29ZLDqqSgpq22jgnZy6lw3lph QucqqsFmLpxwes6pmMkKYd1VgFsNXuzEuYHWJf9cOnEVrmd7DU9yC+Ldz4rQBExFIiDg KbOR107wlTnqwdpwuaCKKxnZIYkg3SMeh3RuFRQSwaJzieNoQ0ne619FQAKG0SuYTHVU EYpQ== X-Gm-Message-State: ALoCoQnFIOKdeJb1ZEjGEGOxd/m/3RrXu42VQqy4yg+7BYP5lIxALftsBEj4TChLAuZcNA48Jej0 X-Received: by 10.229.68.136 with SMTP id v8mr7485954qci.16.1425490860206; Wed, 04 Mar 2015 09:41:00 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBWokOHsByySffSTl2nHfhLhrzDnA== Date: Wed, 4 Mar 2015 12:40:58 -0500 Message-ID: <14335066f1d02c25df6eb6c3d81af23e@mail.gmail.com> To: draft-ietf-sipcore-6665-clarification@tools.ietf.org, sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [sipcore] draft-ietf-sipcore-6665-clarification-00: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 17:41:28 -0000 Hi, The following are some comments concerning draft-ietf-sipcore-6665-clarification-00. Thanks, Brett ------ 1) Section 1: RFC2119 should be RFC6665. 2) Section 2 paragraph 5: Should potentially change "obscure cases" to "cases". The situation can be as simple as an RFC 3725 3PCC device willing to accept REFER associated with some dialogs but not others. 3) Section 2 paragraph 5: Concerning "(although the use of GRUUs in such a context causes no harm, either)", it is only true if you exclude things such as the Security Considerations mentioned within RFC 5627. Thus it potentially should be removed or reworded. 4) Section 3: Should potentially mention RFC 5627 since the clarification also clarifies that the RFC 5627 security issues apply to all notifiers (or the location they supplied within the Contact). From nobody Wed Mar 4 13:31:04 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125F31A1BDE; Wed, 4 Mar 2015 13:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.299 X-Spam-Level: X-Spam-Status: No, score=-99.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPYk6DF-gC8E; Wed, 4 Mar 2015 13:31:01 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0AB41A1ABF; Wed, 4 Mar 2015 13:31:00 -0800 (PST) Received: by labmn12 with SMTP id mn12so11277486lab.2; Wed, 04 Mar 2015 13:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+VNF/mTVoB0RsnIdDEyXaByTKaOr2NXdwo3Prf7sEkE=; b=cTb6sGJ70O724w6fCSpxMegmTLyd5GAGhkkKqX41V0Hotrh4XMNr11MYhGQYYJ4/pV 72E8rB/2ylUQhqfeKOF1foXLd4u+95Q3PNoYSei+DWZug9REZSx7F2AavZ5oxZRPV2km HlvmYGUp1+PuLBmtw8Rvw8Y/e1Naqq7MIpS7jcBfhrQBaE+WixtFUh7Yewe251l3MSos wVNBVVeKlZxPw9CHEHgM8YncpC6YRiamOAZA61TVBM5nsqNM1MDxdpOZSG29pM6nSJ0P RG+P3CFiEJ9Y7VdEhtN9TD4FstK8Jb/ro3khdQFh6uwoNkGrBs4ZUI9sVksVZwwKdVAw kgvw== MIME-Version: 1.0 X-Received: by 10.112.8.68 with SMTP id p4mr5080341lba.37.1425504659262; Wed, 04 Mar 2015 13:30:59 -0800 (PST) Received: by 10.25.17.222 with HTTP; Wed, 4 Mar 2015 13:30:59 -0800 (PST) In-Reply-To: <54f7745d.c53cec0a.266a.ffffc20aSMTPIN_ADDED_BROKEN@mx.google.com> References: <54f7745d.c53cec0a.266a.ffffc20aSMTPIN_ADDED_BROKEN@mx.google.com> Date: Wed, 4 Mar 2015 15:30:59 -0600 Message-ID: From: Mary Barnes To: DISPATCH , SIPCORE Content-Type: multipart/alternative; boundary=001a1135e3d2d7550505107d2acb Archived-At: Subject: [sipcore] Fwd: [SIPForum-techwg] Submit Your SIPNOC 2015 Speaking Proposal Today! X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 21:31:04 -0000 --001a1135e3d2d7550505107d2acb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I thought this might be of interest to folks in these WGs. If you've not been to SIPNOC, this might be a good opportunity to submit a proposal and/or attend and hear what the folks that deploy SIP networks are dealing with. Regards, Mary. ---------- Forwarded message ---------- From: Marc Robins Date: Wed, Mar 4, 2015 at 3:06 PM Subject: [SIPForum-techwg] Submit Your SIPNOC 2015 Speaking Proposal Today! To: techwg@sipforum.org SIP Forum TechWG Members: There=E2=80=99s still time to submit your proposal for SIPNOC 2015 workshop= s, panels, speaker presentations and =E2=80=9CBirds of a Feather=E2=80=9D sess= ions addressing the deployment of SIP in service provider environments. To view the official call for presentations, which includes instructions on submitting material and specific SIPNOC policies, please visit www.sipforum.org/content/view/374/275/. To submit, visit https://www.easychair.org/conferences/?conf=3Dsipnoc2015. Topics can include SIP peering, SIP trunking, Emergency Services, Congestion Control, Scaling and Capacity Issues, SIP-based applications, Routing, Security, SIP-Network Operations Center Best Practices, IPv6 deployment challenges, User-agent Configuration, Standardization Issues and Progress, HD voice deployments, Video Interoperability, WebRTC and SIP, FoIP/T.38 Deployment, Testing or other issues facing SIP network operations. SIPNOC 2015 offers several different types of speaking opportunities including: - General Session Talks: A General Session presentation should be on a topic of interest to the general SIPNOC audience, and may be up to 30 minutes long (including time for Q&A). - General Session Panel Discussions: Panels are sessions with a moderator and a team of experts. The panel moderator should submit an abstract on the panel topic, a list of panelists, and how the panel will= be organized. Panel selection is based on the importance, originality, focu= s and timeliness of the topic, expertise of proposed panelists, as well as the potential for informative and controversial discussion. - Special Workshops: These are workshops that run for 1-2 hours, providing time to focus in-depth on a variety of issues important to the SIPNOC community. Topics can include a review of SIP RFCs and standards development, the regulatory environment, etc. - Research Topics: Researchers are invited to present short summaries of their work for operator feedback. Topics may include call routing, netwo= rk performance, statistical measurement and analysis and protocol developme= nt and implementation. Studies presented may be works in progress. Research= ers from academia, government, and industry are encouraged to present. - BOFs: BOFs (Birds of a Feather sessions) are informal sessions on topics which are of interest to a portion of the SIPNOC community. BOFs = may be held in break=E2=80=90out areas or in an unscheduled room. Requests f= or scheduled BOFs can be made at any time, including on site at the confere= nce. ------------------------------ *SIPNOC 2015 General Info* The SIPNOC 2015 event website is located at www.sipnoc.org. Registration for SIPNOC 2015 is officially open! Special pricing for SIPNOC 2015 is now in effect! Take advantage of special early-bird pricing now through March 15, 2015. The regular SIPNOC 2015 conference registration fee is $995, but for a limited time regular attendees can save $100 and pay only $895 for three days of conference proceedings. This fee includes a special SIP Training Day the first day of the event on June 23, a Welcome Reception that evening with food and drink; breakfast, lunch and break refreshments and snacks during the conference; and a special dinner =E2=80=9CBeer and Gear=E2=80=9D networking reception t= he second night of the event. *Individuals from SIP Forum Full Member companies save even more ($245 off the regular price to be exact with special early-bird pricing)! Please contact Marc Robins, SIP Forum President and Managing Director, at marc.robins@sipforum.org to obtain the exclusive Full Member discount code.* Register today at http://www.regonline.com/sipnoc2015. ------------------------------ *SIPNOC 2015 Sponsorship Information* There are still a number of great sponsorship opportunities remaining. For information about corporate sponsorship opportunities at SIPNOC 2015, please contact Marc Robins, SIP Forum President and Managing Director, at 203-829-6307 or marc.robins@sipforum.org. ------------------------------ All best, Marc ************************* Marc Robins President and Managing Director SIP Forum http://www.sipforum.org Mobile: 203-829-6307 SkypeMe! marcrobins ************************* _______________________________________________ techwg mailing list Send mail to: techwg@sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techw= g --001a1135e3d2d7550505107d2acb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I thought this might be of interest to folks in these WGs.= =C2=A0 If you've not been to SIPNOC, this might be a good opportunity t= o submit a proposal and/or attend and hear what the folks that deploy SIP n= etworks are dealing with.=C2=A0

Regards,
Mary.= =C2=A0

---------- Forwarded messag= e ----------
From: Marc Robins <marc.robins@sipf= orum.org>
Date: Wed, Mar 4, 2015 at 3:06 PM
Subject: [S= IPForum-techwg] Submit Your SIPNOC 2015 Speaking Proposal Today!
To: techwg@sipforum.org


SIP Forum TechWG Members= :

There=E2=80=99s still time to submit your proposal for SIPNOC 2015 workshops, panels, sp= eaker presentations and =E2=80=9CBirds of a Feather=E2=80=9D sessions addre= ssing the deployment of SIP in service provider environments.=

To view the official call for presentations, which includes instr= uctions on submitting material and specific SIPNOC policies, please visit <= a href=3D"http://www.sipforum.org/content/view/374/275/" target=3D"_blank">= www.sipforum.org/content/view/374/275/. To submit, visit ht= tps://www.easychair.org/conferences/?conf=3Dsipnoc2015.

Topics can include SIP peering, SIP trunking, Emergency Services, C= ongestion Control, Scaling and Capacity Issues, SIP-based applications, Rou= ting, Security, SIP-Network Operations Center Best Practices, IPv6 deployme= nt challenges, User-agent Configuration, Standardization Issues and Progres= s, HD voice deployments, Video Interoperability, WebRTC and SIP, FoIP/T.38 = Deployment, Testing or other issues facing SIP network operations. <= u>

SIPNOC 2015 offers several different types of speaking oppo= rtunities including:

  • General Session Talks: A Gener= al Session presentation should be on a topic of interest to the general SIP= NOC audience, and may be up to 30 minutes long (including time for Q&A)= .
  • General Session Panel Discussions: Panels are sessions with a mod= erator and a team of experts. The panel moderator should submit an abstract= on the panel topic, a list of panelists, and how the panel will be organiz= ed. Panel selection is based on the importance, originality, focus and time= liness of the topic, expertise of proposed panelists, as well as the potent= ial for informative and controversial discussion.
    • =
  • Special Workshops:= These are workshops that run for 1-2 hours, providing time to focus in-dep= th on a variety of issues important to the SIPNOC community. Topics can inc= lude a review of SIP RFCs and standards development, the regulatory environ= ment, etc.
  • Research Topics: Researchers are invited to present short= summaries of their work for operator feedback. Topics may include call rou= ting, network performance, statistical measurement and analysis and protoco= l development and implementation. Studies presented may be works in progres= s. Researchers from academia, government, and industry are encouraged to pr= esent.
  • BOFs: BOFs (Birds of a Feather sessions) are informal session= s on topics which are of interest to a portion of the SIPNOC community. BOF= s may be held in break=E2=80=90out areas or in an unscheduled room. Request= s for scheduled BOFs can be made at any time, including on site at the conf= erence.

SIPNOC 2015 General Info<= /span>

The SIPNOC 2015 event website is located at www.sipnoc.org.<= /p>

Registration for SIPNOC 2015 is officially open!

=

S= pecial pricing for SIPNOC 2015 is now in effect! Take advantage of special = early-bird pricing now through March 15, 2015. The regular SIPNOC 2015 conf= erence registration fee is $995, but for a limited time regular attendees c= an save $100 and pay only $895 for three days of conference proceedings. Th= is fee includes a special SIP Training Day the first day of the event on Ju= ne 23, a Welcome Reception that evening with food and drink; breakfast, lun= ch and break refreshments and snacks during the conference; and a special d= inner =E2=80=9CBeer and Gear=E2=80=9D networking reception the second night= of the event.

Individuals from SIP = Forum Full Member companies save even more ($245 off the regular price to b= e exact with special early-bird pricing)! Please contact Marc Robins, SIP F= orum President and Managing Director, at marc.robins@sipforum.org to obtain the excl= usive Full Member discount code.

Register today = at http:/= /www.regonline.com/sipnoc2015.=C2=A0

SIPNOC 2015 Sponsorship Information

There a= re still a number of great sponsorship opportunities remaining. For informa= tion about corporate sponsorship opportunities at SIPNOC 2015, please conta= ct Marc Robins, SIP Forum President and Managing Director, at 203-829-6307 o= r marc.robins= @sipforum.org.

=C2=A0

=C2=A0

All best,

= =C2=A0

Marc

=C2=A0<= /p>

*******************= ******

Marc Robins

President and Managing Director=

SIP Forum

http://www.sipforum.org

Mobile: 203-829-6307

SkypeMe! marcrobins

=C2=A0=

******************= *******

=C2=A0=


_______________________________________________
techwg mailing list
Send mail to: techwg@sipforum.org
Unsubscribe or edit options at:=C2=A0 http://sipforum.org/mailman/listinfo/t= echwg


--001a1135e3d2d7550505107d2acb-- From nobody Mon Mar 9 05:26:31 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A93B1A887E for ; Mon, 9 Mar 2015 05:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6QPpVlUR3vv for ; Mon, 9 Mar 2015 05:26:25 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B60A1A8884 for ; Mon, 9 Mar 2015 05:26:24 -0700 (PDT) X-AuditID: c1b4fb2d-f79aa6d00000359d-00-54fd916dd984 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1E.42.13725.D619DF45; Mon, 9 Mar 2015 13:26:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0210.002; Mon, 9 Mar 2015 13:26:21 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Content-Disposition questions Thread-Index: AdBaY9SoDDjiuJSCSNy+9rzo9dcbww== Date: Mon, 9 Mar 2015 12:26:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D73005D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D73005DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvjW7exL8hBu3NvBZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtlFXawFHdYV21tfsDUwXjTuYuTkkBAwkbjSf4sRwhaTuHBv PVsXIxeHkMARRolZs68xQTiLGSWWztrP2sXIwcEmYCHR/U8bpEFEQFNi+bet7CC2sICaxKOD TewQcW2J2/vmMkPYehJnvq4GW8AioCLRP2UzC4jNK+ArsXTSYjCbEWjx91NrmEBsZgFxiVtP 5jNBHCQgsWTPeWYIW1Ti5eN/rBC2ksSPDZdYIOrzJRbufckEMVNQ4uTMJywTGIVmIRk1C0nZ LCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjaHFqcXFuupGxXmpRZnJxcX6eXl5q ySZGYEwc3PJbdwfj6teOhxgFOBiVeHgLrvwJEWJNLCuuzD3EKM3BoiTOa2d8KERIID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QDo1SxgqJ5zJd/mg9tt2ldmtgVcZRRuyyFc/XPx2tTfd1WqZct z+7oWCB+cpGPcP2NSYYRBg/0Jggndz8WKL8Q12x/5OfptS8+/Q8xzHwv9Mtj47LDru4/1Qp3 3A5wbPZv19/24MvBt/waGyK5rPV3yXAal192ZuPnZmnJVLJ9LhgkduJx9j8xJZbijERDLeai 4kQAs9wV7WoCAAA= Archived-At: Subject: [sipcore] Content-Disposition questions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 12:26:30 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D73005DESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 20.11 of RFC 3261 says: "For backward-compatibility, if the Content-Disposition header fiel= d is missing, the server SHOULD assume bodies of Content-Type application/sdp are the disposition "session", while other content types are "render"." Section 20.11 also says: "The handling parameter, handling-param, describes how the UAS shou= ld react if it receives a message body whose content type or dispositi= on type it does not understand. The parameter has defined values of "optional" and "required". If the handling parameter is missing, th= e value "required" SHOULD be assumed. The handling parameter is described in RFC 3204 [19]. QUESTION_1: If the C-D header field is missing, and the default disposition= type value ("render") is assumed, shall then the default handling value ("= required") also be assumed? RFC 3204, which RFC 3261 refers to, says that the default disposition type = value for ISUP and QSIG bodies are "signal". QUESTION_2: If, for a specific message body, the "render" default type can = be overwritten, shouldn't that be mentioned in 3261? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D73005DESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Section 20.11 of RFC 3261 says:=

 

        “=
;For backward-compatibility, if the Content-Disposition header field
        is missing,=
 the server SHOULD assume bodies of Content-Type
        application=
/sdp are the disposition "session", while other content
        types are &=
quot;render".”

 

Section 20.11 also says:

 

        “=
;The handling parameter, handling-param, describes how the UAS should<=
/o:p>
        react if it=
 receives a message body whose content type or disposition
        type it doe=
s not understand. The parameter has defined values of

        "optio=
nal" and "required". If the handling parameter is missing, t=
he


        value "=
;required" SHOULD be assumed. The handling parameter is


        described i=
n RFC 3204 [19].


 


 


QUESTION_1: If=
 the C-D header field is missing, and the default disposition type value (&=
#8220;render”) is assumed, shall then the default handling value (=
220;required”) also be assumed?


 


 


 


RFC 3204, which RFC 3261 refers to, says that the=
 default disposition type value for ISUP and QSIG bodies are “signal&=
#8221;.


 


QUESTION_2: If=
, for a specific message body, the “render” default type can be=
 overwritten, shouldn’t that be mentioned in 3261?<=
/pre>

 


 


Regards,


 


Christer


 
--_000_7594FB04B1934943A5C02806D1A2204B1D73005DESESSMB209erics_-- From nobody Mon Mar 9 06:56:51 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA071A88F6 for ; Mon, 9 Mar 2015 06:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKyiR1cCNOuY for ; Mon, 9 Mar 2015 06:56:48 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20C01A87DF for ; Mon, 9 Mar 2015 06:54:28 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-12v.sys.comcast.net with comcast id 1Rty1q0032LrikM01RuUGM; Mon, 09 Mar 2015 13:54:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-12v.sys.comcast.net with comcast id 1RuT1q00M3Ge9ey01RuTfW; Mon, 09 Mar 2015 13:54:28 +0000 Message-ID: <54FDA613.8000800@alum.mit.edu> Date: Mon, 09 Mar 2015 09:54:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D73005D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D73005D@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1425909268; bh=Rze6k3P9Pp6MNdZriT44A4JmQM9e8d6kMz/iw20cIeQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AvjnspknD0AlkdSIq30LqLA8nK1vRMkl5U2rTKOAjXXZtemM+P+ntBxmhP8E0XUxr 0raALgJU6NGgWVenKW7wXJ/Y/tl85C0iGl+qIgOouhS52TO2DBBEUCjr14a9atSbSB CfVPvIGeO69+WrMgKRPl68A6f5oBCFOaoIkxxuFCk6OBANhphrCuGKzb/akkIiacpP cHUEELiCNuMSIaSrdf6vfrDPCWb4UB1w2mj1i2sEDGS+37d7mJj1gGZMduRccTtEW4 U6HZ+ElsoqFdOndhNsefn4BOb9k3/hukCVfG3gzeG3hRHr6My8WCJJsoEi1njK0o6T NuZ1qpg+IDd9w== Archived-At: Subject: Re: [sipcore] Content-Disposition questions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 13:56:50 -0000 On 3/9/15 8:26 AM, Christer Holmberg wrote: > Hi, > > Section 20.11 of RFC 3261 says: > > “For backward-compatibility, if the Content-Disposition header field > > is missing, the server SHOULD assume bodies of Content-Type > > application/sdp are the disposition "session", while other content > > types are "render".” > > Section 20.11 also says: > > “The handling parameter, handling-param, describes how the UAS should > > react if it receives a message body whose content type or disposition > > type it does not understand. The parameter has defined values of > > "optional" and "required". If the handling parameter is missing, the > > value "required" SHOULD be assumed. The handling parameter is > > described in RFC 3204 [19]. > > *QUESTION_1*: If the C-D header field is missing, and the default disposition type value (“render”) is assumed, shall then the default handling value (“required”) also be assumed? My personal opinion is that yes "required" is what it *should* be. It is less clear whether an implementation that treats it as "optional" can be accused of being non-compliant. > RFC 3204, which RFC 3261 refers to, says that the default disposition type value for ISUP and QSIG bodies are “signal”. > > *QUESTION_2*: If, for a specific message body, the “render” default type can be overwritten, shouldn’t that be mentioned in 3261? Yes. It is quite evident that 3261 didn't give enough thought to Content-Disposition. You didn't mention RFC5621. It has a section on C-D and it updates 3261. But it doesn't totally address the issues you mention here. IMO it would be reasonable to file an erratum on this. I don't know that it needs another 3261 update at this time. Thanks, Paul > Regards, > > > > Christer > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Mar 9 08:54:20 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9FB1A873A for ; Mon, 9 Mar 2015 08:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdh_6GqEESVb for ; Mon, 9 Mar 2015 08:54:16 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 63BF31A88B8 for ; Mon, 9 Mar 2015 08:53:59 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 165EF23F0411; Mon, 9 Mar 2015 16:53:58 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.173]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0224.002; Mon, 9 Mar 2015 16:53:57 +0100 From: "Stach, Thomas" To: Christer Holmberg , "sipcore@ietf.org" Thread-Topic: Content-Disposition questions Thread-Index: AdBaY9SoDDjiuJSCSNy+9rzo9dcbwwAG+ntA Date: Mon, 9 Mar 2015 15:53:57 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D73005D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D73005D@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Content-Disposition questions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 15:54:18 -0000 Christer, I don't know if that helps with your question, but if you tunnel QSIG over = SIP it would most likely done using ECMA-355=20 or the ISO's equivalent IS 22535 Here, the handling parameter would be set to "required". - http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-355.pdf= =20 - http://standards.iso.org/ittf/PubliclyAvailableStandards/c052060_ISO_IEC_= 22535_2009(E).zip =20 Regards Thomas From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: Montag, 9. M=E4rz 2015 13:26 To: sipcore@ietf.org Subject: [sipcore] Content-Disposition questions Hi, Section 20.11 of RFC 3261 says: =A0=A0=A0=A0=A0=A0=A0 "For backward-compatibility, if the Content-Dispositi= on header field =A0=A0 =A0=A0=A0=A0 is missing, the server SHOULD assume bodies of Content-= Type =A0=A0 =A0=A0=A0=A0 application/sdp are the disposition "session", while ot= her content =A0=A0 =A0=A0=A0=A0 types are "render"." Section 20.11 also says: =A0=A0=A0=A0=A0=A0=A0 "The handling parameter, handling-param, describes ho= w the UAS should =A0=A0 =A0=A0=A0=A0 react if it receives a message body whose content type = or disposition =A0=A0 =A0=A0=A0=A0 type it does not understand. The parameter has defined = values of =A0=A0 =A0=A0=A0=A0 "optional" and "required". If the handling parameter is= missing, the =A0=A0 =A0=A0=A0=A0 value "required" SHOULD be assumed. The handling parame= ter is =A0=A0 =A0=A0=A0=A0 described in RFC 3204 [19]. QUESTION_1: If the C-D header field is missing, and the default disposition= type value ("render") is assumed, shall then the default handling value ("= required") also be assumed? RFC 3204, which RFC 3261 refers to, says that the default disposition type = value for ISUP and QSIG bodies are "signal". QUESTION_2: If, for a specific message body, the "render" default type can = be overwritten, shouldn't that be mentioned in 3261? Regards, Christer From lfw_frank@163.com Mon Mar 9 23:28:56 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68E21A1B83 for ; Mon, 9 Mar 2015 23:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.809 X-Spam-Level: ** X-Spam-Status: No, score=2.809 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_220=2.118, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDkMZjVCIivn for ; Mon, 9 Mar 2015 23:28:52 -0700 (PDT) Received: from m13-128.163.com (m13-128.163.com [220.181.13.128]) by ietfa.amsl.com (Postfix) with ESMTP id C15B11A6F2B for ; Mon, 9 Mar 2015 23:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=YsxRo +9ULeZPf7i6K7uyTLpauYs9nkqOyrsbcMPvt1o=; b=NGiFuvnUUi3cu6hEC61Zx Ksdk8CZ4JmNSjvVYVAcypSVZ7FV3g+7MxJ7WnUxmszaLNEab6l0zg217Gc6px7M9 kahwuk53XCqbai1cFoOcrFKPZqtf1OCWGXRahYJnFp0HjqLeIs1CGZaMn9/Afhk2 B7qdLUfya7vjDV+dkn/BGo= Received: from lfw_frank$163.com ( [223.104.3.138] ) by ajax-webmail-wmsvr128 (Coremail) ; Tue, 10 Mar 2015 14:28:47 +0800 (CST) X-Originating-IP: [223.104.3.138] Date: Tue, 10 Mar 2015 14:28:47 +0800 (CST) From: lfw_frank To: sipcore@ietf.org X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20150119(59087.7062) Copyright (c) 2002-2015 www.mailtech.cn 163com X-CM-CTRLDATA: R2Qs12Zvb3Rlcl9odG09MTI4Mzo4MQ== Content-Type: multipart/alternative; boundary="----=_Part_325661_286895833.1425968927488" MIME-Version: 1.0 Message-ID: <267098f4.14b60.14c025f1300.Coremail.lfw_frank@163.com> X-CM-TRANSID: gMGowECp7kUfj_5UlpxaAA--.8896W X-CM-SenderInfo: poizswpudqyqqrwthudrp/1tbiHgy44FSIHIz+DgABs3 X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Archived-At: Cc: zuomin@chinamobile.com, qiminpeng@chinamobile.com Subject: [sipcore] SIP authentication using EC-SRP5 protocol X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 06:43:44 -0000 ------=_Part_325661_286895833.1425968927488 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 aGksIGFsbAoKV2UgaGF2ZSBqdXN0IHVwbG9hZGVkIGEgZHJhZnQgcmVnYXJkaW5nIFNJUCBhdXRo ZW50aWNhdGlvbiwgd2hpY2ggY2FuIGJlIHNlZW4gYXQgdGhlIGxpbmsKCmh0dHA6Ly93d3cuaWV0 Zi5vcmcvc3RhZ2luZy9kcmFmdC1saXUtc2lwY29yZS1lYy1zcnAtMDAudHh0CgpJdCBpcyBrbm93 biB0aGF0IFNJUCBhdXRoZW50aWNhdGlvbiBzdWZmZXJzIGZyb20gb2ZmLWxpbmUgZGljdGlvbmFy eSBhdHRhY2tzIGR1ZSB0byB0aGUgdXNlIG9mIHdlYWsgYXV0aGVudGljYXRpb24gc2NoZW1lIChI VFRQIGRpZ2VzdCBhdXRoZW50aWNhdGlvbikuIE91ciBwcm9wb3NhbCBpcyB0byBhcHBseSB0aGUg c3Ryb25nIHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSBFQy1TUlA1ICB0byBTSVAgYXV0 aGVudGljYXRpb24uIFNJUCBDbGllbnQgYW5kIHNlcnZlciBwZXJmb3JtIG11dHVhbCBhdXRoZW50 aWNhdGUgYnkgdXNpbmcgdGhlIG1vZGVybiAnemVybyBrbm93bGVkZ2UnIG1ldGhvZCB3aXRob3V0 IGRpc2Nsb3NpbmcgdGhlIHBhc3N3b3JkIGluIHRoZSBwcm9jZXNzLiBJdCBpcyByZXNpbGllbnQg dG8gdmFyaW91cyBraW5kcyBvZiBhdHRhY2tzLCBpbmNsdWRpbmcgb2ZmLWxpbmUgZGljdGlvbmFy eSBhdHRhY2tzLiBNb3Jlb3ZlciwgIGl0IGhhcyBsb3cgY29tcHV0YXRpb24gY29tcGxleGl0eSBh bmQgbG93IGJhbmR3aWR0aCBjb25zdW1wdGlvbiBkdWUgdG8gdGhlIHVzZSBvZiBlbGxpcHRpY2Fs IGN1cnZlIGNyeXB0b2dyYXBoeS4KClRoaXMgaXMgdGhlIGZpcnN0IHZlcnNpb24gb2Ygb3VyIHBy b3Bvc2FsLiBJdCBpcyB1bmF2b2lkYWJsZSB0aGF0IHRoZXJlIGFyZSBlcnJvcnMgaW4gdGhlIGRv Y3VtZW50LiAgQW55IGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgaGlnaGx5IGRlc2lyZWQu CgpCZXN0IHJlZ2FyZHMKCkRyLiBGdXdlbiBMaXUKCkNoaW5hbW9iaWxlCgo= ------=_Part_325661_286895833.1425968927488 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+aGksIGFsbDxicj48YnI+V2UgaGF2ZSBqdXN0IHVwbG9h ZGVkIGEgZHJhZnQgcmVnYXJkaW5nIFNJUCBhdXRoZW50aWNhdGlvbiwgd2hpY2ggY2FuIGJlIHNl ZW4gYXQgdGhlIGxpbms8YnI+PGJyPjxhIF9zcmM9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvc3RhZ2lu Zy9kcmFmdC1saXUtc2lwY29yZS1lYy1zcnAtMDAudHh0IiBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL3N0YWdpbmcvZHJhZnQtbGl1LXNpcGNvcmUtZWMtc3JwLTAwLnR4dCI+aHR0cDovL3d3dy5p ZXRmLm9yZy9zdGFnaW5nL2RyYWZ0LWxpdS1zaXBjb3JlLWVjLXNycC0wMC50eHQ8L2E+PGJyPjxi cj5JdCBpcyBrbm93biB0aGF0IFNJUCBhdXRoZW50aWNhdGlvbiBzdWZmZXJzIGZyb20gb2ZmLWxp bmUgZGljdGlvbmFyeSBhdHRhY2tzIGR1ZSB0byB0aGUgdXNlIG9mIHdlYWsgYXV0aGVudGljYXRp b24gc2NoZW1lIChIVFRQIGRpZ2VzdCBhdXRoZW50aWNhdGlvbikuIE91ciBwcm9wb3NhbCBpcyB0 byBhcHBseSB0aGUgc3Ryb25nIHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSBFQy1TUlA1 Jm5ic3A7IHRvIFNJUCBhdXRoZW50aWNhdGlvbi4gU0lQIENsaWVudCBhbmQKICAgc2VydmVyIHBl cmZvcm0gbXV0dWFsIGF1dGhlbnRpY2F0ZSBieSB1c2luZyB0aGUgbW9kZXJuICd6ZXJvCiAgIGtu b3dsZWRnZScgbWV0aG9kIHdpdGhvdXQgZGlzY2xvc2luZyB0aGUgcGFzc3dvcmQgaW4gdGhlIHBy b2Nlc3MuIEl0IGlzIHJlc2lsaWVudCB0bwogICB2YXJpb3VzIGtpbmRzIG9mIGF0dGFja3MsIGlu Y2x1ZGluZyBvZmYtbGluZSBkaWN0aW9uYXJ5IGF0dGFja3MuIE1vcmVvdmVyLCZuYnNwOyBpdAog ICBoYXMgbG93IGNvbXB1dGF0aW9uIGNvbXBsZXhpdHkgYW5kIGxvdyBiYW5kd2lkdGggY29uc3Vt cHRpb24gZHVlIHRvCiAgIHRoZSB1c2Ugb2YgZWxsaXB0aWNhbCBjdXJ2ZSBjcnlwdG9ncmFwaHku PGJyPjxicj5UaGlzIGlzIHRoZSBmaXJzdCB2ZXJzaW9uIG9mIG91ciBwcm9wb3NhbC4gSXQgaXMg dW5hdm9pZGFibGUgdGhhdCB0aGVyZSBhcmUgZXJyb3JzIGluIHRoZSBkb2N1bWVudC4mbmJzcDsg QW55IGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgaGlnaGx5IGRlc2lyZWQuIDxicj48YnI+ QmVzdCByZWdhcmRzPGJyPjxicj5Eci4gRnV3ZW4gTGl1PGJyPjxicj5DaGluYW1vYmlsZSA8YnI+ PGJyPjxwcmU+IDwvcHJlPiA8L2Rpdj48L2Rpdj48YnI+PGJyPjxzcGFuIHRpdGxlPSJuZXRlYXNl Zm9vdGVyIj48c3BhbiBpZD0ibmV0ZWFzZV9tYWlsX2Zvb3RlciI+PC9zcGFuPjwvc3Bhbj4= ------=_Part_325661_286895833.1425968927488-- From nobody Tue Mar 10 01:20:05 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8691B2A2E for ; Tue, 10 Mar 2015 01:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXxraqCRNomw for ; Tue, 10 Mar 2015 01:20:01 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155C21B2A2B for ; Tue, 10 Mar 2015 01:20:00 -0700 (PDT) X-AuditID: c1b4fb2d-f79aa6d00000359d-37-54fea92e6931 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 28.E5.13725.E29AEF45; Tue, 10 Mar 2015 09:19:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0210.002; Tue, 10 Mar 2015 09:19:58 +0100 From: Christer Holmberg To: "Stach, Thomas" , "sipcore@ietf.org" Thread-Topic: Content-Disposition questions Thread-Index: AdBaY9SoDDjiuJSCSNy+9rzo9dcbwwAG+ntAACLKJ7A= Date: Tue, 10 Mar 2015 08:19:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D7335FB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D73005D@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvja7+yn8hBj+bWC2+/tjEZnFy5zZm ByaPJUt+Mnls73nMEsAUxWWTkpqTWZZapG+XwJVx/fN69oKLQhUHu16wNTCu5u9i5OSQEDCR 2HXtGjOELSZx4d56ti5GLg4hgSOMEodftbJCOEsYJVYs/MHYxcjBwSZgIdH9TxvEFBEIlXi6 XRqkV1hAS2LKz+9gc0QEtCVu75sLZVtJ7P6/kRHEZhFQlfi1qpEFxOYV8JU40buBGWL8JEaJ J0t+soIkOAX8Je7M6GUCsRmBDvp+ag2YzSwgLnHryXwmiEMFJJbsOQ91tKjEy8f/WCFsJYlF tz9D1etJ3Jg6hQ3C1pZYtvA1M8RiQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo2hxanFx brqRsV5qUWZycXF+nl5easkmRmCcHNzyW3cH4+rXjocYBTgYlXh4DeL+hQixJpYVV+YeYpTm YFES57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdFZeMHmQ9uNL67wmfuKb26C2fVr V3//uVOoe2XDGQ3Dg92xwf4+Zw4a/WYPm8L3pqEv6GysoOqa7+VGU+vOOItyiWfIvrGN5tm2 +2pLwOIKixcpO5VPqh+8vMyyoCKkkyOyXc4xaK8Rm6hbLPve8OaNqSYlu9uYFyU81Wxj2Mca 1jJ96foaMSWW4oxEQy3mouJEAHCFsL10AgAA Archived-At: Subject: Re: [sipcore] Content-Disposition questions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 08:20:03 -0000 Hi Thomas, My issue is not so much related to specific usages of the handling paramete= r - but what the default value is when not present in the message. Regards, Christer -----Original Message----- From: Stach, Thomas [mailto:thomas.stach@unify.com]=20 Sent: 09 March 2015 17:54 To: Christer Holmberg; sipcore@ietf.org Subject: RE: Content-Disposition questions Christer, I don't know if that helps with your question, but if you tunnel QSIG over = SIP it would most likely done using ECMA-355 or the ISO's equivalent IS 225= 35 Here, the handling parameter would be set to "required". - http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-355.pdf - http://standards.iso.org/ittf/PubliclyAvailableStandards/c052060_ISO_IEC_= 22535_2009(E).zip =20 Regards Thomas From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: Montag, 9. M=E4rz 2015 13:26 To: sipcore@ietf.org Subject: [sipcore] Content-Disposition questions Hi, Section 20.11 of RFC 3261 says: =A0=A0=A0=A0=A0=A0=A0 "For backward-compatibility, if the Content-Dispositi= on header field =A0=A0 =A0=A0=A0=A0 is missing, the server SHOULD assume bodies of Content-= Type =A0=A0 =A0=A0=A0=A0 application/sdp are the disposition "session", while ot= her content =A0=A0 =A0=A0=A0=A0 types are "render"." Section 20.11 also says: =A0=A0=A0=A0=A0=A0=A0 "The handling parameter, handling-param, describes ho= w the UAS should =A0=A0 =A0=A0=A0=A0 react if it receives a message body whose content type = or disposition =A0=A0 =A0=A0=A0=A0 type it does not understand. The parameter has defined = values of =A0=A0 =A0=A0=A0=A0 "optional" and "required". If the handling parameter is= missing, the =A0=A0 =A0=A0=A0=A0 value "required" SHOULD be assumed. The handling parame= ter is =A0=A0 =A0=A0=A0=A0 described in RFC 3204 [19]. QUESTION_1: If the C-D header field is missing, and the default disposition= type value ("render") is assumed, shall then the default handling value ("= required") also be assumed? RFC 3204, which RFC 3261 refers to, says that the default disposition type = value for ISUP and QSIG bodies are "signal". QUESTION_2: If, for a specific message body, the "render" default type can = be overwritten, shouldn't that be mentioned in 3261? Regards, Christer From nobody Tue Mar 10 01:28:23 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69AD1ACE0E for ; Tue, 10 Mar 2015 01:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1_nUqt_0xnk for ; Tue, 10 Mar 2015 01:28:19 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54781A90AE for ; Tue, 10 Mar 2015 01:28:18 -0700 (PDT) X-AuditID: c1b4fb30-f79c86d000000fc0-f0-54feab20cc3d Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 85.49.04032.02BAEF45; Tue, 10 Mar 2015 09:28:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0210.002; Tue, 10 Mar 2015 09:28:16 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Content-Disposition questions Thread-Index: AdBaY9SoDDjiuJSCSNy+9rzo9dcbwwABFg+AACi2+gA= Date: Tue, 10 Mar 2015 08:28:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D733675@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D73005D@ESESSMB209.ericsson.se> <54FDA613.8000800@alum.mit.edu> In-Reply-To: <54FDA613.8000800@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvja7i6n8hBj92MFms2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAldGc+8H1oITYhULNj5lbmDcJ9jFyMkhIWAi sfXmDhYIW0ziwr31bF2MXBxCAkcYJQ4d3sAK4SxhlLjdeoGpi5GDg03AQqL7nzZIg4hAoMTV JROYQWxhoEHrPvxmASkRETCV2LcsDqLESuLRwudMIDaLgKrEpWXf2UFsXgFfiTlrp4HFhQTy JZ4t3skGYnMK6EjsWvcFbCQj0D3fT60Bq2EWEJe49WQ+E8SdAhJL9pxnhrBFJV4+/scKYStJ LLr9GapeR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxhFi1OL k3LTjYz0Uosyk4uL8/P08lJLNjECo+Tglt8GOxhfPnc8xCjAwajEw2sQ9y9EiDWxrLgy9xCj NAeLkjivnfGhECGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M7oH7Si/GhnrLCM924pPL0Ny5 YyZ/VP06kbNNc2s7F9cdvrr2RkLEc31Fth9LLEyazq54vmCLquuuuPi9047tlHMTOSR8o+V4 wbdZacLpRozhi5IWbGjo65RZv016b4rp3R/ave9MTfw3NOzYYJ8Xs/Gt+cPHstxmPxUX1LjU njM9XZTmYZCgxFKckWioxVxUnAgAob67pnMCAAA= Archived-At: Subject: Re: [sipcore] Content-Disposition questions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 08:28:21 -0000 Hi, >> Section 20.11 of RFC 3261 says: >> >> "For backward-compatibility, if the Content-Disposition=20 >> header field is missing, the server SHOULD assume bodies of Con= tent-Type >> application/sdp are the disposition "session", while other cont= ent >> types are "render"." >> >> Section 20.11 also says: >> >> "The handling parameter, handling-param, describes how the=20 >> UAS should react if it receives a message body whose content typ= e or=20 >> disposition type it does not understand. The parameter has defin= ed values=20 >> of "optional" and "required". If the handling parameter is missi= ng, the >> value "required" SHOULD be assumed. The handling parameter is >> described in RFC 3204 [19]. >> >> *QUESTION_1*: If the C-D header field is missing, and the default dispos= ition=20 >> type value ("render") is assumed, shall then the default handling value = ("required") also be assumed? > > My personal opinion is that yes "required" is what it *should* be. > > It is less clear whether an implementation that treats it as "optional" c= an be accused of being non-compliant. I don't think there should be a "should" - either there is a default value,= or there isn't. Then, if you want to allow different processing when "require" is used, tha= t is a separate issue. But, that does not depend on whether "require" is in= dicated implicitly or explicitly. For example, if you receive a body with C-D type "render" and "handling=3Dr= equired", are you still allowed to process the request even if you aren't a= ble to handle the body? >> RFC 3204, which RFC 3261 refers to, says that the default disposition ty= pe value for ISUP and QSIG bodies are "signal". >> >> *QUESTION_2*: If, for a specific message body, the "render" default type= can be=20 >> overwritten, shouldn't that be >> mentioned in 3261? > > Yes. It is quite evident that 3261 didn't give enough thought to Content-= Disposition. > > You didn't mention RFC5621. It has a section on C-D and it updates 3261. > But it doesn't totally address the issues you mention here. I did have a look, but unless I missed something the focus seems to be most= ly related to multipart bodies. > IMO it would be reasonable to file an erratum on this. I don't know that = it needs another 3261 update at this time. My suggestion for such erratum would be: 1. Define that, if no C-D header field is present, "require" is the default= handling value. 2. Define that, for specific message bodies, the default type value can be = overwritten. BUT, in such cases, do we need to mandate "require" handling? = Otherwise an entity that does not understand ISUP could treat it as "render= ", which is not the=20 expected behaviour. Regards, Christer From nobody Tue Mar 10 02:45:56 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E661A8742 for ; Tue, 10 Mar 2015 02:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1cNkCyJjZ-M for ; Tue, 10 Mar 2015 02:45:52 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9389C1A8730 for ; Tue, 10 Mar 2015 02:45:52 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id B77E423F0448; Tue, 10 Mar 2015 10:45:51 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.173]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0224.002; Tue, 10 Mar 2015 10:45:51 +0100 From: "Stach, Thomas" To: Christer Holmberg , "sipcore@ietf.org" Thread-Topic: Content-Disposition questions Thread-Index: AdBaY9SoDDjiuJSCSNy+9rzo9dcbwwAG+ntAACLKJ7AAAKAUgA== Date: Tue, 10 Mar 2015 09:45:50 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D73005D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7335FB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7335FB@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Content-Disposition questions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 09:45:54 -0000 Christer, >=20 > Hi Thomas, >=20 > My issue is not so much related to specific usages of the handling parame= ter - Understood.=20 More inline > but what the default value is when not present in the message. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Stach, Thomas [mailto:thomas.stach@unify.com] > Sent: 09 March 2015 17:54 > To: Christer Holmberg; sipcore@ietf.org > Subject: RE: Content-Disposition questions >=20 > Christer, >=20 > I don't know if that helps with your question, but if you tunnel QSIG ove= r SIP > it would most likely done using ECMA-355 or the ISO's equivalent IS 22535 >=20 > Here, the handling parameter would be set to "required". >=20 > - http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-355.p= df > - > http://standards.iso.org/ittf/PubliclyAvailableStandards/c052060_ISO_IEC_= 22535 > _2009(E).zip >=20 >=20 > Regards > Thomas >=20 > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Hol= mberg > Sent: Montag, 9. M=E4rz 2015 13:26 > To: sipcore@ietf.org > Subject: [sipcore] Content-Disposition questions >=20 > Hi, >=20 > Section 20.11 of RFC 3261 says: >=20 > =A0=A0=A0=A0=A0=A0=A0 "For backward-compatibility, if the Content-Disposi= tion header field > =A0=A0 =A0=A0=A0=A0 is missing, the server SHOULD assume bodies of Conten= t-Type > =A0=A0 =A0=A0=A0=A0 application/sdp are the disposition "session", while = other content > =A0=A0 =A0=A0=A0=A0 types are "render"." >=20 > Section 20.11 also says: >=20 > =A0=A0=A0=A0=A0=A0=A0 "The handling parameter, handling-param, describes = how the UAS should > =A0=A0 =A0=A0=A0=A0 react if it receives a message body whose content typ= e or disposition > =A0=A0 =A0=A0=A0=A0 type it does not understand. The parameter has define= d values of > =A0=A0 =A0=A0=A0=A0 "optional" and "required". If the handling parameter = is missing, the > =A0=A0 =A0=A0=A0=A0 value "required" SHOULD be assumed. The handling para= meter is > =A0=A0 =A0=A0=A0=A0 described in RFC 3204 [19]. >=20 >=20 > QUESTION_1: If the C-D header field is missing, and the default dispositi= on > type value ("render") is assumed, shall then the default handling value > ("required") also be assumed? Yes, for unknown message bodies with the following exception. Since RFC3204 is a normative reference, "qsig" and "isup" are not "unknown"= and=20 treated as specified there,=20 i.e. Content-Disposition: signal; handling=3Doptional >=20 >=20 >=20 > RFC 3204, which RFC 3261 refers to, says that the default disposition typ= e > value for ISUP and QSIG bodies are "signal". >=20 > QUESTION_2: If, for a specific message body, the "render" default type ca= n be > overwritten, shouldn't that be mentioned in 3261? I think this is already written down. The last sentence in section 20.11 re= ads " If this header field is missing, the MIME type determines the default content disposition. If there is none, "render" is assumed." So, if the MIME type is understood, the default disposition from the=20 corresponding MIME definition applies. Of course, this default disposition= =20 can be overwritten by sending a corresponding C-D header field, as e.g. ECM= A-355 does for "qsig". "render" kicks in, only if the MIME type is not understood and if C-D is om= itted. Does this make sense? Regards Thomas >=20 >=20 > Regards, >=20 > Christer From nobody Tue Mar 10 07:51:10 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AA71A893B for ; Tue, 10 Mar 2015 07:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iclxw2bPXT-N for ; Tue, 10 Mar 2015 07:51:08 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06301A8930 for ; Tue, 10 Mar 2015 07:51:06 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-08v.sys.comcast.net with comcast id 1qpL1q0022EPM3101qr6HF; Tue, 10 Mar 2015 14:51:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-07v.sys.comcast.net with comcast id 1qr51q00S3Ge9ey01qr5dW; Tue, 10 Mar 2015 14:51:05 +0000 Message-ID: <54FF04D9.7020609@alum.mit.edu> Date: Tue, 10 Mar 2015 10:51:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D73005D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7335FB@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1425999066; bh=4PMglSaC0CkkOJ55EHRQcuFx0MsKdsmKm6NIc4bLDsI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=s4BP5JDpZCxcJMW0+/bdejy3xHYg6o/e074hPNUTJKW+6smdvg/RAlav01Ydt5eNj BSh0ejLse4pYJIYlwH2q3wI4O84lr56TzcLySLp7DFrcQGofANS995N7tl1aT0Lp+R OtM8VmXxTWIYR4YjbQoyz6JK22jOaJ4gsU2rgdQTXcWL+rqpUSZ04HC/IiqTNQYspM gTgxZ58Q/RgmFvRDx+RmRD+EF2n08SWc3YbHTT4WLcDXQSOhvoD1E3GwUS2bxABc04 t2duS1uovtj4vA+wXR/5wpkHgW+7sMsl8aYZgRTqtYenuak/XxLvk73eIYNjgGidEU 8qA1mvUOZcEMg== Archived-At: Subject: Re: [sipcore] Content-Disposition questions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 14:51:09 -0000 On 3/10/15 5:45 AM, Stach, Thomas wrote: >> QUESTION_2: If, for a specific message body, the "render" default type can be >> overwritten, shouldn't that be mentioned in 3261? > > I think this is already written down. The last sentence in section 20.11 reads > " If this header field is missing, the MIME type determines the default > content disposition. If there is none, "render" is assumed." > > So, if the MIME type is understood, the default disposition from the > corresponding MIME definition applies. Of course, this default disposition > can be overwritten by sending a corresponding C-D header field, as e.g. ECMA-355 does for "qsig". > "render" kicks in, only if the MIME type is not understood and if C-D is omitted. > Does this make sense? That has a problem. It makes no sense to define a default handling parameter value for a specific mime type that applies when the C-D isn't present. Suppose you define a mime type where the default handling is "optional". Then a receiver that does understand the mime type will treat the handling as optional, but that is irrelevant because this only applies if the mime type is not understood. A receiver that does not understand the mime type will use the global default handling value "required". Thanks, Paul From nobody Tue Mar 10 08:10:42 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3A11A00E8 for ; Tue, 10 Mar 2015 08:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwmfLyooTXex for ; Tue, 10 Mar 2015 08:10:26 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1191A0016 for ; Tue, 10 Mar 2015 08:10:20 -0700 (PDT) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-04v.sys.comcast.net with comcast id 1rAA1q0064xDoy801rALEj; Tue, 10 Mar 2015 15:10:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-05v.sys.comcast.net with comcast id 1rAK1q00a3Ge9ey01rALAt; Tue, 10 Mar 2015 15:10:20 +0000 Message-ID: <54FF095B.7040805@alum.mit.edu> Date: Tue, 10 Mar 2015 11:10:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <267098f4.14b60.14c025f1300.Coremail.lfw_frank@163.com> In-Reply-To: <267098f4.14b60.14c025f1300.Coremail.lfw_frank@163.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1426000220; bh=NMfW73P9tT69pf+10buOSYT2hKm8A5rerLHbf3wniSI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Mb4jBfzq6FXB0F2WPKcICNCCz0okvH8/yG41CJBpjFp+dEiMPj6G/cIqXzYfngcId 5ifG26HJ9RYV+zoWpTK6Sn9AFikpQutbyarzpNaK5K62IdlGWAZ5/obA1BP3iWtAjY ixhc0KafvMkIxEOjaQ6xX0KUIIlWHgEFF9YrlDSzqZlKuWEqG4qF++Y3zHjzNc+2WS k4cRsYw29AYotyhqLp8mJrQukPXlocwGeN+IfOksf+RBxzWSk6NlkJrUesZV6mn61w vVCXOO3uFDRH3o++ZPw/OgrLJlQu8IXI2XyqnFqVCnliw3/Xz3E/MNFhW/O5ZdiMRt xnwDtTV7BuigQ== Archived-At: Subject: Re: [sipcore] SIP authentication using EC-SRP5 protocol X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 15:10:28 -0000 Dr. Liu, I just now quickly reviewed your draft. Let me first say that I am *not* expert in security and encryption. Since that is the primary focus of this draft I will be looking for comments from experts on that. I did not see any mention of how you propose to integrate this approach into SIP. Is it your intent to reuse the Authorization and Authentication-Info header fields? Or do you intend to introduce some other mechanism to exchange the information you use? Thanks, Paul On 3/10/15 2:28 AM, lfw_frank wrote: > hi, all > > We have just uploaded a draft regarding SIP authentication, which can be > seen at the link > > http://www.ietf.org/staging/draft-liu-sipcore-ec-srp-00.txt > > It is known that SIP authentication suffers from off-line dictionary > attacks due to the use of weak authentication scheme (HTTP digest > authentication). Our proposal is to apply the strong password > authentication scheme EC-SRP5 to SIP authentication. SIP Client and > server perform mutual authenticate by using the modern 'zero knowledge' > method without disclosing the password in the process. It is resilient > to various kinds of attacks, including off-line dictionary attacks. > Moreover, it has low computation complexity and low bandwidth > consumption due to the use of elliptical curve cryptography. > > This is the first version of our proposal. It is unavoidable that there > are errors in the document. Any comments and suggestions are highly > desired. > > Best regards > > Dr. Fuwen Liu > > Chinamobile > > > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Mar 10 08:27:21 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3881A008A for ; Tue, 10 Mar 2015 08:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoSfaP4KZoh4 for ; Tue, 10 Mar 2015 08:27:17 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E79A1A0016 for ; Tue, 10 Mar 2015 08:27:16 -0700 (PDT) X-AuditID: c1b4fb30-f79c86d000000fc0-15-54ff0d52deae Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 04.03.04032.25D0FF45; Tue, 10 Mar 2015 16:27:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0210.002; Tue, 10 Mar 2015 16:27:14 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Content-Disposition questions Thread-Index: AdBaY9SoDDjiuJSCSNy+9rzo9dcbwwAG+ntAACLKJ7AAAKAUgAAK9kqAAANbhKQ= Date: Tue, 10 Mar 2015 15:27:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D7342B7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D73005D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7335FB@ESESSMB209.ericsson.se> , <54FF04D9.7020609@alum.mit.edu> In-Reply-To: <54FF04D9.7020609@alum.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D7342B7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjW4Q7/8Qgx37ZS1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj3benTAWPDCsOPjvF1MA4X6uLkZNDQsBE 4sjxhewQtpjEhXvr2boYuTiEBI4wSlw40cAM4SxhlHh7aw9jFyMHB5uAhUT3P22QBhGBQImr SyYwg9jCQIPWffjNAlIiImAqsW9ZHESJn8SyN69YQGwWAVWJbTsugZXzCvhKLHpyiBFi/G4m ie9LHzKBJDgFdCSWb/rEBmIzAh30/dQasDizgLhE05eVrBCHCkgs2XOeGcIWlXj5+B8rRE2+ xITHN5ggFghKnJz5hGUCo/AsJO2zkJTNQlIGETeQ+PL+NpStLbFs4WtmCFtfovv9aSZk8QWM 7KsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAuPn4JbfBjsYXz53PMQowMGoxMNrEPcvRIg1 say4MvcQozQHi5I4r53xoRAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjE5sX4Re6R1UZ3M4 Vj6nPmyZU5BW1Y87iRFtPyukrR3fTOE+cCTW5vFapWu1NWIfr8zksQ+wcDeqmcC2+N/+QP1d M5RE5hXwbpFw7JCw5nX8prGnzuFLbJ3L6XftOrPCFk4QN+GaouXprDcndq2Gew+L0ifXTQpb cldFTA+V/HTnDmPivPt8SizFGYmGWsxFxYkAqDtQaIACAAA= Archived-At: Subject: Re: [sipcore] Content-Disposition questions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 15:27:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D7342B7ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Paul, It is not the default handling value that is different for the qsig/isup bo= dies - it is the default type value ("signal", rather than "render"). I am not sure I agree with Thomas that a SIP client must support the qsig/i= sup bodies. Yes, 3261 does reference the CR, but mostly for information reg= arding the C-D header field itself. Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD10/=FD03/=FD2015 16:58 To: sipcore@ietf.org Subject: Re: [sipcore] Content-Disposition questions On 3/10/15 5:45 AM, Stach, Thomas wrote: >> QUESTION_2: If, for a specific message body, the "render" default type c= an be >> overwritten, shouldn't that be mentioned in 3261? > > I think this is already written down. The last sentence in section 20.11 = reads > " If this header field is missing, the MIME type determines the default > content disposition. If there is none, "render" is assumed." > > So, if the MIME type is understood, the default disposition from the > corresponding MIME definition applies. Of course, this default dispositio= n > can be overwritten by sending a corresponding C-D header field, as e.g. E= CMA-355 does for "qsig". > "render" kicks in, only if the MIME type is not understood and if C-D is = omitted. > Does this make sense? That has a problem. It makes no sense to define a default handling parameter value for a specific mime type that applies when the C-D isn't present. Suppose you define a mime type where the default handling is "optional". Then a receiver that does understand the mime type will treat the handling as optional, but that is irrelevant because this only applies if the mime type is not understood. A receiver that does not understand the mime type will use the global default handling value "required". Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B1D7342B7ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Paul,

It is not the default handling value that is different for the qsig/isup bo= dies - it is the default type value ("signal", rather than "= render").

I am not sure I agree with Thomas that a SIP client must support the qsig/i= sup bodies. Yes, 3261 does reference the CR, but mostly for information reg= arding the C-D header field itself.

Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD10= /=FD03/=FD2015 16:58
To: sipcore@ietf.org
Subject: Re: [= sipcore] Content-Disposition questions

On 3/10/15 5:45 AM, Stach, Thomas wrote:

>> QUESTION_2: If, for a specific message body, the "render"= ; default type can be
>> overwritten, shouldn't that be mentioned in 3261?
>
> I think this is already written down. The last sentence in section 20.= 11 reads
> "   If this header field is missing, the MIME type dete= rmines the default
>     content disposition.  If there is none, &= quot;render" is assumed."
>
> So, if the MIME type is understood, the default disposition from the > corresponding MIME definition applies. Of course, this default disposi= tion
> can be overwritten by sending a corresponding C-D header field, as e.g= . ECMA-355 does for "qsig".
> "render" kicks in, only if the MIME type is not understood a= nd if C-D is omitted.
> Does this make sense?

That has a problem. It makes no sense to define a default handling
parameter value for a specific mime type that applies when the C-D isn't present. Suppose you define a mime type where the default handling is
"optional".

Then a receiver that does understand the mime type will treat the
handling as optional, but that is irrelevant because this only applies
if the mime type is not understood.

A receiver that does not understand the mime type will use the global
default handling value "required".

        Thanks,
        Paul



_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore
 --_000_7594FB04B1934943A5C02806D1A2204B1D7342B7ESESSMB209erics_-- From nobody Tue Mar 10 09:04:09 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE451A1B0B for ; Tue, 10 Mar 2015 09:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhrNj0Zx_wSO for ; Tue, 10 Mar 2015 09:04:06 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6817C1A1AFC for ; Tue, 10 Mar 2015 09:04:06 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-06v.sys.comcast.net with comcast id 1s2r1q0052Bo0NV01s454f; Tue, 10 Mar 2015 16:04:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-05v.sys.comcast.net with comcast id 1s451q0083Ge9ey01s4515; Tue, 10 Mar 2015 16:04:05 +0000 Message-ID: <54FF15F4.9040006@alum.mit.edu> Date: Tue, 10 Mar 2015 12:04:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Christer Holmberg , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D73005D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7335FB@ESESSMB209.ericsson.se> , <54FF04D9.7020609@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D7342B7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7342B7@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1426003445; bh=e9ApSiZR1acvEXoI/GbjpZ0TD5Qx0AipcpqyoqCPitE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=D9yuXurg+CFbD/oB3SNnYRS1af0YQ0PCheJNucaE63jku+j4qiZKJWUxOrQIKzvUr kGkqW7lSkbsDsESfyvG3GJKkBQQgfzJqkosaVqQwU/NGiDRHuBVXRn5xC+06AyVdci 7huR9H/XqJ0pA1WsDag+SuhOWyUVWXSGBXfLfiJBbbrGxrbJU20785iHNM2lwwiVAg uVEU3pch4BwcQgl37GbheusRgXfitgaUOZhdzdnLgyWa+xLMlk3MwFSur3jedgbhBO K4kUewf8DG2lp0sMfhHcH16l/6p2qE7BQ2WM3RBeGcbnVCXniUap4ngTfLVK78SxaN wZdapPkpnqAjQ== Archived-At: Subject: Re: [sipcore] Content-Disposition questions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 16:04:08 -0000 On 3/10/15 11:27 AM, Christer Holmberg wrote: > Hi Paul, > > It is not the default handling value that is different for the qsig/isup > bodies - it is the default type value ("signal", rather than "render"). I know they define the default disposition type for those mime types. But I thought Thomas was also saying that they change the default handling to "optional", and I was commenting on the relevance of that part. If you include a qsig mime body, and don't include a C-D with handling="optional" then a recipient that doesn't know the mime type should treat it as "required" and reject the request, regardless of what defaults are defined for that mime type. > I am not sure I agree with Thomas that a SIP client must support the > qsig/isup bodies. Yes, 3261 does reference the CR, but mostly for > information regarding the C-D header field itself. I agree with you. Classifying a reference as normative doesn't mean that every aspect of that draft is required. And the only body reference in 3261 is wrt the definition of the handling parameter. And 3204 goes out of its way to say: The Content-Disposition header [5] may be included to describe how the encapsulated ISUP is to be processed, and in particular what the handling should be if the received Content-Type is not recognized. That would make no sense if all SIP UA were required to recognize ISUP. Thanks, Paul > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Paul Kyzivat > Sent: ý10/ý03/ý2015 16:58 > To: sipcore@ietf.org > Subject: Re: [sipcore] Content-Disposition questions > > On 3/10/15 5:45 AM, Stach, Thomas wrote: > >>> QUESTION_2: If, for a specific message body, the "render" default type can be >>> overwritten, shouldn't that be mentioned in 3261? >> >> I think this is already written down. The last sentence in section 20.11 reads >> " If this header field is missing, the MIME type determines the default >> content disposition. If there is none, "render" is assumed." >> >> So, if the MIME type is understood, the default disposition from the >> corresponding MIME definition applies. Of course, this default disposition >> can be overwritten by sending a corresponding C-D header field, as e.g. ECMA-355 does for "qsig". >> "render" kicks in, only if the MIME type is not understood and if C-D is omitted. >> Does this make sense? > > That has a problem. It makes no sense to define a default handling > parameter value for a specific mime type that applies when the C-D isn't > present. Suppose you define a mime type where the default handling is > "optional". > > Then a receiver that does understand the mime type will treat the > handling as optional, but that is irrelevant because this only applies > if the mime type is not understood. > > A receiver that does not understand the mime type will use the global > default handling value "required". > > Thanks, > Paul > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Mar 10 09:48:12 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA201A00E4 for ; Tue, 10 Mar 2015 09:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5Z3xSVR2GAX for ; Tue, 10 Mar 2015 09:48:10 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id AC20A1A00D6 for ; Tue, 10 Mar 2015 09:48:09 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 2BA6523F04D7; Tue, 10 Mar 2015 17:48:08 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.173]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0224.002; Tue, 10 Mar 2015 17:48:07 +0100 From: "Stach, Thomas" To: Paul Kyzivat , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] Content-Disposition questions Thread-Index: AdBaY9SoDDjiuJSCSNy+9rzo9dcbwwAG+ntAACLKJ7AAAKAUgAAPnNEZAAChmLA= Date: Tue, 10 Mar 2015 16:48:07 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D73005D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7335FB@ESESSMB209.ericsson.se> , <54FF04D9.7020609@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D7342B7@ESESSMB209.ericsson.se> <54FF15F4.9040006@alum.mit.edu> In-Reply-To: <54FF15F4.9040006@alum.mit.edu> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Content-Disposition questions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 16:48:11 -0000 UGF1bCwgQ2hyaXN0ZXIsDQoNCmFsbCBvZiB0aGlzIGlzIGp1c3QgYSBjb3JuZXIgY2FzZSwgaW5j bHVkaW5nIEMtRCB3aXRoIGhhbmRsaW5nPW9wdGlvbmFsIA0Kd291bGQgYXZvaWQgYW55IGNvbmZ1 c2lvbiwgYnV0IC4uLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNp cGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVs IEt5eml2YXQNCj4gU2VudDogRGllbnN0YWcsIDEwLiBNw6RyeiAyMDE1IDE3OjA0DQo+IFRvOiBD aHJpc3RlciBIb2xtYmVyZzsgc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcGNv cmVdIENvbnRlbnQtRGlzcG9zaXRpb24gcXVlc3Rpb25zDQo+IA0KPiBPbiAzLzEwLzE1IDExOjI3 IEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4gPiBIaSBQYXVsLA0KPiA+DQo+ID4gSXQg aXMgbm90IHRoZSBkZWZhdWx0IGhhbmRsaW5nIHZhbHVlIHRoYXQgaXMgZGlmZmVyZW50IGZvciB0 aGUgcXNpZy9pc3VwDQo+ID4gYm9kaWVzIC0gaXQgaXMgdGhlIGRlZmF1bHQgdHlwZSB2YWx1ZSAo InNpZ25hbCIsIHJhdGhlciB0aGFuICJyZW5kZXIiKS4NCk5vLCBteSBwb2ludCB3YXMgYWJvdXQg dGhlIGRpZmZlcmVudCBoYW5kbGluZy4NCg0KPiANCj4gSSBrbm93IHRoZXkgZGVmaW5lIHRoZSBk ZWZhdWx0IGRpc3Bvc2l0aW9uIHR5cGUgZm9yIHRob3NlIG1pbWUgdHlwZXMuDQo+IEJ1dCBJIHRo b3VnaHQgVGhvbWFzIHdhcyBhbHNvIHNheWluZyB0aGF0IHRoZXkgY2hhbmdlIHRoZSBkZWZhdWx0 DQo+IGhhbmRsaW5nIHRvICJvcHRpb25hbCIsIGFuZCBJIHdhcyBjb21tZW50aW5nIG9uIHRoZSBy ZWxldmFuY2Ugb2YgdGhhdA0KPiBwYXJ0LiBJZiB5b3UgaW5jbHVkZSBhIHFzaWcgbWltZSBib2R5 LCBhbmQgZG9uJ3QgaW5jbHVkZSBhIEMtRCB3aXRoDQo+IGhhbmRsaW5nPSJvcHRpb25hbCIgdGhl biBhIHJlY2lwaWVudCB0aGF0IGRvZXNuJ3Qga25vdyB0aGUgbWltZSB0eXBlDQo+IHNob3VsZCB0 cmVhdCBpdCBhcyAicmVxdWlyZWQiIGFuZCByZWplY3QgdGhlIHJlcXVlc3QsIHJlZ2FyZGxlc3Mg b2Ygd2hhdA0KPiBkZWZhdWx0cyBhcmUgZGVmaW5lZCBmb3IgdGhhdCBtaW1lIHR5cGUuDQpDb3Jy ZWN0LCANCklmIHRoZSBVQVMgZG9lc24ndCBrbm93IGFib3V0IHRoZSBkaWZmZXJlbnQgZGVmYXVs dCBoYW5kbGluZyBmcm9tIFJGQzMyMDQsIA0KaXQgcmVqZWN0cyB0aGUgcmVxdWVzdC4NCg0KPiAN Cj4gPiBJIGFtIG5vdCBzdXJlIEkgYWdyZWUgd2l0aCBUaG9tYXMgdGhhdCBhIFNJUCBjbGllbnQg bXVzdCBzdXBwb3J0IHRoZQ0KPiA+IHFzaWcvaXN1cCBib2RpZXMuIA0KVGhhdCdzIG5vdCB3aGF0 IEkgbWVhbnQuIFN1cHBvcnQgZm9yIHFzaWcvaXN1cCBpcyBub3QgbmVlZGVkLg0KSG93ZXZlciwg aWYgdGhlIFVBUyBpbXBsZW1lbnRlZCBhbiBleGNlcHRpb24gZm9yIHRoZSBfaGFuZGxpbmdfIA0K b2YgdGhlc2UgMiBib2RpZXMgKGkuZS4gb3B0aW9uYWwpLCBpdCB3b3VsZCBqdXN0IGhhdmUgdG8g DQpyZWNvZ25pemUgYXBwbGljYXRpb24vcXNpZywgY291bGQgaWdub3JlIHRoZSBib2RpZXMgYW5k IA0Kd291bGQgbm90IGhhdmUgdG8gcmVqZWN0IGFuIElOVklURSB3aXRoIGEgNDE1Lg0KQXMgc2Fp ZCBhYm92ZSwgaXQgaXMganVzdCBhIGNvcm5lciBjYXNlLg0KDQo+IFllcywgMzI2MSBkb2VzIHJl ZmVyZW5jZSB0aGUgQ1IsIGJ1dCBtb3N0bHkgZm9yDQo+ID4gaW5mb3JtYXRpb24gcmVnYXJkaW5n IHRoZSBDLUQgaGVhZGVyIGZpZWxkIGl0c2VsZi4NCj4gDQo+IEkgYWdyZWUgd2l0aCB5b3UuIENs YXNzaWZ5aW5nIGEgcmVmZXJlbmNlIGFzIG5vcm1hdGl2ZSBkb2Vzbid0IG1lYW4gdGhhdA0KPiBl dmVyeSBhc3BlY3Qgb2YgdGhhdCBkcmFmdCBpcyByZXF1aXJlZC4gDQpBZ3JlZQ0KDQo+IEFuZCB0 aGUgb25seSBib2R5IHJlZmVyZW5jZSBpbg0KPiAzMjYxIGlzIHdydCB0aGUgZGVmaW5pdGlvbiBv ZiB0aGUgaGFuZGxpbmcgcGFyYW1ldGVyLiANCj4gQW5kIDMyMDQgZ29lcyBvdXQNCj4gb2YgaXRz IHdheSB0byBzYXk6DQo+IA0KPiAgICAgVGhlIENvbnRlbnQtRGlzcG9zaXRpb24gaGVhZGVyIFs1 XSBtYXkgYmUgaW5jbHVkZWQgdG8gZGVzY3JpYmUgaG93DQo+ICAgICB0aGUgZW5jYXBzdWxhdGVk IElTVVAgaXMgdG8gYmUgcHJvY2Vzc2VkLCBhbmQgaW4gcGFydGljdWxhciB3aGF0IHRoZQ0KPiAg ICAgaGFuZGxpbmcgc2hvdWxkIGJlIGlmIHRoZSByZWNlaXZlZCBDb250ZW50LVR5cGUgaXMgbm90 IHJlY29nbml6ZWQuDQo+IA0KPiBUaGF0IHdvdWxkIG1ha2Ugbm8gc2Vuc2UgaWYgYWxsIFNJUCBV QSB3ZXJlIHJlcXVpcmVkIHRvIHJlY29nbml6ZSBJU1VQLg0KQ29tcGxldGVseSBhZ3JlZS4NCg0K UmVnYXJkcw0KVGhvbWFzDQoNCj4gDQo+IAlUaGFua3MsDQo+IAlQYXVsDQo+IA0KPiA+IFJlZ2Fy ZHMsDQo+ID4NCj4gPiBDaHJpc3Rlcg0KPiA+DQo+ID4gU2VudCBmcm9tIG15IFdpbmRvd3MgUGhv bmUNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBGcm9tOiBQYXVsIEt5eml2YXQgPG1haWx0bzpw a3l6aXZhdEBhbHVtLm1pdC5lZHU+DQo+ID4gU2VudDog4oCOMTAv4oCOMDMv4oCOMjAxNSAxNjo1 OA0KPiA+IFRvOiBzaXBjb3JlQGlldGYub3JnIDxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCj4g PiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIENvbnRlbnQtRGlzcG9zaXRpb24gcXVlc3Rpb25zDQo+ ID4NCj4gPiBPbiAzLzEwLzE1IDU6NDUgQU0sIFN0YWNoLCBUaG9tYXMgd3JvdGU6DQo+ID4NCj4g Pj4+IFFVRVNUSU9OXzI6IElmLCBmb3IgYSBzcGVjaWZpYyBtZXNzYWdlIGJvZHksIHRoZSAicmVu ZGVyIiBkZWZhdWx0IHR5cGUgY2FuDQo+IGJlDQo+ID4+PiBvdmVyd3JpdHRlbiwgc2hvdWxkbid0 IHRoYXQgYmUgbWVudGlvbmVkIGluIDMyNjE/DQo+ID4+DQo+ID4+IEkgdGhpbmsgdGhpcyBpcyBh bHJlYWR5IHdyaXR0ZW4gZG93bi4gVGhlIGxhc3Qgc2VudGVuY2UgaW4gc2VjdGlvbiAyMC4xMQ0K PiByZWFkcw0KPiA+PiAiICAgSWYgdGhpcyBoZWFkZXIgZmllbGQgaXMgbWlzc2luZywgdGhlIE1J TUUgdHlwZSBkZXRlcm1pbmVzIHRoZSBkZWZhdWx0DQo+ID4+ICAgICBjb250ZW50IGRpc3Bvc2l0 aW9uLiAgSWYgdGhlcmUgaXMgbm9uZSwgInJlbmRlciIgaXMgYXNzdW1lZC4iDQo+ID4+DQo+ID4+ IFNvLCBpZiB0aGUgTUlNRSB0eXBlIGlzIHVuZGVyc3Rvb2QsIHRoZSBkZWZhdWx0IGRpc3Bvc2l0 aW9uIGZyb20gdGhlDQo+ID4+IGNvcnJlc3BvbmRpbmcgTUlNRSBkZWZpbml0aW9uIGFwcGxpZXMu IE9mIGNvdXJzZSwgdGhpcyBkZWZhdWx0IGRpc3Bvc2l0aW9uDQo+ID4+IGNhbiBiZSBvdmVyd3Jp dHRlbiBieSBzZW5kaW5nIGEgY29ycmVzcG9uZGluZyBDLUQgaGVhZGVyIGZpZWxkLCBhcyBlLmcu DQo+IEVDTUEtMzU1IGRvZXMgZm9yICJxc2lnIi4NCj4gPj4gInJlbmRlciIga2lja3MgaW4sIG9u bHkgaWYgdGhlIE1JTUUgdHlwZSBpcyBub3QgdW5kZXJzdG9vZCBhbmQgaWYgQy1EIGlzDQo+IG9t aXR0ZWQuDQo+ID4+IERvZXMgdGhpcyBtYWtlIHNlbnNlPw0KPiA+DQo+ID4gVGhhdCBoYXMgYSBw cm9ibGVtLiBJdCBtYWtlcyBubyBzZW5zZSB0byBkZWZpbmUgYSBkZWZhdWx0IGhhbmRsaW5nDQo+ ID4gcGFyYW1ldGVyIHZhbHVlIGZvciBhIHNwZWNpZmljIG1pbWUgdHlwZSB0aGF0IGFwcGxpZXMg d2hlbiB0aGUgQy1EIGlzbid0DQo+ID4gcHJlc2VudC4gU3VwcG9zZSB5b3UgZGVmaW5lIGEgbWlt ZSB0eXBlIHdoZXJlIHRoZSBkZWZhdWx0IGhhbmRsaW5nIGlzDQo+ID4gIm9wdGlvbmFsIi4NCj4g Pg0KPiA+IFRoZW4gYSByZWNlaXZlciB0aGF0IGRvZXMgdW5kZXJzdGFuZCB0aGUgbWltZSB0eXBl IHdpbGwgdHJlYXQgdGhlDQo+ID4gaGFuZGxpbmcgYXMgb3B0aW9uYWwsIGJ1dCB0aGF0IGlzIGly cmVsZXZhbnQgYmVjYXVzZSB0aGlzIG9ubHkgYXBwbGllcw0KPiA+IGlmIHRoZSBtaW1lIHR5cGUg aXMgbm90IHVuZGVyc3Rvb2QuDQo+ID4NCj4gPiBBIHJlY2VpdmVyIHRoYXQgZG9lcyBub3QgdW5k ZXJzdGFuZCB0aGUgbWltZSB0eXBlIHdpbGwgdXNlIHRoZSBnbG9iYWwNCj4gPiBkZWZhdWx0IGhh bmRsaW5nIHZhbHVlICJyZXF1aXJlZCIuDQo+ID4NCj4gPiAgICAgICAgICBUaGFua3MsDQo+ID4g ICAgICAgICAgUGF1bA0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gPiBz aXBjb3JlQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaXBjb3JlDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K From nobody Fri Mar 13 04:18:27 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472F61A011D for ; Fri, 13 Mar 2015 04:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kG-y1unwAQ-n for ; Fri, 13 Mar 2015 04:18:23 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0CC1A0110 for ; Fri, 13 Mar 2015 04:18:22 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-ec-5502c77dc96b Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id DB.A4.19337.D77C2055; Fri, 13 Mar 2015 12:18:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0210.002; Fri, 13 Mar 2015 12:18:20 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Content-Disposition questions Thread-Index: AdBaY9SoDDjiuJSCSNy+9rzo9dcbwwAG+ntAACLKJ7AAAKAUgAAK9kqAAANbhKT///mIAP/7ifWQ Date: Fri, 13 Mar 2015 11:18:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D7396B4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D73005D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7335FB@ESESSMB209.ericsson.se> , <54FF04D9.7020609@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D7342B7@ESESSMB209.ericsson.se> <54FF15F4.9040006@alum.mit.edu> In-Reply-To: <54FF15F4.9040006@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvjW7tcaZQgzs7ZSxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjTedftoKtChVHP/1kb2Dskepi5OSQEDCR +Dh9MTOELSZx4d56ti5GLg4hgSOMEn/nTGSCcJYwSnR8XcvexcjBwSZgIdH9TxukQUQgUOLq kglgzcJAg9Z9+M0CUiIiYCqxb1kcREmUxP+eJ2AlLAKqEo9fbmABsXkFfCUuf1kKNX4hs8SR L88YQRKcAjoSn890s4HYjEAHfT+1hgnEZhYQl7j1ZD4TxKECEkv2nIc6WlTi5eN/rBC2okT7 0wZGiHoDiXPbN7JD2NoSyxa+ZoZYLChxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYhQtTi1O yk03MtZLLcpMLi7Oz9PLSy3ZxAiMk4NbfqvuYLz8xvEQowAHoxIP74cuplAh1sSy4srcQ4zS HCxK4rx2xodChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCWXfHP7lNuc9770zYpx2qN7qHp 66wO9N52W3PiybLTBt/WnV7x1iByjeuHj9PWREjz6Pi/5ROZ1qM951yERdX6iXrHGn879xda Nhr07d0b5XXmPM+56zoNOt+2Pr5/Ve7Usi6hjJm3Fj3p+2l4PvW+4+pdMYv56u6/aumNKJxc U7xuMevbtYaxSizFGYmGWsxFxYkAskeVSnQCAAA= Archived-At: Subject: Re: [sipcore] Content-Disposition questions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 11:18:25 -0000 Hi, Related to this, I see that Content-Disposition is not mentioned in RFC 644= 2 (Location Conveyance for the Session Initiation Protocol).=20 (This was also mentioned in ECRIT at one point: http://www.ietf.org/mail-ar= chive/web/ecrit/current/msg08517.html). So, that basically means that the default disposition type for the XML body= is "render", which I don't think fits very well. In addition, assuming the default handling value is "required", it also mea= ns that endpoints must support the XML body. But, perhaps that's ok. Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 10. maaliskuuta 2015 18:04 To: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] Content-Disposition questions On 3/10/15 11:27 AM, Christer Holmberg wrote: > Hi Paul, > > It is not the default handling value that is different for the=20 > qsig/isup bodies - it is the default type value ("signal", rather than "r= ender"). I know they define the default disposition type for those mime types. But I thought Thomas was also saying that they change the default handling = to "optional", and I was commenting on the relevance of that part. If you i= nclude a qsig mime body, and don't include a C-D with handling=3D"optional"= then a recipient that doesn't know the mime type should treat it as "requi= red" and reject the request, regardless of what defaults are defined for th= at mime type. > I am not sure I agree with Thomas that a SIP client must support the=20 > qsig/isup bodies. Yes, 3261 does reference the CR, but mostly for=20 > information regarding the C-D header field itself. I agree with you. Classifying a reference as normative doesn't mean that ev= ery aspect of that draft is required. And the only body reference in 3261 is wrt the definition of the handling parameter. And 3204 goes out of = its way to say: The Content-Disposition header [5] may be included to describe how the encapsulated ISUP is to be processed, and in particular what the handling should be if the received Content-Type is not recognized. That would make no sense if all SIP UA were required to recognize ISUP. Thanks, Paul > Regards, > > Christer > > Sent from my Windows Phone > ---------------------------------------------------------------------- > -- > From: Paul Kyzivat > Sent: =FD10/=FD03/=FD2015 16:58 > To: sipcore@ietf.org > Subject: Re: [sipcore] Content-Disposition questions > > On 3/10/15 5:45 AM, Stach, Thomas wrote: > >>> QUESTION_2: If, for a specific message body, the "render" default=20 >>> type can be overwritten, shouldn't that be mentioned in 3261? >> >> I think this is already written down. The last sentence in section 20.11= reads >> " If this header field is missing, the MIME type determines the defaul= t >> content disposition. If there is none, "render" is assumed." >> >> So, if the MIME type is understood, the default disposition from the=20 >> corresponding MIME definition applies. Of course, this default=20 >> disposition can be overwritten by sending a corresponding C-D header fie= ld, as e.g. ECMA-355 does for "qsig". >> "render" kicks in, only if the MIME type is not understood and if C-D is= omitted. >> Does this make sense? > > That has a problem. It makes no sense to define a default handling=20 > parameter value for a specific mime type that applies when the C-D=20 > isn't present. Suppose you define a mime type where the default=20 > handling is "optional". > > Then a receiver that does understand the mime type will treat the=20 > handling as optional, but that is irrelevant because this only applies=20 > if the mime type is not understood. > > A receiver that does not understand the mime type will use the global=20 > default handling value "required". > > Thanks, > Paul > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Sat Mar 14 09:58:45 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DF81A0277 for ; Sat, 14 Mar 2015 09:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdVlQnDh9cCi for ; Sat, 14 Mar 2015 09:58:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F661A026A for ; Sat, 14 Mar 2015 09:58:39 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id D2AEB26425E; Sat, 14 Mar 2015 17:58:37 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 9E851238056; Sat, 14 Mar 2015 17:58:37 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Sat, 14 Mar 2015 17:58:37 +0100 From: To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] Comment on draft-ietf-sipcore-refer-explicit-subscription-01 Thread-Index: AdBed7/EO4fQAoUJRcSohVaf/WA0hw== Date: Sat, 14 Mar 2015 16:58:36 +0000 Message-ID: <12455_1426352317_550468BD_12455_2010_1_8B970F90C584EA4E97D5BAAC9172DBB814318AE6@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB814318AE6PEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.112421 Archived-At: Subject: [sipcore] Comment on draft-ietf-sipcore-refer-explicit-subscription-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 16:58:43 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB814318AE6PEXCVZYM12corpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I did a late review of draft-ietf-sipcore-refer-clarifications-03 and draft= -ietf-sipcore-refer-explicit-subscription-01. I'm fine with those drafts but I just have one comment on draft-ietf-sipco= re-refer-explicit-subscription-01 and I prefer to do it before its publicat= ion: On this draft it is clearly stated for the 'explicitsub' option tag that "= The event server identified by the Refer-Events-At URI could receive SUBSCRIBE requests" In section 5.1 : For the 'nosub' option tag, even if it is stated that "no explicit subscrip= tion will be forthcoming", there is no explicit statement such as : A UA se= nding a REFER with the 'nosub' option tag MUST NOT send a SUBSCRIBE request= for that dialog. Maybe you consider, this situation cannot appear as this UA will not receiv= e the event server URI in the Refer-Event-At? In that case, I think it would be good to have the following statements: - in section 5.2: If the UA receives a 2xx-class response, it will no= t contain a Refer-Events-At header field. and - in section 5.3: An element that accepts a REFER request with 'nosub= ' in its Require header field MUST return a 200 response that MUST NOT cont= ain a URI that could be used to subscribe to the refer event state associat= ed with this REFER request. It is also possible that I missed something already mentioned in the draft. If not, I think a statement like that could reinforce the correct usage of = the 'nosub' option tag. Sorry about this very late comment. Kind regards, Marianne Mohali ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8B970F90C584EA4E97D5BAAC9172DBB814318AE6PEXCVZYM12corpo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I did a late review of draft-ietf-sipcore-refer-clarifications-03 and = draft-ietf-sipcore-refer-explicit-subscription-01.

I’m fine with those draft= s but I just have one comment on  draft-ietf-sipcore-refer-explicit-su= bscription-01 and I prefer to do it before its publication:

 

On this draft it is clearly stated for the ‘explicitsub’ op= tion tag that  "The event server identified by the Refer-Events-At URI could receive

SUBSCRIBE requests"

In section 5.1 :

For the ‘nosub’= ; option tag, even if it is stated that “no explicit subscription wil= l be forthcoming”, there is no explicit statement such as : A UA sending a REFER w= ith the ‘nosub’ option tag MUST NOT send a SUBSCRIBE request for that dialog.

 

Maybe you consider, this s= ituation cannot appear as this UA will not receive the event server URI in = the Refer-Event-At?

 

In that case, I think it would be good to have the following statements= :

-  &nb= sp;    in section 5.2: If the UA receives a 2xx-class response, it = will not contain a Refer-Events-At header field.

and

-  &nb= sp;    in section 5.3: An element that accepts a REFER request wi= th ’nosub’ in its Require header field MUST return a 200 respon= se that MUST NOT contain a URI that could be used to subscribe to the refer event state associated with this REFER request.

 

It is also possible that I= missed something already mentioned in the draft.

If not, I think a statemen= t like that could reinforce the correct usage of the ‘nosub’ op= tion tag.

 

Sorry about this very late= comment.

 

Kind regards,

Marianne Mohali=

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_8B970F90C584EA4E97D5BAAC9172DBB814318AE6PEXCVZYM12corpo_-- From nobody Tue Mar 17 10:25:40 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3921A87D7 for ; Tue, 17 Mar 2015 10:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_LOLITA1=1.865, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPIwEMBMUKfC for ; Tue, 17 Mar 2015 10:25:37 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A53A1A87E2 for ; Tue, 17 Mar 2015 10:25:24 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-29-550863828ec3 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A1.4D.01716.28368055; Tue, 17 Mar 2015 18:25:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0210.002; Tue, 17 Mar 2015 18:25:22 +0100 From: Christer Holmberg To: Ivo Sedlacek , Adam Roach , 'SIPCORE' , Brett Tate Thread-Topic: Concluded: WGLC / Call for Adoption: REFER-related work Thread-Index: AQHQUuqrIQAMujZGOU68UZ6cpXMyup0L7vOAgBUZ6Lc= Date: Tue, 17 Mar 2015 17:25:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D766E5E@ESESSMB209.ericsson.se> References: <54DA3735.30807@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D6C9D62@ESESSMB209.ericsson.se> <54F106F1.90302@nostrum.com>, <39B5E4D390E9BD4890E2B3107900610112831FC8@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112831FC8@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D766E5EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+JvjW5TMkeoweEpphZ7/i5it2ie/4/R 4uuPTWwOzB4/bgd6LFnyk8lj1s4nLAHMUVw2Kak5mWWpRfp2CVwZZ5edYS744VfR8f48WwPj A58uRg4OCQETiRkzHLoYOYFMMYkL99azdTFycQgJHGGUuPlyHzOEs4RR4sLlo0wgDWwCFhLd /7RB4iICvYwS/xZfZATpFhZwkXh84hsbiC0i4CqxZfd3JgjbSqLv83F2kF4WAVWJOYsKQExe AV+J5k49iPFnGSX27T0KNoZTwE9i46PfYGMYgQ76fmoN2BhmAXGJpi8rWSEOFZBYsuc8M4Qt KvHy8T9WkJnMAvkSu2eLgYR5BQQlTs58wjKBUXgWku5ZCFWzkFRBhDUl1u/Sh6hWlJjS/ZAd wtaQaJ0zlx1ZfAEj+ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwEg6uOW37g7G1a8dDzEK cDAq8fBumMEeKsSaWFZcmXuIUZqDRUmc1874UIiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkG RosTMoFivYlM9T4uWuYeyv/fFE9aMvHi4YQC2y13qqcHt0kd8hB7xvnyx+ecWTuf3zjmqd/w pbigQT3fnfNSlb9E3PJDweK6y8TF+i47qx1ZOV/znmyOAYOekBffTbGif/IydxdftPl0PV/3 UKGw9hzDh2HLnKpO8kTXn6xnvekW4d7CZ5yvxFKckWioxVxUnAgA9ebl8YUCAAA= Archived-At: Subject: Re: [sipcore] Concluded: WGLC / Call for Adoption: REFER-related work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 17:25:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D766E5EESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldoYXQgaXMgdGhlIHN0YXR1cyBvZiB0aGlzPyBIYXMgSXZvJ3MgY29tbWVudCBiZWVu IGFkZHJlc3NlZD8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KU2VudCBmcm9tIG15IFdpbmRv d3MgUGhvbmUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBJdm8gU2Vk bGFjZWs8bWFpbHRvOml2by5zZWRsYWNla0Blcmljc3Nvbi5jb20+DQpTZW50OiDigI4wNC/igI4w My/igI4yMDE1IDEwOjExDQpUbzogQWRhbSBSb2FjaDxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT47 IENocmlzdGVyIEhvbG1iZXJnPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+ OyAnU0lQQ09SRSc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+OyBCcmV0dCBUYXRlPG1haWx0bzpi cmV0dEBicm9hZHNvZnQuY29tPg0KU3ViamVjdDogUkU6IENvbmNsdWRlZDogV0dMQyAvIENhbGwg Zm9yIEFkb3B0aW9uOiBSRUZFUi1yZWxhdGVkIHdvcmsNCg0KDQpIZWxsbywNCg0KDQoNCkkgcmV2 aWV3ZWQgZHJhZnQtaWV0Zi1zaXBjb3JlLXJlZmVyLWNsYXJpZmljYXRpb25zLTAzIGFuZCBkcmFm dC1pZXRmLXNpcGNvcmUtcmVmZXItZXhwbGljaXQtc3Vic2NyaXB0aW9uLTAwICBhbmQgZm91bmQg bm8gaXNzdWVzLiBPSyB0byBwcm9ncmVzcyB0aG9zZSBkcmFmdHMuDQoNCkkgcmV2aWV3ZWQgZHJh ZnQtaWV0Zi1zaXBjb3JlLTY2NjUtY2xhcmlmaWNhdGlvbi0wMCBhbmQgc2VudCBhIGNvbW1lbnQg dG8gdGhlIFNJUENPUkUgbGlzdCB5ZXN0ZXJkYXkgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNnMDY1NjEuaHRtbCkuIEkgcHJlZmVyIHRoZSBj b21tZW50IGJlaW5nIGFkZHJlc3NlZCBiZWZvcmUgcHJvZ3Jlc3NpbmcgdGhlIGRyYWZ0Lg0KDQpL aW5kIHJlZ2FyZHMNCg0KSXZvIFNlZGxhY2VrDQoNCg0KDQpUaGlzIENvbW11bmljYXRpb24gaXMg Q29uZmlkZW50aWFsLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lz IG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0IHd3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1l cg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFkYW0gUm9hY2ggW21h aWx0bzphZGFtQG5vc3RydW0uY29tXQ0KU2VudDogMjguIMO6bm9yYSAyMDE1IDE6MDgNClRvOiBD aHJpc3RlciBIb2xtYmVyZzsgJ1NJUENPUkUnOyBJdm8gU2VkbGFjZWs7IEJyZXR0IFRhdGUNClN1 YmplY3Q6IENvbmNsdWRlZDogV0dMQyAvIENhbGwgZm9yIEFkb3B0aW9uOiBSRUZFUi1yZWxhdGVk IHdvcmsNCg0KDQoNClthcyBjaGFpcl0NCg0KDQoNClRoZSBhZG9wdGlvbiBhbmQgV0dMQyBwZXJp b2QgZm9yIHRoZSB0aHJlZSBkb2N1bWVudHMgaGFzIGVuZGVkLiBHaXZlbiB0aGUgZXhwcmVzc2Vk IHN1cHBvcnQgKG1lYWdlciBhcyBpdCB3YXMpIGFuZCBsYWNrIG9mIG9iamVjdGlvbiwgd2UncmUg Z29pbmcgdG8gY29uc2lkZXIgdGhlIDY2NjUtY2xhcmlmaWNhdGlvbnMgZHJhZnQgYWRvcHRlZC4N Cg0KDQoNClRoZXJlIHdlcmUgbm8gYWRkaXRpb25hbCBjb21tZW50cyBvbiByZWZlci1jbGFyaWZp Y2F0aW9ucyBvciByZWZlci1leHBsaWNpdC1zdWJzY3JpcHRpb24sIHNvIHdlIHdpbGwgYmVnaW4g cHJlcGFyaW5nIHRoZW0gZm9yIElFU0cgcmV2aWV3Lg0KDQoNCg0KW2FzIGF1dGhvcl0NCg0KDQoN CkEgbmV3IHZlcnNpb24gdGhhdCBJIGJlbGlldmUgYWRkcmVzc2VzIHRoZSBvdXRzdGFuZGluZyBj b21tZW50cyBvbiB0aGUNCg0KNjY2NSBjbGFyaWZpY2F0aW9uIGRvY3VtZW50IGlzIGF2YWlsYWJs ZSBoZXJlOg0KDQoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1zaXBjb3JlLTY2NjUtY2xhcmlmaWNhdGlvbi8NCg0KDQoNCkl2byAvIEJyZXR0OiBhcyB5b3Ug d2VyZSB0aGUgcGVvcGxlIHdobyBwcm92aWRlZCB0aGUgZmVlZGJhY2sgdGhhdCBJJ3ZlIGluY29y cG9yYXRlZCwgcGxlYXNlIGxvb2sgb3ZlciB0aGlzIGxhdGVzdCB0ZXh0IHRvIGxldCBtZSBrbm93 IHdoZXRoZXIgaXQgYWRkcmVzc2VzIHRoZSBzcGVjaWZpYyBjb25jZXJuIHRoYXQgaGFkIGJlZW4g cmFpc2VkLiBUaGFua3MhDQoNCg0KDQovYQ0K --_000_7594FB04B1934943A5C02806D1A2204B1D766E5EESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaX0NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYifQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmV9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmV9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxh aW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIn0NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYifQ0KLk1zb0NocERlZmF1bHQNCgl7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIn0NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXttYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w cHQgNzIuMHB0fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXt9DQotLT4NCjwvc3R5bGU+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFw dCI+SGksPGJyPg0KPGJyPg0KV2hhdCBpcyB0aGUgc3RhdHVzIG9mIHRoaXM/IEhhcyBJdm8ncyBj b21tZW50IGJlZW4gYWRkcmVzc2VkPzxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hy aXN0ZXI8YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZTwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGRpcj0ibHRyIj4NCjxocj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5Gcm9tOg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZToxMXB0Ij48YSBocmVmPSJtYWlsdG86aXZvLnNlZGxhY2VrQGVyaWNzc29uLmNvbSI+SXZvIFNl ZGxhY2VrPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxz YW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDoNCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6 MTFwdCI+4oCOMDQv4oCOMDMv4oCOMjAxNSAxMDoxMTwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWln aHQ6Ym9sZCI+VG86DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fu cy1zZXJpZjsgZm9udC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0uY29t Ij5BZGFtIFJvYWNoPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb20iPkNocmlzdGVyIEhvbG1iZXJnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVA aWV0Zi5vcmciPg0KJ1NJUENPUkUnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmJyZXR0QGJyb2Fkc29m dC5jb20iPkJyZXR0IFRhdGU8L2E+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5T dWJqZWN0Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZToxMXB0Ij5SRTogQ29uY2x1ZGVkOiBXR0xDIC8gQ2FsbCBmb3IgQWRvcHRp b246IFJFRkVSLXJlbGF0ZWQgd29yazwvc3Bhbj48YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGVsbG8s PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+SSByZXZpZXdlZCBkcmFmdC1pZXRmLXNpcGNvcmUtcmVmZXItY2xhcmlmaWNhdGlv bnMtMDMgYW5kIGRyYWZ0LWlldGYtc2lwY29yZS1yZWZlci1leHBsaWNpdC1zdWJzY3JpcHRpb24t MDAmbmJzcDsgYW5kIGZvdW5kIG5vIGlzc3Vlcy4gT0sgdG8gcHJvZ3Jlc3MgdGhvc2UgZHJhZnRz LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPkkgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1zaXBjb3JlLTY2NjUtY2xhcmlmaWNhdGlvbi0wMCBh bmQgc2VudCBhIGNvbW1lbnQgdG8gdGhlIFNJUENPUkUgbGlzdCB5ZXN0ZXJkYXkgKDxhIGhyZWY9 Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNn MDY1NjEuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUv Y3VycmVudC9tc2cwNjU2MS5odG1sPC9hPikuDQogSSBwcmVmZXIgdGhlIGNvbW1lbnQgYmVpbmcg YWRkcmVzc2VkIGJlZm9yZSBwcm9ncmVzc2luZyB0aGUgZHJhZnQuPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+S2luZCByZWdhcmRzPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ SXZvIFNlZGxhY2VrIDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPlRoaXMgQ29tbXVuaWNhdGlvbiBpcyBDb25maWRlbnRpYWwu IFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1z IHNldCBvdXQgYXQgd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyDQo8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IEFkYW0gUm9hY2ggW21haWx0bzph ZGFtQG5vc3RydW0uY29tXSA8YnI+DQpTZW50OiAyOC4gw7pub3JhIDIwMTUgMTowODxicj4NClRv OiBDaHJpc3RlciBIb2xtYmVyZzsgJ1NJUENPUkUnOyBJdm8gU2VkbGFjZWs7IEJyZXR0IFRhdGU8 YnI+DQpTdWJqZWN0OiBDb25jbHVkZWQ6IFdHTEMgLyBDYWxsIGZvciBBZG9wdGlvbjogUkVGRVIt cmVsYXRlZCB3b3JrPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+W2FzIGNoYWlyXTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBhZG9wdGlvbiBhbmQg V0dMQyBwZXJpb2QgZm9yIHRoZSB0aHJlZSBkb2N1bWVudHMgaGFzIGVuZGVkLiBHaXZlbiB0aGUg ZXhwcmVzc2VkIHN1cHBvcnQgKG1lYWdlciBhcyBpdCB3YXMpIGFuZCBsYWNrIG9mIG9iamVjdGlv biwgd2UncmUgZ29pbmcgdG8gY29uc2lkZXIgdGhlIDY2NjUtY2xhcmlmaWNhdGlvbnMgZHJhZnQg YWRvcHRlZC48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5UaGVyZSB3ZXJlIG5vIGFkZGl0aW9uYWwgY29tbWVudHMgb24gcmVm ZXItY2xhcmlmaWNhdGlvbnMgb3IgcmVmZXItZXhwbGljaXQtc3Vic2NyaXB0aW9uLCBzbyB3ZSB3 aWxsIGJlZ2luIHByZXBhcmluZyB0aGVtIGZvciBJRVNHIHJldmlldy48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5bYXMgYXV0 aG9yXTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkEgbmV3IHZlcnNpb24gdGhhdCBJIGJlbGlldmUgYWRkcmVzc2VzIHRoZSBv dXRzdGFuZGluZyBjb21tZW50cyBvbiB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij42 NjY1IGNsYXJpZmljYXRpb24gZG9jdW1lbnQgaXMgYXZhaWxhYmxlIGhlcmU6PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaXBjb3Jl LTY2NjUtY2xhcmlmaWNhdGlvbi8iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0OyB0ZXh0 LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1zaXBjb3JlLTY2NjUtY2xhcmlmaWNhdGlvbi88L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkl2byAv IEJyZXR0OiBhcyB5b3Ugd2VyZSB0aGUgcGVvcGxlIHdobyBwcm92aWRlZCB0aGUgZmVlZGJhY2sg dGhhdCBJJ3ZlIGluY29ycG9yYXRlZCwgcGxlYXNlIGxvb2sgb3ZlciB0aGlzIGxhdGVzdCB0ZXh0 IHRvIGxldCBtZSBrbm93IHdoZXRoZXIgaXQgYWRkcmVzc2VzIHRoZSBzcGVjaWZpYyBjb25jZXJu IHRoYXQgaGFkIGJlZW4gcmFpc2VkLiBUaGFua3MhPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+L2E8L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D766E5EESESSMB209erics_-- From nobody Thu Mar 19 01:36:47 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F82E1A00C2 for ; Thu, 19 Mar 2015 01:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_LOLITA1=1.865, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXcJ9JClxliO for ; Thu, 19 Mar 2015 01:36:43 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7FB91A1A39 for ; Thu, 19 Mar 2015 01:36:41 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-58-550a8a97a652 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C5.E6.28835.79A8A055; Thu, 19 Mar 2015 09:36:39 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.84]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0210.002; Thu, 19 Mar 2015 09:36:38 +0100 From: Ivo Sedlacek To: Christer Holmberg , Adam Roach , 'SIPCORE' , Brett Tate Thread-Topic: Concluded: WGLC / Call for Adoption: REFER-related work Thread-Index: AQHQUuqrIQAMujZGOU68UZ6cpXMyup0L7vOAgBUZ6LeAApC2wA== Date: Thu, 19 Mar 2015 08:36:38 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061011284CCB1@ESESSMB301.ericsson.se> References: <54DA3735.30807@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D6C9D62@ESESSMB209.ericsson.se> <54F106F1.90302@nostrum.com>, <39B5E4D390E9BD4890E2B3107900610112831FC8@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D766E5E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D766E5E@ESESSMB209.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061011284CCB1ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3Rnd6F1eoQf9UGYs9fxexWzTP/8do 8fXHJjYHZo8ftwM9liz5yeQxa+cTlgDmKC6blNSczLLUIn27BK6MC0/+sxZ8aWSsOLfuL2MD 45a6LkZODgkBE4nVXw8xQthiEhfurWfrYuTiEBI4wigxYe4hdghnMaPEjzcHwarYBPQkJm45 wgqSEBGYyShx/eUCZpCEsICLxOMT39hAbBEBV4ktu78zQdhOEv1fVoA1swioSjye8Z4VxOYV 8JW407cGat1EJoklm56DFXEK+Ek8+XMazGYUkJW4+qcXzGYWEJe49WQ+E8StAhJL9pxnhrBF JV4+/scKYStKtD9tgKrPl3j/7xMjxDJBiZMzn7BMYBSZhWTULCRls5CUzWLkAIprSqzfpQ9R oigxpfshO4StIdE6Zy47svgCRvZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIHxdnDLb6sd jAefOx5iFOBgVOLh/VDMFSrEmlhWXJl7iFGag0VJnNfO+FCIkEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBsbAR4UbOfYobNox2fRWRI/sMlHmeoFvX8SNAw5M8nqUqpR2cNt3lsffguvea0az 3fiW/Hb5BZljrV3+Ah2bv818HswclpKwps97zW/fBcczTr1bytZgI3CvvXlu/fakX6kcbXfO nWHu+zaraP2bTqXQ236CmjX/dWd33xKJvf/vVFOo6GYj3utKLMUZiYZazEXFiQD8bs97mAIA AA== Archived-At: Subject: Re: [sipcore] Concluded: WGLC / Call for Adoption: REFER-related work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 08:36:45 -0000 --_000_39B5E4D390E9BD4890E2B310790061011284CCB1ESESSMB301erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCm15IGNvbW1lbnQgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9zaXBjb3JlL2N1cnJlbnQvbXNnMDY1NjEuaHRtbCkgaGFzIG5vdCBiZWVuIGFkZHJlc3NlZCB5 ZXQuDQoNCktpbmQgcmVnYXJkcw0KDQpJdm8gU2VkbGFjZWsNCg0KVGhpcyBDb21tdW5pY2F0aW9u IGlzIENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBi YXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdCB3d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2Ns YWltZXI8aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lcj4NCkZyb206IENo cmlzdGVyIEhvbG1iZXJnDQpTZW50OiAxNy4gYsWZZXpuYSAyMDE1IDE4OjI1DQpUbzogSXZvIFNl ZGxhY2VrOyBBZGFtIFJvYWNoOyAnU0lQQ09SRSc7IEJyZXR0IFRhdGUNClN1YmplY3Q6IFJFOiBD b25jbHVkZWQ6IFdHTEMgLyBDYWxsIGZvciBBZG9wdGlvbjogUkVGRVItcmVsYXRlZCB3b3JrDQoN CkhpLA0KDQpXaGF0IGlzIHRoZSBzdGF0dXMgb2YgdGhpcz8gSGFzIEl2bydzIGNvbW1lbnQgYmVl biBhZGRyZXNzZWQ/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNClNlbnQgZnJvbSBteSBXaW5k b3dzIFBob25lDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogSXZvIFNl ZGxhY2VrPG1haWx0bzppdm8uc2VkbGFjZWtAZXJpY3Nzb24uY29tPg0KU2VudDog4oCOMDQv4oCO MDMv4oCOMjAxNSAxMDoxMQ0KVG86IEFkYW0gUm9hY2g8bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20+ OyBDaHJpc3RlciBIb2xtYmVyZzxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PjsgJ1NJUENPUkUnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPjsgQnJldHQgVGF0ZTxtYWlsdG86 YnJldHRAYnJvYWRzb2Z0LmNvbT4NClN1YmplY3Q6IFJFOiBDb25jbHVkZWQ6IFdHTEMgLyBDYWxs IGZvciBBZG9wdGlvbjogUkVGRVItcmVsYXRlZCB3b3JrDQoNCkhlbGxvLA0KDQoNCg0KSSByZXZp ZXdlZCBkcmFmdC1pZXRmLXNpcGNvcmUtcmVmZXItY2xhcmlmaWNhdGlvbnMtMDMgYW5kIGRyYWZ0 LWlldGYtc2lwY29yZS1yZWZlci1leHBsaWNpdC1zdWJzY3JpcHRpb24tMDAgIGFuZCBmb3VuZCBu byBpc3N1ZXMuIE9LIHRvIHByb2dyZXNzIHRob3NlIGRyYWZ0cy4NCg0KSSByZXZpZXdlZCBkcmFm dC1pZXRmLXNpcGNvcmUtNjY2NS1jbGFyaWZpY2F0aW9uLTAwIGFuZCBzZW50IGEgY29tbWVudCB0 byB0aGUgU0lQQ09SRSBsaXN0IHllc3RlcmRheSAoaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwNjU2MS5odG1sKS4gSSBwcmVmZXIgdGhlIGNv bW1lbnQgYmVpbmcgYWRkcmVzc2VkIGJlZm9yZSBwcm9ncmVzc2luZyB0aGUgZHJhZnQuDQoNCktp bmQgcmVnYXJkcw0KDQpJdm8gU2VkbGFjZWsNCg0KDQoNClRoaXMgQ29tbXVuaWNhdGlvbiBpcyBD b25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMg b2YgdGhlIHRlcm1zIHNldCBvdXQgYXQgd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVy PGh0dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI+DQoNCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1 bS5jb21dDQpTZW50OiAyOC4gw7pub3JhIDIwMTUgMTowOA0KVG86IENocmlzdGVyIEhvbG1iZXJn OyAnU0lQQ09SRSc7IEl2byBTZWRsYWNlazsgQnJldHQgVGF0ZQ0KU3ViamVjdDogQ29uY2x1ZGVk OiBXR0xDIC8gQ2FsbCBmb3IgQWRvcHRpb246IFJFRkVSLXJlbGF0ZWQgd29yaw0KDQoNCg0KW2Fz IGNoYWlyXQ0KDQoNCg0KVGhlIGFkb3B0aW9uIGFuZCBXR0xDIHBlcmlvZCBmb3IgdGhlIHRocmVl IGRvY3VtZW50cyBoYXMgZW5kZWQuIEdpdmVuIHRoZSBleHByZXNzZWQgc3VwcG9ydCAobWVhZ2Vy IGFzIGl0IHdhcykgYW5kIGxhY2sgb2Ygb2JqZWN0aW9uLCB3ZSdyZSBnb2luZyB0byBjb25zaWRl ciB0aGUgNjY2NS1jbGFyaWZpY2F0aW9ucyBkcmFmdCBhZG9wdGVkLg0KDQoNCg0KVGhlcmUgd2Vy ZSBubyBhZGRpdGlvbmFsIGNvbW1lbnRzIG9uIHJlZmVyLWNsYXJpZmljYXRpb25zIG9yIHJlZmVy LWV4cGxpY2l0LXN1YnNjcmlwdGlvbiwgc28gd2Ugd2lsbCBiZWdpbiBwcmVwYXJpbmcgdGhlbSBm b3IgSUVTRyByZXZpZXcuDQoNCg0KDQpbYXMgYXV0aG9yXQ0KDQoNCg0KQSBuZXcgdmVyc2lvbiB0 aGF0IEkgYmVsaWV2ZSBhZGRyZXNzZXMgdGhlIG91dHN0YW5kaW5nIGNvbW1lbnRzIG9uIHRoZQ0K DQo2NjY1IGNsYXJpZmljYXRpb24gZG9jdW1lbnQgaXMgYXZhaWxhYmxlIGhlcmU6DQoNCg0KDQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNpcGNvcmUtNjY2NS1j bGFyaWZpY2F0aW9uLw0KDQoNCg0KSXZvIC8gQnJldHQ6IGFzIHlvdSB3ZXJlIHRoZSBwZW9wbGUg d2hvIHByb3ZpZGVkIHRoZSBmZWVkYmFjayB0aGF0IEkndmUgaW5jb3Jwb3JhdGVkLCBwbGVhc2Ug bG9vayBvdmVyIHRoaXMgbGF0ZXN0IHRleHQgdG8gbGV0IG1lIGtub3cgd2hldGhlciBpdCBhZGRy ZXNzZXMgdGhlIHNwZWNpZmljIGNvbmNlcm4gdGhhdCBoYWQgYmVlbiByYWlzZWQuIFRoYW5rcyEN Cg0KDQoNCi9hDQo= --_000_39B5E4D390E9BD4890E2B310790061011284CCB1ESESSMB301erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7 DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnAuTXNvQWNldGF0ZSwg bGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLm1zb2NocGRlZmF1 bHQsIGxpLm1zb2NocGRlZmF1bHQsIGRpdi5tc29jaHBkZWZhdWx0DQoJe21zby1zdHlsZS1uYW1l Om1zb2NocGRlZmF1bHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CnNwYW4ucGxhaW50ZXh0Y2hhcjANCgl7bXNvLXN0eWxlLW5hbWU6cGxhaW50ZXh0Y2hhcjsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiM5ODQ4MDY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTg0ODA2Ij5IZWxsbyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 Izk4NDgwNiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5ODQ4MDYiPm15IGNvbW1lbnQgPC9zcGFuPig8YSBocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50L21z ZzA2NTYxLmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBjb3Jl L2N1cnJlbnQvbXNnMDY1NjEuaHRtbDwvYT4pDQo8c3BhbiBzdHlsZT0iY29sb3I6Izk4NDgwNiI+ aGFzIG5vdCBiZWVuIGFkZHJlc3NlZCB5ZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5ODQ4MDYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj OTg0ODA2Ij5LaW5kIHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk4NDgwNiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5ODQ4MDYi Pkl2byBTZWRsYWNlazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojOTg0ODA2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMz MzMzMyI+VGhpcyBDb21tdW5pY2F0aW9uIGlzIENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5kIGFu ZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdA0KPGEg aHJlZj0iaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lciIgdGl0bGU9Imh0 dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXIiPg0Kd3d3LmVyaWNzc29uLmNv bS9lbWFpbF9kaXNjbGFpbWVyPC9hPiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IENocmlzdGVyIEhvbG1iZXJnDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTcuIGLFmWV6bmEg MjAxNSAxODoyNTxicj4NCjxiPlRvOjwvYj4gSXZvIFNlZGxhY2VrOyBBZGFtIFJvYWNoOyAnU0lQ Q09SRSc7IEJyZXR0IFRhdGU8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IENvbmNsdWRlZDogV0dM QyAvIENhbGwgZm9yIEFkb3B0aW9uOiBSRUZFUi1yZWxhdGVkIHdvcms8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxicj4NCjxi cj4NCldoYXQgaXMgdGhlIHN0YXR1cyBvZiB0aGlzPyBIYXMgSXZvJ3MgY29tbWVudCBiZWVuIGFk ZHJlc3NlZD88YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJy Pg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i dGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+DQo8aHIg c2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj5Gcm9tOiA8 L2I+PGEgaHJlZj0ibWFpbHRvOml2by5zZWRsYWNla0Blcmljc3Nvbi5jb20iPkl2byBTZWRsYWNl azwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48Yj5TZW50 OiA8L2I+4oCOMDQv4oCOMDMv4oCOMjAxNSAxMDoxMTxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+PGJyPg0KPC9zcGFuPjxiPlRvOiA8L2I+PGEgaHJlZj0ibWFpbHRvOmFkYW1Abm9zdHJ1 bS5jb20iPkFkYW0gUm9hY2g8L2E+OyA8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tIj4NCkNocmlzdGVyIEhvbG1iZXJnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNp cGNvcmVAaWV0Zi5vcmciPidTSVBDT1JFJzwvYT47IDxhIGhyZWY9Im1haWx0bzpicmV0dEBicm9h ZHNvZnQuY29tIj4NCkJyZXR0IFRhdGU8L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij48YnI+DQo8L3NwYW4+PGI+U3ViamVjdDogPC9iPlJFOiBDb25jbHVkZWQ6IFdHTEMgLyBDYWxs IGZvciBBZG9wdGlvbjogUkVGRVItcmVsYXRlZCB3b3JrPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+SGVsbG8sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PkkgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1zaXBjb3JlLXJlZmVyLWNsYXJpZmljYXRpb25zLTAzIGFu ZCBkcmFmdC1pZXRmLXNpcGNvcmUtcmVmZXItZXhwbGljaXQtc3Vic2NyaXB0aW9uLTAwJm5ic3A7 IGFuZCBmb3VuZCBubyBpc3N1ZXMuIE9LIHRvIHByb2dyZXNzIHRob3NlIGRyYWZ0cy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1z aXBjb3JlLTY2NjUtY2xhcmlmaWNhdGlvbi0wMCBhbmQgc2VudCBhIGNvbW1lbnQgdG8gdGhlIFNJ UENPUkUgbGlzdCB5ZXN0ZXJkYXkgKDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNnMDY1NjEuaHRtbCI+aHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwNjU2MS5odG1sPC9hPiku DQogSSBwcmVmZXIgdGhlIGNvbW1lbnQgYmVpbmcgYWRkcmVzc2VkIGJlZm9yZSBwcm9ncmVzc2lu ZyB0aGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5LaW5k IHJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkl2byBTZWRs YWNlayA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhpcyBDb21tdW5pY2F0aW9uIGlz IENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNp cyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdA0KPGEgaHJlZj0iaHR0cDovL3d3dy5lcmljc3Nvbi5j b20vZW1haWxfZGlzY2xhaW1lciI+d3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPC9h Pg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPg0KRnJvbTogQWRhbSBSb2FjaCBbPGEgaHJlZj0ibWFpbHRvOmFkYW1Abm9zdHJ1bS5j b20iPm1haWx0bzphZGFtQG5vc3RydW0uY29tPC9hPl0gPGJyPg0KU2VudDogMjguIMO6bm9yYSAy MDE1IDE6MDg8YnI+DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmc7ICdTSVBDT1JFJzsgSXZvIFNlZGxh Y2VrOyBCcmV0dCBUYXRlPGJyPg0KU3ViamVjdDogQ29uY2x1ZGVkOiBXR0xDIC8gQ2FsbCBmb3Ig QWRvcHRpb246IFJFRkVSLXJlbGF0ZWQgd29yazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5bYXMgY2hhaXJdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBhZG9wdGlvbiBh bmQgV0dMQyBwZXJpb2QgZm9yIHRoZSB0aHJlZSBkb2N1bWVudHMgaGFzIGVuZGVkLiBHaXZlbiB0 aGUgZXhwcmVzc2VkIHN1cHBvcnQgKG1lYWdlciBhcyBpdCB3YXMpIGFuZCBsYWNrIG9mIG9iamVj dGlvbiwgd2UncmUgZ29pbmcgdG8gY29uc2lkZXIgdGhlIDY2NjUtY2xhcmlmaWNhdGlvbnMgZHJh ZnQgYWRvcHRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlcmUgd2VyZSBubyBh ZGRpdGlvbmFsIGNvbW1lbnRzIG9uIHJlZmVyLWNsYXJpZmljYXRpb25zIG9yIHJlZmVyLWV4cGxp Y2l0LXN1YnNjcmlwdGlvbiwgc28gd2Ugd2lsbCBiZWdpbiBwcmVwYXJpbmcgdGhlbSBmb3IgSUVT RyByZXZpZXcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlthcyBhdXRob3JdPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkEgbmV3IHZlcnNpb24gdGhhdCBJIGJlbGlldmUgYWRk cmVzc2VzIHRoZSBvdXRzdGFuZGluZyBjb21tZW50cyBvbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjY2NjUgY2xhcmlmaWNhdGlvbiBkb2N1bWVudCBpcyBhdmFp bGFibGUgaGVyZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaXBjb3JlLTY2NjUtY2xhcmlm aWNhdGlvbi8iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpu b25lIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNpcGNvcmUt NjY2NS1jbGFyaWZpY2F0aW9uLzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPkl2byAvIEJyZXR0OiBhcyB5b3Ugd2VyZSB0aGUgcGVvcGxlIHdobyBwcm92aWRlZCB0aGUg ZmVlZGJhY2sgdGhhdCBJJ3ZlIGluY29ycG9yYXRlZCwgcGxlYXNlIGxvb2sgb3ZlciB0aGlzIGxh dGVzdCB0ZXh0IHRvIGxldCBtZSBrbm93IHdoZXRoZXIgaXQgYWRkcmVzc2VzIHRoZSBzcGVjaWZp YyBjb25jZXJuIHRoYXQgaGFkIGJlZW4gcmFpc2VkLiBUaGFua3MhPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPi9hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_39B5E4D390E9BD4890E2B310790061011284CCB1ESESSMB301erics_-- From nobody Thu Mar 19 06:29:12 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D99B1A8A12 for ; Thu, 19 Mar 2015 06:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OW8Gg-nhcErB for ; Thu, 19 Mar 2015 06:29:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E201A005D for ; Thu, 19 Mar 2015 06:29:08 -0700 (PDT) Received: from unnumerable-2.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t2JDT7Vu018338 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Mar 2015 08:29:07 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable-2.local Message-ID: <550ACF1E.4030504@nostrum.com> Date: Thu, 19 Mar 2015 08:29:02 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: marianne.mohali@orange.com, "sipcore@ietf.org" References: <12455_1426352317_550468BD_12455_2010_1_8B970F90C584EA4E97D5BAAC9172DBB814318AE6@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <12455_1426352317_550468BD_12455_2010_1_8B970F90C584EA4E97D5BAAC9172DBB814318AE6@PEXCVZYM12.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------060703050307090109080005" Archived-At: Subject: Re: [sipcore] Comment on draft-ietf-sipcore-refer-explicit-subscription-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 13:29:11 -0000 This is a multi-part message in MIME format. --------------060703050307090109080005 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Marianne - You point to an interesting edge, and the explicit MUST NOT requirements you suggest are not in the current text. I don't think they need to be. If you look at "what breaks if someone does these things", I don't believe anything does. An agent sending a REFER with the nosub tag is saying "You don't need to keep state to serve subscriptions from me". If the recipient decides for whatever reason that it wants to keep that state anyhow, who is harmed? Nothing breaks. If it returns a Refer-Events-At header and something subscribes to what's there, what harm comes from allowing the subscription? The important part was that the recipient knows its ok to _not_ keep that state, and not return a Refer-Events-At header. We could add text saying MUST NOT include the header in this case, but what good would that do? Now the case you point out where something tries to send a SUBSCRIBE without having the equivalent of a URI from a Refer-Events-At URI is one of those things where something's acting out of protocol, and it could happen before this extension. Really the only thing that could happen is that someone tries to send a SUBSCRIBE in dialog, or out of dialog to the AoR or current remote-target, or just guessing random URIs. We already have a MUST NOT covering in-dialog. The out-of-dialog cases are covered by the exception cases at 6665 (an event server not holding state matching the subscription will reject it). The risk of someone guessing a valid URI to subscribe to is discussed in the security considerations section. So, again, it's an interesting edge, but I don't think we need to add requirements around it. RjS On 3/14/15 11:58 AM, marianne.mohali@orange.com wrote: > > Hello, > > I did a late review of draft-ietf-sipcore-refer-clarifications-03 and > draft-ietf-sipcore-refer-explicit-subscription-01. > > I’m fine with those drafts but I just have one comment on > draft-ietf-sipcore-refer-explicit-subscription-01 and I prefer to do > it before its publication: > > On this draft it is clearly stated for the ‘explicitsub’ option tag > that "The event server identified by the Refer-Events-At URI could > receive > > SUBSCRIBE requests" > > In section 5.1 : > > For the ‘nosub’ option tag, even if it is stated that “no explicit > subscription will be forthcoming”, there is no explicit statement such > as : A UA sending a REFER with the ‘nosub’ option tag MUST NOT send a > SUBSCRIBE request for that dialog. > > Maybe you consider, this situation cannot appear as this UA will not > receive the event server URI in the Refer-Event-At? > > In that case, I think it would be good to have the following statements: > > -in section 5.2:If the UA receives a 2xx-class response, it will not > contain a Refer-Events-At header field. > > and > > -in section 5.3: An element that accepts a REFER request with ’nosub’ > in its Require header field MUST return a 200 response that MUST NOT > contain a URI that could be used to subscribe to the refer event state > associated with this REFER request. > > It is also possible that I missed something already mentioned in the > draft. > > If not, I think a statement like that could reinforce the correct > usage of the ‘nosub’ option tag. > > Sorry about this very late comment. > > Kind regards, > > Marianne Mohali > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. --------------060703050307090109080005 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Marianne -

You point to an interesting edge, and the explicit MUST NOT requirements you suggest are not in the current text.

I don't think they need to be.

If you look at "what breaks if someone does these things", I don't believe anything does.

An agent sending a REFER with the nosub tag is saying "You don't need to keep state to serve subscriptions from me".
If the recipient decides for whatever reason that it wants to keep that state anyhow, who is harmed? Nothing breaks.
If it returns a Refer-Events-At header and something subscribes to what's there, what harm comes from allowing the
subscription?

The important part was that the recipient knows its ok to _not_ keep that state, and not return a Refer-Events-At header.
We could add text saying MUST NOT include the header in this case, but what good would that do?

Now the case you point out where something tries to send a SUBSCRIBE without having the equivalent of a URI from a Refer-Events-At URI is one of those things where something's acting out of protocol, and it could happen before this extension. Really the only thing that could happen is that someone tries to send a SUBSCRIBE in dialog, or out of dialog to the AoR or current remote-target, or just guessing random URIs. We already have a MUST NOT covering in-dialog. The out-of-dialog cases are covered by the exception cases at 6665 (an event server not holding state matching the subscription will reject it). The risk of someone guessing a valid URI to subscribe to is discussed in the security considerations section.

So, again, it's an interesting edge, but I don't think we need to add requirements around it.

RjS

On 3/14/15 11:58 AM, marianne.mohali@orange.com wrote:

Hello,

 

I did a late review of draft-ietf-sipcore-refer-clarifications-03 and draft-ietf-sipcore-refer-explicit-subscription-01.

I’m fine with those drafts but I just have one comment on  draft-ietf-sipcore-refer-explicit-subscription-01 and I prefer to do it before its publication:

 

On this draft it is clearly stated for the ‘explicitsub’ option tag that  "The event server identified by the Refer-Events-At URI could receive

SUBSCRIBE requests"

In section 5.1 :

For the ‘nosub’ option tag, even if it is stated that “no explicit subscription will be forthcoming”, there is no explicit statement such as : A UA sending a REFER with the ‘nosub’ option tag MUST NOT send a SUBSCRIBE request for that dialog.

 

Maybe you consider, this situation cannot appear as this UA will not receive the event server URI in the Refer-Event-At?

 

In that case, I think it would be good to have the following statements:

-       in section 5.2: If the UA receives a 2xx-class response, it will not contain a Refer-Events-At header field.

and

-       in section 5.3: An element that accepts a REFER request with ’nosub’ in its Require header field MUST return a 200 response that MUST NOT contain a URI that could be used to subscribe to the refer event state associated with this REFER request.

 

It is also possible that I missed something already mentioned in the draft.

If not, I think a statement like that could reinforce the correct usage of the ‘nosub’ option tag.

 

Sorry about this very late comment.

 

Kind regards,

Marianne Mohali

 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------060703050307090109080005-- From nobody Fri Mar 20 14:06:30 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7001A9024 for ; Fri, 20 Mar 2015 14:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diL2hWqzTWgD for ; Fri, 20 Mar 2015 14:06:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06B61A88C8 for ; Fri, 20 Mar 2015 14:06:28 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t2KL6KAW012738 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Mar 2015 16:06:22 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <550C6BB9.2020905@nostrum.com> Date: Fri, 20 Mar 2015 11:49:29 -0700 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Christer Holmberg , Ivo Sedlacek , "'SIPCORE'" , Brett Tate References: <54DA3735.30807@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D6C9D62@ESESSMB209.ericsson.se> <54F106F1.90302@nostrum.com>, <39B5E4D390E9BD4890E2B3107900610112831FC8@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D766E5E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D766E5E@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Concluded: WGLC / Call for Adoption: REFER-related work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 21:06:30 -0000 [as chair] On 3/17/15 10:25, Christer Holmberg wrote: > What is the status of this? The current plan is to progress all three documents at once. We got some late comments on the explicit subscription document. The document author has responded, and I'm giving potentially interested parties a few more days to weigh in on the topic. Due to the upcoming busier-than-normal week, I plan to assign a shepherd to the three documents shortly after the Dallas meeting. Barring any surprises, I expect that all three documents will be sent to the IESG in early April. /a From nobody Fri Mar 20 14:07:01 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A6E1A88C8 for ; Fri, 20 Mar 2015 14:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.044 X-Spam-Level: X-Spam-Status: No, score=-0.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_LOLITA1=1.865, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cbowbSuiCMs for ; Fri, 20 Mar 2015 14:06:58 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE231A88A6 for ; Fri, 20 Mar 2015 14:06:58 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t2KL6pVr012794 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Mar 2015 16:06:52 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <550C8BED.7020809@nostrum.com> Date: Fri, 20 Mar 2015 16:06:53 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ivo Sedlacek , Christer Holmberg , "'SIPCORE'" , Brett Tate References: <54DA3735.30807@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D6C9D62@ESESSMB209.ericsson.se> <54F106F1.90302@nostrum.com>, <39B5E4D390E9BD4890E2B3107900610112831FC8@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D766E5E@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B310790061011284CCB1@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B310790061011284CCB1@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------040404000006050305010900" Archived-At: Subject: Re: [sipcore] Concluded: WGLC / Call for Adoption: REFER-related work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 21:07:00 -0000 This is a multi-part message in MIME format. --------------040404000006050305010900 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit [as document editor] Thanks. I've seen the feedback, but don't currently plan to incorporate it. The comment is strictly editorial (an area over which document editors are given significant latitude), and -- in my opinion -- is not an improvement. It says the same thing, with equivalent clarity, using more words. /a On 3/19/15 01:36, Ivo Sedlacek wrote: > > Hello, > > my comment > (http://www.ietf.org/mail-archive/web/sipcore/current/msg06561.html) > has not been addressed yet. > > Kind regards > > Ivo Sedlacek > > This Communication is Confidential. We only send and receive email on > the basis of the terms set out at www.ericsson.com/email_disclaimer > > > *From:*Christer Holmberg > *Sent:* 17. března 2015 18:25 > *To:* Ivo Sedlacek; Adam Roach; 'SIPCORE'; Brett Tate > *Subject:* RE: Concluded: WGLC / Call for Adoption: REFER-related work > > Hi, > > What is the status of this? Has Ivo's comment been addressed? > > Regards, > > Christer > > Sent from my Windows Phone > > ------------------------------------------------------------------------ > > *From: *Ivo Sedlacek > *Sent: *‎04/‎03/‎2015 10:11 > *To: *Adam Roach ; Christer Holmberg > ; 'SIPCORE' > ; Brett Tate > *Subject: *RE: Concluded: WGLC / Call for Adoption: REFER-related work > > Hello, > > I reviewed draft-ietf-sipcore-refer-clarifications-03 and > draft-ietf-sipcore-refer-explicit-subscription-00 and found no > issues. OK to progress those drafts. > > I reviewed draft-ietf-sipcore-6665-clarification-00 and sent a comment > to the SIPCORE list yesterday > (http://www.ietf.org/mail-archive/web/sipcore/current/msg06561.html). > I prefer the comment being addressed before progressing the draft. > > Kind regards > > Ivo Sedlacek > > This Communication is Confidential. We only send and receive email on > the basis of the terms set out at www.ericsson.com/email_disclaimer > > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: 28. února 2015 1:08 > To: Christer Holmberg; 'SIPCORE'; Ivo Sedlacek; Brett Tate > Subject: Concluded: WGLC / Call for Adoption: REFER-related work > > [as chair] > > The adoption and WGLC period for the three documents has ended. Given > the expressed support (meager as it was) and lack of objection, we're > going to consider the 6665-clarifications draft adopted. > > There were no additional comments on refer-clarifications or > refer-explicit-subscription, so we will begin preparing them for IESG > review. > > [as author] > > A new version that I believe addresses the outstanding comments on the > > 6665 clarification document is available here: > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-6665-clarification/ > > Ivo / Brett: as you were the people who provided the feedback that > I've incorporated, please look over this latest text to let me know > whether it addresses the specific concern that had been raised. Thanks! > > /a > --------------040404000006050305010900 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
[as document editor]

Thanks. I've seen the feedback, but don't currently plan to incorporate it. The comment is strictly editorial (an area over which document editors are given significant latitude), and -- in my opinion -- is not an improvement. It says the same thing, with equivalent clarity, using more words.

/a

On 3/19/15 01:36, Ivo Sedlacek wrote:

Hello,

 

my comment (http://www.ietf.org/mail-archive/web/sipcore/current/msg06561.html) has not been addressed yet.

 

Kind regards

 

Ivo Sedlacek

 

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Christer Holmberg
Sent: 17. března 2015 18:25
To: Ivo Sedlacek; Adam Roach; 'SIPCORE'; Brett Tate
Subject: RE: Concluded: WGLC / Call for Adoption: REFER-related work

 

Hi,

What is the status of this? Has Ivo's comment been addressed?

Regards,

Christer

Sent from my Windows Phone

From: Ivo Sedlacek
Sent: ‎04/‎03/‎2015 10:11
To: Adam Roach; Christer Holmberg; 'SIPCORE'; Brett Tate
Subject: RE: Concluded: WGLC / Call for Adoption: REFER-related work

Hello,

 

I reviewed draft-ietf-sipcore-refer-clarifications-03 and draft-ietf-sipcore-refer-explicit-subscription-00  and found no issues. OK to progress those drafts.

I reviewed draft-ietf-sipcore-6665-clarification-00 and sent a comment to the SIPCORE list yesterday (http://www.ietf.org/mail-archive/web/sipcore/current/msg06561.html). I prefer the comment being addressed before progressing the draft.

Kind regards

Ivo Sedlacek

 

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

 

-----Original Message-----
From: Adam Roach [mailto:adam@nostrum.com]
Sent: 28. února 2015 1:08
To: Christer Holmberg; 'SIPCORE'; Ivo Sedlacek; Brett Tate
Subject: Concluded: WGLC / Call for Adoption: REFER-related work

 

[as chair]

 

The adoption and WGLC period for the three documents has ended. Given the expressed support (meager as it was) and lack of objection, we're going to consider the 6665-clarifications draft adopted.

 

There were no additional comments on refer-clarifications or refer-explicit-subscription, so we will begin preparing them for IESG review.

 

[as author]

 

A new version that I believe addresses the outstanding comments on the

6665 clarification document is available here:

 

https://datatracker.ietf.org/doc/draft-ietf-sipcore-6665-clarification/

 

Ivo / Brett: as you were the people who provided the feedback that I've incorporated, please look over this latest text to let me know whether it addresses the specific concern that had been raised. Thanks!

 

/a


--------------040404000006050305010900-- From nobody Sun Mar 22 23:59:40 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BB71A88F1 for ; Sun, 22 Mar 2015 23:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_LOLITA1=1.865, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pwZWKnBzwF8 for ; Sun, 22 Mar 2015 23:59:36 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7939B1A88EE for ; Sun, 22 Mar 2015 23:59:35 -0700 (PDT) X-AuditID: c1b4fb30-f79996d000006ebb-37-550fb9d542c2 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 17.6F.28347.5D9BF055; Mon, 23 Mar 2015 07:59:33 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.84]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0210.002; Mon, 23 Mar 2015 07:59:32 +0100 From: Ivo Sedlacek To: Adam Roach , Christer Holmberg , 'SIPCORE' , Brett Tate Thread-Topic: Concluded: WGLC / Call for Adoption: REFER-related work Thread-Index: AQHQY1HKTXEbTKhEoEOcf+CASivOgZ0ppWtQ Date: Mon, 23 Mar 2015 06:59:31 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061011284F1FD@ESESSMB301.ericsson.se> References: <54DA3735.30807@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D6C9D62@ESESSMB209.ericsson.se> <54F106F1.90302@nostrum.com>, <39B5E4D390E9BD4890E2B3107900610112831FC8@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D766E5E@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B310790061011284CCB1@ESESSMB301.ericsson.se> <550C8BED.7020809@nostrum.com> In-Reply-To: <550C8BED.7020809@nostrum.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061011284F1FDESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3RvfqTv5Qg4tb1Cz2/F3EbtE8/x+j xdcfm9gcmD1+3A70WLLkJ5PHrJ1PWAKYo7hsUlJzMstSi/TtErgyfn5fyFIwaztjxfUO2QbG NZsYuxg5OSQETCRuPd3NBmGLSVy4tx7I5uIQEjjCKHG7v5EFwlnMKLF//RxmkCo2AT2JiVuO sIIkRARmMkosfd3GApIQFnCReHziG9goEQFXiS27vzNB2EYSd3fcZwexWQRUJTZ0LQezeQV8 JTZve8gIseEbk8THP+dZQRKcAtoSx47vAhvEKCArcfVPL9itzALiEreezGeCuFVAYsme88wQ tqjEy8f/WCFsRYmdZ9uZIerzJT4ufMwEsUxQ4uTMJywTGEVmIRk1C0nZLCRlsxg5gOKaEut3 6UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0Vo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmC8Hdzy 22AH48vnjocYBTgYlXh4NzTyhwqxJpYVV+YeYpTmYFES57UzPhQiJJCeWJKanZpakFoUX1Sa k1p8iJGJg1OqgVFpQr38zf1n9m6cp/vdgMWI+8gKvY8nb+w7Mdn0b1z3Z1mFIrnsrJLTVRty l6yb0Tx/9dH77keqF7+be+GuxS/3MNZ3d9mPiZd+29YsYiqU9VMgpC/TY0JIza5PSjx37H/1 GNXnZVw0PPEzOvjW3YNXV//2Mlxc3zcxfEHtlvpH+vzXSiwvBBUrsRRnJBpqMRcVJwIABjR9 IJgCAAA= Archived-At: Subject: Re: [sipcore] Concluded: WGLC / Call for Adoption: REFER-related work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 06:59:39 -0000 --_000_39B5E4D390E9BD4890E2B310790061011284F1FDESESSMB301erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCj4gVGhlIGNvbW1lbnQgaXMgc3RyaWN0bHkgZWRpdG9yaWFsIChhbiBhcmVhIG92 ZXIgd2hpY2ggZG9jdW1lbnQgZWRpdG9ycyBhcmUgZ2l2ZW4gc2lnbmlmaWNhbnQgbGF0aXR1ZGUp LCBhbmQgLS0gaW4gbXkgb3BpbmlvbiAtLSBpcyBub3QgYW4gaW1wcm92ZW1lbnQuDQo+IEl0IHNh eXMgdGhlIHNhbWUgdGhpbmcsIHdpdGggZXF1aXZhbGVudCBjbGFyaXR5LCB1c2luZyBtb3JlIHdv cmRzLg0KDQpJcyB0aGVyZSBhbnkgZGVmaW5pdGlvbiBvZiB3aGF0ICJzdWJzY3JpcHRpb24gcmVx dWVzdHMgKGltcGxpY2l0IG9yIGV4cGxpY2l0KSIgYXJlPw0KDQppZiBubywgdGhlbiB3b3JkaW5n ICJyZXF1ZXN0cyB0aGF0IG1pZ2h0IGNyZWF0ZSBhbiAoaW1wbGljaXQgb3IgZXhwbGljaXQpIHN1 YnNjcmlwdGlvbiIgaXMgbW9yZSBwcmVjaXNlLg0KDQpJbiBhbnkgY2FzZSwgdGhlIHdvcmRpbmcg KCJyZXF1ZXN0IHRoYXQgbWlnaHQgY3JlYXRlIGEgc3Vic2NyaXB0aW9uIikgaXMgdXNlZCBlbHNl d2hlcmUgaW4gdGhlIGRvY3VtZW50IHNvIGNoYW5nZSB3b3VsZCBtYWtlIHRoZSB0ZXh0IGNvbnNp c3RlbnQuDQoNCktpbmQgcmVnYXJkcw0KDQpJdm8gU2VkbGFjZWsNCg0KVGhpcyBDb21tdW5pY2F0 aW9uIGlzIENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRo ZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdCB3d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rp c2NsYWltZXI8aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lcj4NCkZyb206 IEFkYW0gUm9hY2ggW21haWx0bzphZGFtQG5vc3RydW0uY29tXQ0KU2VudDogMjAuIGLFmWV6bmEg MjAxNSAyMjowNw0KVG86IEl2byBTZWRsYWNlazsgQ2hyaXN0ZXIgSG9sbWJlcmc7ICdTSVBDT1JF JzsgQnJldHQgVGF0ZQ0KU3ViamVjdDogUmU6IENvbmNsdWRlZDogV0dMQyAvIENhbGwgZm9yIEFk b3B0aW9uOiBSRUZFUi1yZWxhdGVkIHdvcmsNCg0KW2FzIGRvY3VtZW50IGVkaXRvcl0NCg0KVGhh bmtzLiBJJ3ZlIHNlZW4gdGhlIGZlZWRiYWNrLCBidXQgZG9uJ3QgY3VycmVudGx5IHBsYW4gdG8g aW5jb3Jwb3JhdGUgaXQuIFRoZSBjb21tZW50IGlzIHN0cmljdGx5IGVkaXRvcmlhbCAoYW4gYXJl YSBvdmVyIHdoaWNoIGRvY3VtZW50IGVkaXRvcnMgYXJlIGdpdmVuIHNpZ25pZmljYW50IGxhdGl0 dWRlKSwgYW5kIC0tIGluIG15IG9waW5pb24gLS0gaXMgbm90IGFuIGltcHJvdmVtZW50LiBJdCBz YXlzIHRoZSBzYW1lIHRoaW5nLCB3aXRoIGVxdWl2YWxlbnQgY2xhcml0eSwgdXNpbmcgbW9yZSB3 b3Jkcy4NCg0KL2ENCg0KT24gMy8xOS8xNSAwMTozNiwgSXZvIFNlZGxhY2VrIHdyb3RlOg0KSGVs bG8sDQoNCm15IGNvbW1lbnQgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9z aXBjb3JlL2N1cnJlbnQvbXNnMDY1NjEuaHRtbCkgaGFzIG5vdCBiZWVuIGFkZHJlc3NlZCB5ZXQu DQoNCktpbmQgcmVnYXJkcw0KDQpJdm8gU2VkbGFjZWsNCg0KVGhpcyBDb21tdW5pY2F0aW9uIGlz IENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNp cyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdCB3d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWlt ZXI8aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lcj4NCkZyb206IENocmlz dGVyIEhvbG1iZXJnDQpTZW50OiAxNy4gYsWZZXpuYSAyMDE1IDE4OjI1DQpUbzogSXZvIFNlZGxh Y2VrOyBBZGFtIFJvYWNoOyAnU0lQQ09SRSc7IEJyZXR0IFRhdGUNClN1YmplY3Q6IFJFOiBDb25j bHVkZWQ6IFdHTEMgLyBDYWxsIGZvciBBZG9wdGlvbjogUkVGRVItcmVsYXRlZCB3b3JrDQoNCkhp LA0KDQpXaGF0IGlzIHRoZSBzdGF0dXMgb2YgdGhpcz8gSGFzIEl2bydzIGNvbW1lbnQgYmVlbiBh ZGRyZXNzZWQ/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNClNlbnQgZnJvbSBteSBXaW5kb3dz IFBob25lDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogSXZvIFNlZGxh Y2VrPG1haWx0bzppdm8uc2VkbGFjZWtAZXJpY3Nzb24uY29tPg0KU2VudDog4oCOMDQv4oCOMDMv 4oCOMjAxNSAxMDoxMQ0KVG86IEFkYW0gUm9hY2g8bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20+OyBD aHJpc3RlciBIb2xtYmVyZzxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsg J1NJUENPUkUnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPjsgQnJldHQgVGF0ZTxtYWlsdG86YnJl dHRAYnJvYWRzb2Z0LmNvbT4NClN1YmplY3Q6IFJFOiBDb25jbHVkZWQ6IFdHTEMgLyBDYWxsIGZv ciBBZG9wdGlvbjogUkVGRVItcmVsYXRlZCB3b3JrDQoNCkhlbGxvLA0KDQoNCg0KSSByZXZpZXdl ZCBkcmFmdC1pZXRmLXNpcGNvcmUtcmVmZXItY2xhcmlmaWNhdGlvbnMtMDMgYW5kIGRyYWZ0LWll dGYtc2lwY29yZS1yZWZlci1leHBsaWNpdC1zdWJzY3JpcHRpb24tMDAgIGFuZCBmb3VuZCBubyBp c3N1ZXMuIE9LIHRvIHByb2dyZXNzIHRob3NlIGRyYWZ0cy4NCg0KSSByZXZpZXdlZCBkcmFmdC1p ZXRmLXNpcGNvcmUtNjY2NS1jbGFyaWZpY2F0aW9uLTAwIGFuZCBzZW50IGEgY29tbWVudCB0byB0 aGUgU0lQQ09SRSBsaXN0IHllc3RlcmRheSAoaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwNjU2MS5odG1sKS4gSSBwcmVmZXIgdGhlIGNvbW1l bnQgYmVpbmcgYWRkcmVzc2VkIGJlZm9yZSBwcm9ncmVzc2luZyB0aGUgZHJhZnQuDQoNCktpbmQg cmVnYXJkcw0KDQpJdm8gU2VkbGFjZWsNCg0KDQoNClRoaXMgQ29tbXVuaWNhdGlvbiBpcyBDb25m aWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2Yg dGhlIHRlcm1zIHNldCBvdXQgYXQgd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPGh0 dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI+DQoNCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5j b21dDQpTZW50OiAyOC4gw7pub3JhIDIwMTUgMTowOA0KVG86IENocmlzdGVyIEhvbG1iZXJnOyAn U0lQQ09SRSc7IEl2byBTZWRsYWNlazsgQnJldHQgVGF0ZQ0KU3ViamVjdDogQ29uY2x1ZGVkOiBX R0xDIC8gQ2FsbCBmb3IgQWRvcHRpb246IFJFRkVSLXJlbGF0ZWQgd29yaw0KDQoNCg0KW2FzIGNo YWlyXQ0KDQoNCg0KVGhlIGFkb3B0aW9uIGFuZCBXR0xDIHBlcmlvZCBmb3IgdGhlIHRocmVlIGRv Y3VtZW50cyBoYXMgZW5kZWQuIEdpdmVuIHRoZSBleHByZXNzZWQgc3VwcG9ydCAobWVhZ2VyIGFz IGl0IHdhcykgYW5kIGxhY2sgb2Ygb2JqZWN0aW9uLCB3ZSdyZSBnb2luZyB0byBjb25zaWRlciB0 aGUgNjY2NS1jbGFyaWZpY2F0aW9ucyBkcmFmdCBhZG9wdGVkLg0KDQoNCg0KVGhlcmUgd2VyZSBu byBhZGRpdGlvbmFsIGNvbW1lbnRzIG9uIHJlZmVyLWNsYXJpZmljYXRpb25zIG9yIHJlZmVyLWV4 cGxpY2l0LXN1YnNjcmlwdGlvbiwgc28gd2Ugd2lsbCBiZWdpbiBwcmVwYXJpbmcgdGhlbSBmb3Ig SUVTRyByZXZpZXcuDQoNCg0KDQpbYXMgYXV0aG9yXQ0KDQoNCg0KQSBuZXcgdmVyc2lvbiB0aGF0 IEkgYmVsaWV2ZSBhZGRyZXNzZXMgdGhlIG91dHN0YW5kaW5nIGNvbW1lbnRzIG9uIHRoZQ0KDQo2 NjY1IGNsYXJpZmljYXRpb24gZG9jdW1lbnQgaXMgYXZhaWxhYmxlIGhlcmU6DQoNCg0KDQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNpcGNvcmUtNjY2NS1jbGFy aWZpY2F0aW9uLw0KDQoNCg0KSXZvIC8gQnJldHQ6IGFzIHlvdSB3ZXJlIHRoZSBwZW9wbGUgd2hv IHByb3ZpZGVkIHRoZSBmZWVkYmFjayB0aGF0IEkndmUgaW5jb3Jwb3JhdGVkLCBwbGVhc2UgbG9v ayBvdmVyIHRoaXMgbGF0ZXN0IHRleHQgdG8gbGV0IG1lIGtub3cgd2hldGhlciBpdCBhZGRyZXNz ZXMgdGhlIHNwZWNpZmljIGNvbmNlcm4gdGhhdCBoYWQgYmVlbiByYWlzZWQuIFRoYW5rcyENCg0K DQoNCi9hDQoNCg== --_000_39B5E4D390E9BD4890E2B310790061011284F1FDESESSMB301erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4gXCwgc2VyaWYiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxh aW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRh dGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5QbGFpblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6Q29uc29s YXM7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAubXNvY2hw ZGVmYXVsdCwgbGkubXNvY2hwZGVmYXVsdCwgZGl2Lm1zb2NocGRlZmF1bHQNCgl7bXNvLXN0eWxl LW5hbWU6bXNvY2hwZGVmYXVsdDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBj bTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5wbGFpbnRleHRjaGFyMA0KCXttc28tc3R5bGUtbmFt ZTpwbGFpbnRleHRjaGFyOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojOTg0ODA2O30NCnNwYW4uRW1haWxT dHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Izk4NDgwNjt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk4NDgwNiI+SGVsbG8sPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiM5ODQ4MDYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTg0ODA2Ij4mZ3Q7IDwvc3Bhbj5UaGUgY29tbWVudCBp cyBzdHJpY3RseSBlZGl0b3JpYWwgKGFuIGFyZWEgb3ZlciB3aGljaCBkb2N1bWVudCBlZGl0b3Jz IGFyZSBnaXZlbiBzaWduaWZpY2FudCBsYXRpdHVkZSksIGFuZCAtLSBpbiBteSBvcGluaW9uIC0t IGlzIG5vdCBhbiBpbXByb3ZlbWVudC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmd0OyBJdCBzYXlzIHRoZSBzYW1lIHRoaW5nLCB3aXRoIGVxdWl2YWxlbnQgY2xhcml0 eSwgdXNpbmcgbW9yZSB3b3Jkcy48c3BhbiBzdHlsZT0iY29sb3I6Izk4NDgwNiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5 ODQ4MDYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojOTg0ODA2Ij5JcyB0aGVyZSBhbnkgZGVmaW5pdGlvbiBvZiB3 aGF0ICZxdW90O3N1YnNjcmlwdGlvbiByZXF1ZXN0cyAoaW1wbGljaXQgb3IgZXhwbGljaXQpJnF1 b3Q7IGFyZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6Izk4NDgwNiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5ODQ4MDYiPmlmIG5vLCB0aGVu IHdvcmRpbmcgJnF1b3Q7cmVxdWVzdHMgdGhhdCBtaWdodCBjcmVhdGUgYW4gKGltcGxpY2l0IG9y IGV4cGxpY2l0KSBzdWJzY3JpcHRpb24mcXVvdDsgaXMgbW9yZSBwcmVjaXNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTg0 ODA2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6Izk4NDgwNiI+SW4gYW55IGNhc2UsIHRoZSB3b3JkaW5nICgmcXVv dDtyZXF1ZXN0IHRoYXQgbWlnaHQgY3JlYXRlIGEgc3Vic2NyaXB0aW9uJnF1b3Q7KSBpcyB1c2Vk IGVsc2V3aGVyZSBpbiB0aGUgZG9jdW1lbnQgc28gY2hhbmdlIHdvdWxkIG1ha2UgdGhlIHRleHQg Y29uc2lzdGVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6Izk4NDgwNiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5ODQ4MDYiPktpbmQgcmVn YXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojOTg0ODA2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk4NDgwNiI+SXZvIFNlZGxhY2VrPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiM5ODQ4MDYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzMzMzIj5UaGlzIENvbW11 bmljYXRpb24gaXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwg b24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0DQo8YSBocmVmPSJodHRwOi8vd3d3 LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyIiB0aXRsZT0iaHR0cDovL3d3dy5lcmljc3Nv bi5jb20vZW1haWxfZGlzY2xhaW1lciI+DQp3d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWlt ZXI8L2E+IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IEFkYW0gUm9hY2ggW21haWx0bzphZGFtQG5vc3RydW0u Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDIwLiBixZllem5hIDIwMTUgMjI6MDc8YnI+DQo8Yj5U bzo8L2I+IEl2byBTZWRsYWNlazsgQ2hyaXN0ZXIgSG9sbWJlcmc7ICdTSVBDT1JFJzsgQnJldHQg VGF0ZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQ29uY2x1ZGVkOiBXR0xDIC8gQ2FsbCBmb3Ig QWRvcHRpb246IFJFRkVSLXJlbGF0ZWQgd29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bYXMgZG9jdW1lbnQgZWRpdG9yXTxicj4NCjxicj4N ClRoYW5rcy4gSSd2ZSBzZWVuIHRoZSBmZWVkYmFjaywgYnV0IGRvbid0IGN1cnJlbnRseSBwbGFu IHRvIGluY29ycG9yYXRlIGl0LiBUaGUgY29tbWVudCBpcyBzdHJpY3RseSBlZGl0b3JpYWwgKGFu IGFyZWEgb3ZlciB3aGljaCBkb2N1bWVudCBlZGl0b3JzIGFyZSBnaXZlbiBzaWduaWZpY2FudCBs YXRpdHVkZSksIGFuZCAtLSBpbiBteSBvcGluaW9uIC0tIGlzIG5vdCBhbiBpbXByb3ZlbWVudC4g SXQgc2F5cyB0aGUgc2FtZSB0aGluZywgd2l0aCBlcXVpdmFsZW50DQogY2xhcml0eSwgdXNpbmcg bW9yZSB3b3Jkcy48YnI+DQo8YnI+DQovYTxicj4NCjxicj4NCk9uIDMvMTkvMTUgMDE6MzYsIEl2 byBTZWRsYWNlayB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk4NDgwNiI+SGVsbG8sPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5ODQ4MDYi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojOTg0ODA2Ij5teSBjb21tZW50IDwvc3Bhbj4oPGEgaHJlZj0iaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwNjU2MS5o dG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50 L21zZzA2NTYxLmh0bWw8L2E+KQ0KPHNwYW4gc3R5bGU9ImNvbG9yOiM5ODQ4MDYiPmhhcyBub3Qg YmVlbiBhZGRyZXNzZWQgeWV0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTg0ODA2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk4NDgwNiI+ S2luZCByZWdhcmRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM5ODQ4MDYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTg0ODA2Ij5Jdm8gU2Vk bGFjZWs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6Izk4NDgwNiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzMzMzMiPlRo aXMgQ29tbXVuaWNhdGlvbiBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2 ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQNCjxhIGhyZWY9Imh0 dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXIiIHRpdGxlPSJodHRwOi8vd3d3 LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyIj4NCnd3dy5lcmljc3Nvbi5jb20vZW1haWxf ZGlzY2xhaW1lcjwvYT4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBD aHJpc3RlciBIb2xtYmVyZw0KPGJyPg0KPGI+U2VudDo8L2I+IDE3LiBixZllem5hIDIwMTUgMTg6 MjU8YnI+DQo8Yj5Ubzo8L2I+IEl2byBTZWRsYWNlazsgQWRhbSBSb2FjaDsgJ1NJUENPUkUnOyBC cmV0dCBUYXRlPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBDb25jbHVkZWQ6IFdHTEMgLyBDYWxs IGZvciBBZG9wdGlvbjogUkVGRVItcmVsYXRlZCB3b3JrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8YnI+DQo8YnI+DQpXaGF0 IGlzIHRoZSBzdGF0dXMgb2YgdGhpcz8gSGFzIEl2bydzIGNvbW1lbnQgYmVlbiBhZGRyZXNzZWQ/ PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpDaHJpc3Rlcjxicj4NCjxicj4NClNlbnQg ZnJvbSBteSBXaW5kb3dzIFBob25lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxp Z246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4gLCBzZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+DQo8aHIg c2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj5Gcm9tOiA8 L2I+PGEgaHJlZj0ibWFpbHRvOml2by5zZWRsYWNla0Blcmljc3Nvbi5jb20iPkl2byBTZWRsYWNl azwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4gLCBzZXJpZiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFu PjxiPlNlbnQ6IDwvYj7igI4wNC/igI4wMy/igI4yMDE1IDEwOjExPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuICwgc2VyaWYmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48Yj5UbzogPC9iPjxhIGhyZWY9Im1h aWx0bzphZGFtQG5vc3RydW0uY29tIj5BZGFtIFJvYWNoPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+DQpDaHJpc3RlciBIb2xtYmVyZzwvYT47IDxh IGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj4nU0lQQ09SRSc8L2E+OyA8YSBocmVmPSJt YWlsdG86YnJldHRAYnJvYWRzb2Z0LmNvbSI+DQpCcmV0dCBUYXRlPC9hPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiAsIHNlcmlm JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGI+U3ViamVjdDogPC9iPlJF OiBDb25jbHVkZWQ6IFdHTEMgLyBDYWxsIGZvciBBZG9wdGlvbjogUkVGRVItcmVsYXRlZCB3b3Jr PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+SGVsbG8sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgcmV2aWV3ZWQgZHJh ZnQtaWV0Zi1zaXBjb3JlLXJlZmVyLWNsYXJpZmljYXRpb25zLTAzIGFuZCBkcmFmdC1pZXRmLXNp cGNvcmUtcmVmZXItZXhwbGljaXQtc3Vic2NyaXB0aW9uLTAwJm5ic3A7IGFuZCBmb3VuZCBubyBp c3N1ZXMuIE9LIHRvIHByb2dyZXNzIHRob3NlIGRyYWZ0cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkkgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1zaXBjb3JlLTY2NjUtY2xh cmlmaWNhdGlvbi0wMCBhbmQgc2VudCBhIGNvbW1lbnQgdG8gdGhlIFNJUENPUkUgbGlzdCB5ZXN0 ZXJkYXkgKDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBj b3JlL2N1cnJlbnQvbXNnMDY1NjEuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwNjU2MS5odG1sPC9hPikuDQogSSBwcmVmZXIgdGhl IGNvbW1lbnQgYmVpbmcgYWRkcmVzc2VkIGJlZm9yZSBwcm9ncmVzc2luZyB0aGUgZHJhZnQuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5LaW5kIHJlZ2FyZHM8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkl2byBTZWRsYWNlayA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhpcyBDb21tdW5pY2F0aW9uIGlzIENvbmZpZGVudGlhbC4g V2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMg c2V0IG91dCBhdA0KPGEgaHJlZj0iaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xh aW1lciI+d3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPC9hPg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTog QWRhbSBSb2FjaCBbPGEgaHJlZj0ibWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20iPm1haWx0bzphZGFt QG5vc3RydW0uY29tPC9hPl0gPGJyPg0KU2VudDogMjguIMO6bm9yYSAyMDE1IDE6MDg8YnI+DQpU bzogQ2hyaXN0ZXIgSG9sbWJlcmc7ICdTSVBDT1JFJzsgSXZvIFNlZGxhY2VrOyBCcmV0dCBUYXRl PGJyPg0KU3ViamVjdDogQ29uY2x1ZGVkOiBXR0xDIC8gQ2FsbCBmb3IgQWRvcHRpb246IFJFRkVS LXJlbGF0ZWQgd29yazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5bYXMgY2hhaXJdPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBhZG9wdGlvbiBhbmQgV0dMQyBwZXJpb2Qg Zm9yIHRoZSB0aHJlZSBkb2N1bWVudHMgaGFzIGVuZGVkLiBHaXZlbiB0aGUgZXhwcmVzc2VkIHN1 cHBvcnQgKG1lYWdlciBhcyBpdCB3YXMpIGFuZCBsYWNrIG9mIG9iamVjdGlvbiwgd2UncmUgZ29p bmcgdG8gY29uc2lkZXIgdGhlIDY2NjUtY2xhcmlmaWNhdGlvbnMgZHJhZnQgYWRvcHRlZC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlcmUgd2VyZSBubyBhZGRpdGlvbmFsIGNvbW1l bnRzIG9uIHJlZmVyLWNsYXJpZmljYXRpb25zIG9yIHJlZmVyLWV4cGxpY2l0LXN1YnNjcmlwdGlv biwgc28gd2Ugd2lsbCBiZWdpbiBwcmVwYXJpbmcgdGhlbSBmb3IgSUVTRyByZXZpZXcuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlthcyBhdXRob3JdPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkEgbmV3IHZlcnNpb24gdGhhdCBJIGJlbGlldmUgYWRkcmVzc2VzIHRoZSBvdXRz dGFuZGluZyBjb21tZW50cyBvbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjY2NjUgY2xhcmlmaWNhdGlvbiBkb2N1bWVudCBpcyBhdmFpbGFibGUgaGVyZTo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaXBjb3JlLTY2NjUtY2xhcmlmaWNhdGlvbi8iPjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNpcGNvcmUtNjY2NS1jbGFyaWZpY2F0 aW9uLzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkl2byAvIEJyZXR0 OiBhcyB5b3Ugd2VyZSB0aGUgcGVvcGxlIHdobyBwcm92aWRlZCB0aGUgZmVlZGJhY2sgdGhhdCBJ J3ZlIGluY29ycG9yYXRlZCwgcGxlYXNlIGxvb2sgb3ZlciB0aGlzIGxhdGVzdCB0ZXh0IHRvIGxl dCBtZSBrbm93IHdoZXRoZXIgaXQgYWRkcmVzc2VzIHRoZSBzcGVjaWZpYyBjb25jZXJuIHRoYXQg aGFkIGJlZW4gcmFpc2VkLiBUaGFua3MhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9h PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_39B5E4D390E9BD4890E2B310790061011284F1FDESESSMB301erics_-- From nobody Mon Mar 23 03:03:37 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1991A1EF3 for ; Mon, 23 Mar 2015 03:03:36 -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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVYuXQW4Dtkc for ; Mon, 23 Mar 2015 03:03:35 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DDFC1A1EF7 for ; Mon, 23 Mar 2015 03:03:35 -0700 (PDT) Received: by qcbjx9 with SMTP id jx9so101650417qcb.0 for ; Mon, 23 Mar 2015 03:03:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=f3w/emFKJHMK5kuzzKFH9PucE+pzO0UmDjzuYbt+JkQ=; b=bqX3R7lAF1w5YGkYJlDXiIsOweRhTVzkKns+URqVGSFCHBeDH0on1/0m2leATKTiSp Xc8WoR7IQ/2b4+IUJpnc8AN8EZAqI85b9ce7sC5k905bmXLfUNLuym6+xTzORu8zkrQI CnXRhZRcSVTfj95rNcPv8I/5zpna8ij4oC5IKhwZNpkFAlRxYtAPa1ZtJi7x1U9hYzpz m+zIBVPiHYNmDVTnJusfxuhFBkxXDEUzb6uqOVf6pbDkmdBhVEemTY/YvznWgrlvRZQD X0TFc9Ok6GwhHSX68I6BbPZCetc2aB2bFknyqJdDUFQ2gQdRr3VPDe0y9t9gsdxiDjWd g6Ew== X-Gm-Message-State: ALoCoQmRk1FrpRB01wfkBi4N5r2MH8zy9yf8loI6KLBBlkoYXHcH8sLaMs9C3HozQbLxlacMOKex X-Received: by 10.140.234.142 with SMTP id f136mr106842114qhc.13.1427105014216; Mon, 23 Mar 2015 03:03:34 -0700 (PDT) From: Brett Tate References: <54DA3735.30807@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D6C9D62@ESESSMB209.ericsson.se> <54F106F1.90302@nostrum.com>, <39B5E4D390E9BD4890E2B3107900610112831FC8@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D766E5E@ESESSMB209.ericsson.se> <550C6BB9.2020905@nostrum.com> In-Reply-To: <550C6BB9.2020905@nostrum.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKZNvi/KECCMwa9/fxX28PKeJQ2qAMQs0IPAoD1FzABrsXunwFez7rrAskwOUubPO5MUA== Date: Mon, 23 Mar 2015 06:03:32 -0400 Message-ID: <88790955ca1de56a513935834836430a@mail.gmail.com> To: Adam Roach , SIPCORE Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] Concluded: WGLC / Call for Adoption: REFER-related work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 10:03:36 -0000 > On 3/17/15 10:25, Christer Holmberg wrote: > > What is the status of this? > > The current plan is to progress all three documents at once. Hi, I have not received a reply concerning my March 4 comments. http://www.ietf.org/mail-archive/web/sipcore/current/msg06565.html Are any them going to be addressed? Thanks, Brett From nobody Mon Mar 23 07:00:28 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7E41A8A76 for ; Mon, 23 Mar 2015 07:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_LOLITA1=1.865, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAM0c-3F-EH2 for ; Mon, 23 Mar 2015 07:00:24 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAEC1A8A81 for ; Mon, 23 Mar 2015 07:00:22 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-0c-55101c75a571 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EC.0A.28835.57C10155; Mon, 23 Mar 2015 15:00:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Mon, 23 Mar 2015 15:00:20 +0100 From: Christer Holmberg To: Ivo Sedlacek , Adam Roach , 'SIPCORE' , Brett Tate Thread-Topic: Concluded: WGLC / Call for Adoption: REFER-related work Thread-Index: AQHQYh/R8J28RQY1b0y/157bZrFciJ0lzpGAgAPKPoCAAIYHcA== Date: Mon, 23 Mar 2015 14:00:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D775386@ESESSMB209.ericsson.se> References: <54DA3735.30807@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D6C9D62@ESESSMB209.ericsson.se> <54F106F1.90302@nostrum.com>, <39B5E4D390E9BD4890E2B3107900610112831FC8@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D766E5E@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B310790061011284CCB1@ESESSMB301.ericsson.se> <550C8BED.7020809@nostrum.com> <39B5E4D390E9BD4890E2B310790061011284F1FD@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B310790061011284F1FD@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D775386ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3RrdURiDUYN1UUYs9fxexWzTP/8do 8fXHJjYHZo8ftwM9liz5yeQxa+cTlgDmKC6blNSczLLUIn27BK6MJbNbmAvm3Ges+Lv2BWMD 45qbjF2MnBwSAiYSZw71QtliEhfurWfrYuTiEBI4wiix/nQ7lLOEUeLKqYMsXYwcHGwCFhLd /7RB4iICvYwS/xZfBOsWFnCReHziGxuILSLgKrFl93cmCNtJYsPb/ewgNouAqsSC2ffB4rwC vhI3Nv5khFiwi1li4sEdLCAJTgE/idZJb5lBbEagk76fWgPWwCwgLnHryXwmiFMFJJbsOc8M YYtKvHz8jxXCVpJYdPszVH2+xKzPk6CWCUqcnPmEZQKjyCwko2YhKZuFpGwW0J/MApoS63fp Q5QoSkzpfsgOYWtItM6Zy44svoCRfRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYLwd3PLb agfjweeOhxgFOBiVeHg3NPKHCrEmlhVX5h5ilOZgURLntTM+FCIkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qB0T9MRWrZvYzbrealWS2vl279zHK6Y1/bgQ/vvAwuHf4/9bnxwy6l27+6BIKV Jkkv8tGqczu69uz2O7Fd/nuXB0zoj5L3fLPhKtNP8Xlb/CQ/xFceMq3mMFvjcTXKrJ9JK13D OV9epihs2eQJa2PUNq1qNVJYzn2Q+dvpMCWRa/zui78vqP/lqMRSnJFoqMVcVJwIADEtKY2Y AgAA Archived-At: Subject: Re: [sipcore] Concluded: WGLC / Call for Adoption: REFER-related work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:00:26 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D775386ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgc3VwcG9ydCBoYXZpbmcgY29uc2lzdGVudCB0ZXJtaW5vbG9neSwgYW5kIHRoZSBz dWdnZXN0ZWQgY2hhbmdlIHNlZW1zIHZlcnkgc3RyYWlnaHQgZm9yd2FyZCwgc2/igKYNCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogSXZvIFNlZGxhY2VrDQpTZW50OiAyMyBNYXJjaCAy MDE1IDA5OjAwDQpUbzogQWRhbSBSb2FjaDsgQ2hyaXN0ZXIgSG9sbWJlcmc7ICdTSVBDT1JFJzsg QnJldHQgVGF0ZQ0KU3ViamVjdDogUkU6IENvbmNsdWRlZDogV0dMQyAvIENhbGwgZm9yIEFkb3B0 aW9uOiBSRUZFUi1yZWxhdGVkIHdvcmsNCg0KSGVsbG8sDQoNCj4gVGhlIGNvbW1lbnQgaXMgc3Ry aWN0bHkgZWRpdG9yaWFsIChhbiBhcmVhIG92ZXIgd2hpY2ggZG9jdW1lbnQgZWRpdG9ycyBhcmUg Z2l2ZW4gc2lnbmlmaWNhbnQgbGF0aXR1ZGUpLCBhbmQgLS0gaW4gbXkgb3BpbmlvbiAtLSBpcyBu b3QgYW4gaW1wcm92ZW1lbnQuDQo+IEl0IHNheXMgdGhlIHNhbWUgdGhpbmcsIHdpdGggZXF1aXZh bGVudCBjbGFyaXR5LCB1c2luZyBtb3JlIHdvcmRzLg0KDQpJcyB0aGVyZSBhbnkgZGVmaW5pdGlv biBvZiB3aGF0ICJzdWJzY3JpcHRpb24gcmVxdWVzdHMgKGltcGxpY2l0IG9yIGV4cGxpY2l0KSIg YXJlPw0KDQppZiBubywgdGhlbiB3b3JkaW5nICJyZXF1ZXN0cyB0aGF0IG1pZ2h0IGNyZWF0ZSBh biAoaW1wbGljaXQgb3IgZXhwbGljaXQpIHN1YnNjcmlwdGlvbiIgaXMgbW9yZSBwcmVjaXNlLg0K DQpJbiBhbnkgY2FzZSwgdGhlIHdvcmRpbmcgKCJyZXF1ZXN0IHRoYXQgbWlnaHQgY3JlYXRlIGEg c3Vic2NyaXB0aW9uIikgaXMgdXNlZCBlbHNld2hlcmUgaW4gdGhlIGRvY3VtZW50IHNvIGNoYW5n ZSB3b3VsZCBtYWtlIHRoZSB0ZXh0IGNvbnNpc3RlbnQuDQoNCktpbmQgcmVnYXJkcw0KDQpJdm8g U2VkbGFjZWsNCg0KVGhpcyBDb21tdW5pY2F0aW9uIGlzIENvbmZpZGVudGlhbC4gV2Ugb25seSBz ZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBh dCB3d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI8aHR0cDovL3d3dy5lcmljc3Nvbi5j b20vZW1haWxfZGlzY2xhaW1lcj4NCkZyb206IEFkYW0gUm9hY2ggW21haWx0bzphZGFtQG5vc3Ry dW0uY29tXQ0KU2VudDogMjAuIGLFmWV6bmEgMjAxNSAyMjowNw0KVG86IEl2byBTZWRsYWNlazsg Q2hyaXN0ZXIgSG9sbWJlcmc7ICdTSVBDT1JFJzsgQnJldHQgVGF0ZQ0KU3ViamVjdDogUmU6IENv bmNsdWRlZDogV0dMQyAvIENhbGwgZm9yIEFkb3B0aW9uOiBSRUZFUi1yZWxhdGVkIHdvcmsNCg0K W2FzIGRvY3VtZW50IGVkaXRvcl0NCg0KVGhhbmtzLiBJJ3ZlIHNlZW4gdGhlIGZlZWRiYWNrLCBi dXQgZG9uJ3QgY3VycmVudGx5IHBsYW4gdG8gaW5jb3Jwb3JhdGUgaXQuIFRoZSBjb21tZW50IGlz IHN0cmljdGx5IGVkaXRvcmlhbCAoYW4gYXJlYSBvdmVyIHdoaWNoIGRvY3VtZW50IGVkaXRvcnMg YXJlIGdpdmVuIHNpZ25pZmljYW50IGxhdGl0dWRlKSwgYW5kIC0tIGluIG15IG9waW5pb24gLS0g aXMgbm90IGFuIGltcHJvdmVtZW50LiBJdCBzYXlzIHRoZSBzYW1lIHRoaW5nLCB3aXRoIGVxdWl2 YWxlbnQgY2xhcml0eSwgdXNpbmcgbW9yZSB3b3Jkcy4NCg0KL2ENCg0KT24gMy8xOS8xNSAwMToz NiwgSXZvIFNlZGxhY2VrIHdyb3RlOg0KSGVsbG8sDQoNCm15IGNvbW1lbnQgKGh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNnMDY1NjEuaHRtbCkg aGFzIG5vdCBiZWVuIGFkZHJlc3NlZCB5ZXQuDQoNCktpbmQgcmVnYXJkcw0KDQpJdm8gU2VkbGFj ZWsNCg0KVGhpcyBDb21tdW5pY2F0aW9uIGlzIENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5kIGFu ZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdCB3d3cu ZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI8aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1h aWxfZGlzY2xhaW1lcj4NCkZyb206IENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiAxNy4gYsWZZXpu YSAyMDE1IDE4OjI1DQpUbzogSXZvIFNlZGxhY2VrOyBBZGFtIFJvYWNoOyAnU0lQQ09SRSc7IEJy ZXR0IFRhdGUNClN1YmplY3Q6IFJFOiBDb25jbHVkZWQ6IFdHTEMgLyBDYWxsIGZvciBBZG9wdGlv bjogUkVGRVItcmVsYXRlZCB3b3JrDQoNCkhpLA0KDQpXaGF0IGlzIHRoZSBzdGF0dXMgb2YgdGhp cz8gSGFzIEl2bydzIGNvbW1lbnQgYmVlbiBhZGRyZXNzZWQ/DQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRnJvbTogSXZvIFNlZGxhY2VrPG1haWx0bzppdm8uc2VkbGFjZWtAZXJpY3Nz b24uY29tPg0KU2VudDog4oCOMDQv4oCOMDMv4oCOMjAxNSAxMDoxMQ0KVG86IEFkYW0gUm9hY2g8 bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20+OyBDaHJpc3RlciBIb2xtYmVyZzxtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgJ1NJUENPUkUnPG1haWx0bzpzaXBjb3JlQGlldGYu b3JnPjsgQnJldHQgVGF0ZTxtYWlsdG86YnJldHRAYnJvYWRzb2Z0LmNvbT4NClN1YmplY3Q6IFJF OiBDb25jbHVkZWQ6IFdHTEMgLyBDYWxsIGZvciBBZG9wdGlvbjogUkVGRVItcmVsYXRlZCB3b3Jr DQoNCkhlbGxvLA0KDQoNCg0KSSByZXZpZXdlZCBkcmFmdC1pZXRmLXNpcGNvcmUtcmVmZXItY2xh cmlmaWNhdGlvbnMtMDMgYW5kIGRyYWZ0LWlldGYtc2lwY29yZS1yZWZlci1leHBsaWNpdC1zdWJz Y3JpcHRpb24tMDAgIGFuZCBmb3VuZCBubyBpc3N1ZXMuIE9LIHRvIHByb2dyZXNzIHRob3NlIGRy YWZ0cy4NCg0KSSByZXZpZXdlZCBkcmFmdC1pZXRmLXNpcGNvcmUtNjY2NS1jbGFyaWZpY2F0aW9u LTAwIGFuZCBzZW50IGEgY29tbWVudCB0byB0aGUgU0lQQ09SRSBsaXN0IHllc3RlcmRheSAoaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwNjU2 MS5odG1sKS4gSSBwcmVmZXIgdGhlIGNvbW1lbnQgYmVpbmcgYWRkcmVzc2VkIGJlZm9yZSBwcm9n cmVzc2luZyB0aGUgZHJhZnQuDQoNCktpbmQgcmVnYXJkcw0KDQpJdm8gU2VkbGFjZWsNCg0KDQoN ClRoaXMgQ29tbXVuaWNhdGlvbiBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVj ZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQgd3d3LmVyaWNz c29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPGh0dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rp c2NsYWltZXI+DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWRhbSBS b2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21dDQpTZW50OiAyOC4gw7pub3JhIDIwMTUgMTow OA0KVG86IENocmlzdGVyIEhvbG1iZXJnOyAnU0lQQ09SRSc7IEl2byBTZWRsYWNlazsgQnJldHQg VGF0ZQ0KU3ViamVjdDogQ29uY2x1ZGVkOiBXR0xDIC8gQ2FsbCBmb3IgQWRvcHRpb246IFJFRkVS LXJlbGF0ZWQgd29yaw0KDQoNCg0KW2FzIGNoYWlyXQ0KDQoNCg0KVGhlIGFkb3B0aW9uIGFuZCBX R0xDIHBlcmlvZCBmb3IgdGhlIHRocmVlIGRvY3VtZW50cyBoYXMgZW5kZWQuIEdpdmVuIHRoZSBl eHByZXNzZWQgc3VwcG9ydCAobWVhZ2VyIGFzIGl0IHdhcykgYW5kIGxhY2sgb2Ygb2JqZWN0aW9u LCB3ZSdyZSBnb2luZyB0byBjb25zaWRlciB0aGUgNjY2NS1jbGFyaWZpY2F0aW9ucyBkcmFmdCBh ZG9wdGVkLg0KDQoNCg0KVGhlcmUgd2VyZSBubyBhZGRpdGlvbmFsIGNvbW1lbnRzIG9uIHJlZmVy LWNsYXJpZmljYXRpb25zIG9yIHJlZmVyLWV4cGxpY2l0LXN1YnNjcmlwdGlvbiwgc28gd2Ugd2ls bCBiZWdpbiBwcmVwYXJpbmcgdGhlbSBmb3IgSUVTRyByZXZpZXcuDQoNCg0KDQpbYXMgYXV0aG9y XQ0KDQoNCg0KQSBuZXcgdmVyc2lvbiB0aGF0IEkgYmVsaWV2ZSBhZGRyZXNzZXMgdGhlIG91dHN0 YW5kaW5nIGNvbW1lbnRzIG9uIHRoZQ0KDQo2NjY1IGNsYXJpZmljYXRpb24gZG9jdW1lbnQgaXMg YXZhaWxhYmxlIGhlcmU6DQoNCg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXNpcGNvcmUtNjY2NS1jbGFyaWZpY2F0aW9uLw0KDQoNCg0KSXZvIC8gQnJldHQ6 IGFzIHlvdSB3ZXJlIHRoZSBwZW9wbGUgd2hvIHByb3ZpZGVkIHRoZSBmZWVkYmFjayB0aGF0IEkn dmUgaW5jb3Jwb3JhdGVkLCBwbGVhc2UgbG9vayBvdmVyIHRoaXMgbGF0ZXN0IHRleHQgdG8gbGV0 IG1lIGtub3cgd2hldGhlciBpdCBhZGRyZXNzZXMgdGhlIHNwZWNpZmljIGNvbmNlcm4gdGhhdCBo YWQgYmVlbiByYWlzZWQuIFRoYW5rcyENCg0KDQoNCi9hDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D775386ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIFwsIHNlcmlmIjt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29Q bGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJp ZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIixzYW5zLXNlcmlmO30NCnAubXNvY2hwZGVmYXVsdCwgbGkubXNvY2hwZGVm YXVsdCwgZGl2Lm1zb2NocGRlZmF1bHQNCgl7bXNvLXN0eWxlLW5hbWU6bXNvY2hwZGVmYXVsdDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNw YW4ucGxhaW50ZXh0Y2hhcjANCgl7bXNvLXN0eWxlLW5hbWU6cGxhaW50ZXh0Y2hhcjsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjojOTg0ODA2O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiM5ODQ4 MDY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1H QiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+SSBzdXBwb3J0IGhhdmluZyBjb25zaXN0ZW50IHRlcm1pbm9sb2d5LCBhbmQgdGhlIHN1Z2dl c3RlZCBjaGFuZ2Ugc2VlbXMgdmVyeSBzdHJhaWdodCBmb3J3YXJkLCBzb+KApjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9h PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBJ dm8gU2VkbGFjZWsNCjxicj4NCjxiPlNlbnQ6PC9iPiAyMyBNYXJjaCAyMDE1IDA5OjAwPGJyPg0K PGI+VG86PC9iPiBBZGFtIFJvYWNoOyBDaHJpc3RlciBIb2xtYmVyZzsgJ1NJUENPUkUnOyBCcmV0 dCBUYXRlPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBDb25jbHVkZWQ6IFdHTEMgLyBDYWxsIGZv ciBBZG9wdGlvbjogUkVGRVItcmVsYXRlZCB3b3JrPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojOTg0 ODA2Ij5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM5ODQ4MDYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6Izk4NDgwNiI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBjb21t ZW50IGlzIHN0cmljdGx5IGVkaXRvcmlhbCAoYW4gYXJlYSBvdmVyIHdoaWNoIGRvY3VtZW50IGVk aXRvcnMgYXJlIGdpdmVuIHNpZ25pZmljYW50IGxhdGl0dWRlKSwgYW5kIC0tIGluIG15IG9waW5p b24gLS0gaXMgbm90IGFuIGltcHJvdmVtZW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgSXQgc2F5cyB0aGUgc2Ft ZSB0aGluZywgd2l0aCBlcXVpdmFsZW50IGNsYXJpdHksIHVzaW5nIG1vcmUgd29yZHMuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Izk4NDgwNiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjojOTg0ODA2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM5ODQ4MDYiPklzIHRoZXJl IGFueSBkZWZpbml0aW9uIG9mIHdoYXQgJnF1b3Q7c3Vic2NyaXB0aW9uIHJlcXVlc3RzIChpbXBs aWNpdCBvciBleHBsaWNpdCkmcXVvdDsgYXJlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Izk4NDgwNiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojOTg0ODA2Ij5pZiBubywgdGhlbiB3b3JkaW5nICZx dW90O3JlcXVlc3RzIHRoYXQgbWlnaHQgY3JlYXRlIGFuIChpbXBsaWNpdCBvciBleHBsaWNpdCkg c3Vic2NyaXB0aW9uJnF1b3Q7IGlzIG1vcmUgcHJlY2lzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM5 ODQ4MDYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Izk4NDgwNiI+SW4gYW55IGNhc2UsIHRo ZSB3b3JkaW5nICgmcXVvdDtyZXF1ZXN0IHRoYXQgbWlnaHQgY3JlYXRlIGEgc3Vic2NyaXB0aW9u JnF1b3Q7KSBpcyB1c2VkIGVsc2V3aGVyZSBpbiB0aGUgZG9jdW1lbnQgc28gY2hhbmdlIHdvdWxk IG1ha2UgdGhlIHRleHQgY29uc2lzdGVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM5ODQ4MDYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Izk4NDgwNiI+S2luZCByZWdhcmRzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjojOTg0ODA2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM5ODQ4MDYiPkl2byBT ZWRsYWNlazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Izk4NDgwNiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMzMzMzMzIj5UaGlzIENvbW11bmljYXRpb24gaXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5 IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0 IGF0DQo8YSBocmVmPSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyIiB0 aXRsZT0iaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lciI+DQp3d3cuZXJp Y3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI8L2E+IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPiBBZGFtIFJvYWNoIFs8YSBocmVmPSJtYWlsdG86YWRhbUBub3N0 cnVtLmNvbSI+bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IDIwLiBixZllem5hIDIwMTUgMjI6MDc8YnI+DQo8Yj5Ubzo8L2I+IEl2byBTZWRsYWNlazsgQ2hy aXN0ZXIgSG9sbWJlcmc7ICdTSVBDT1JFJzsgQnJldHQgVGF0ZTxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogQ29uY2x1ZGVkOiBXR0xDIC8gQ2FsbCBmb3IgQWRvcHRpb246IFJFRkVSLXJlbGF0ZWQg d29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5bYXMgZG9jdW1l bnQgZWRpdG9yXTxicj4NCjxicj4NClRoYW5rcy4gSSd2ZSBzZWVuIHRoZSBmZWVkYmFjaywgYnV0 IGRvbid0IGN1cnJlbnRseSBwbGFuIHRvIGluY29ycG9yYXRlIGl0LiBUaGUgY29tbWVudCBpcyBz dHJpY3RseSBlZGl0b3JpYWwgKGFuIGFyZWEgb3ZlciB3aGljaCBkb2N1bWVudCBlZGl0b3JzIGFy ZSBnaXZlbiBzaWduaWZpY2FudCBsYXRpdHVkZSksIGFuZCAtLSBpbiBteSBvcGluaW9uIC0tIGlz IG5vdCBhbiBpbXByb3ZlbWVudC4gSXQgc2F5cyB0aGUgc2FtZSB0aGluZywgd2l0aCBlcXVpdmFs ZW50DQogY2xhcml0eSwgdXNpbmcgbW9yZSB3b3Jkcy48YnI+DQo8YnI+DQovYTxicj4NCjxicj4N Ck9uIDMvMTkvMTUgMDE6MzYsIEl2byBTZWRsYWNlayB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojOTg0ODA2Ij5IZWxsbyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6Izk4NDgwNiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOiM5ODQ4MDYiPm15IGNvbW1lbnQgPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj4oPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Np cGNvcmUvY3VycmVudC9tc2cwNjU2MS5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50L21zZzA2NTYxLmh0bWw8L2E+KQ0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Izk4NDgwNiI+aGFzIG5vdCBiZWVuIGFkZHJlc3Nl ZCB5ZXQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM5ODQ4 MDYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj OTg0ODA2Ij5LaW5kIHJlZ2FyZHM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6Izk4NDgwNiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiM5ODQ4MDYiPkl2byBTZWRsYWNlazwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojOTg0ODA2Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+VGhpcyBDb21tdW5pY2F0aW9uIGlz IENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNp cyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdA0KPGEgaHJlZj0iaHR0cDovL3d3dy5lcmljc3Nvbi5j b20vZW1haWxfZGlzY2xhaW1lciIgdGl0bGU9Imh0dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWls X2Rpc2NsYWltZXIiPg0Kd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPC9hPiA8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMt c2VyaWYiPiBDaHJpc3RlciBIb2xtYmVyZw0KPGJyPg0KPGI+U2VudDo8L2I+IDE3LiBixZllem5h IDIwMTUgMTg6MjU8YnI+DQo8Yj5Ubzo8L2I+IEl2byBTZWRsYWNlazsgQWRhbSBSb2FjaDsgJ1NJ UENPUkUnOyBCcmV0dCBUYXRlPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBDb25jbHVkZWQ6IFdH TEMgLyBDYWxsIGZvciBBZG9wdGlvbjogUkVGRVItcmVsYXRlZCB3b3JrPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkhpLDxicj4NCjxicj4NCldoYXQgaXMgdGhlIHN0YXR1cyBvZiB0aGlzPyBIYXMgSXZvJ3Mg Y29tbWVudCBiZWVuIGFkZHJlc3NlZD88YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNo cmlzdGVyPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuIFwsIHNlcmlmJnF1b3Q7Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNl bnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOiA8L3NwYW4+DQo8L2I+ PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzppdm8uc2VkbGFjZWtAZXJpY3Nzb24u Y29tIj5Jdm8gU2VkbGFjZWs8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4gXCwgc2VyaWYm cXVvdDsiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+U2VudDogPC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyI+4oCOMDQv4oCOMDMv4oCOMjAxNSAxMDoxMTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuIFwsIHNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiPlRvOiA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWls dG86YWRhbUBub3N0cnVtLmNvbSI+QWRhbSBSb2FjaDwvYT47DQo8YSBocmVmPSJtYWlsdG86Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj5DaHJpc3RlciBIb2xtYmVyZzwvYT47IDxhIGhy ZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj4NCidTSVBDT1JFJzwvYT47IDxhIGhyZWY9Im1h aWx0bzpicmV0dEBicm9hZHNvZnQuY29tIj5CcmV0dCBUYXRlPC9hPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuIFwsIHNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iRU4t VVMiPlN1YmplY3Q6IDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPlJFOiBDb25jbHVkZWQ6 IFdHTEMgLyBDYWxsIGZvciBBZG9wdGlvbjogUkVGRVItcmVsYXRlZCB3b3JrPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgcmV2 aWV3ZWQgZHJhZnQtaWV0Zi1zaXBjb3JlLXJlZmVyLWNsYXJpZmljYXRpb25zLTAzIGFuZCBkcmFm dC1pZXRmLXNpcGNvcmUtcmVmZXItZXhwbGljaXQtc3Vic2NyaXB0aW9uLTAwJm5ic3A7IGFuZCBm b3VuZCBubyBpc3N1ZXMuIE9LIHRvIHByb2dyZXNzIHRob3NlIGRyYWZ0cy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSBy ZXZpZXdlZCBkcmFmdC1pZXRmLXNpcGNvcmUtNjY2NS1jbGFyaWZpY2F0aW9uLTAwIGFuZCBzZW50 IGEgY29tbWVudCB0byB0aGUgU0lQQ09SRSBsaXN0IHllc3RlcmRheSAoPGEgaHJlZj0iaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwNjU2MS5o dG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50 L21zZzA2NTYxLmh0bWw8L2E+KS4NCiBJIHByZWZlciB0aGUgY29tbWVudCBiZWluZyBhZGRyZXNz ZWQgYmVmb3JlIHByb2dyZXNzaW5nIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+S2luZCByZWdhcmRzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPkl2byBTZWRsYWNlayA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgQ29tbXVu aWNhdGlvbiBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBv biB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQNCjxhIGhyZWY9Imh0dHA6Ly93d3cu ZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXIiPnd3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlz Y2xhaW1lcjwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQpGcm9tOiBBZGFtIFJvYWNoIFs8YSBocmVmPSJtYWlsdG86YWRhbUBub3N0 cnVtLmNvbSI+bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb208L2E+XSA8YnI+DQpTZW50OiAyOC4gw7pu b3JhIDIwMTUgMTowODxicj4NClRvOiBDaHJpc3RlciBIb2xtYmVyZzsgJ1NJUENPUkUnOyBJdm8g U2VkbGFjZWs7IEJyZXR0IFRhdGU8YnI+DQpTdWJqZWN0OiBDb25jbHVkZWQ6IFdHTEMgLyBDYWxs IGZvciBBZG9wdGlvbjogUkVGRVItcmVsYXRlZCB3b3JrPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij5bYXMgY2hhaXJdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgYWRvcHRpb24gYW5kIFdH TEMgcGVyaW9kIGZvciB0aGUgdGhyZWUgZG9jdW1lbnRzIGhhcyBlbmRlZC4gR2l2ZW4gdGhlIGV4 cHJlc3NlZCBzdXBwb3J0IChtZWFnZXIgYXMgaXQgd2FzKSBhbmQgbGFjayBvZiBvYmplY3Rpb24s IHdlJ3JlIGdvaW5nIHRvIGNvbnNpZGVyIHRoZSA2NjY1LWNsYXJpZmljYXRpb25zIGRyYWZ0IGFk b3B0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGVyZSB3ZXJlIG5vIGFkZGl0aW9uYWwg Y29tbWVudHMgb24gcmVmZXItY2xhcmlmaWNhdGlvbnMgb3IgcmVmZXItZXhwbGljaXQtc3Vic2Ny aXB0aW9uLCBzbyB3ZSB3aWxsIGJlZ2luIHByZXBhcmluZyB0aGVtIGZvciBJRVNHIHJldmlldy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlthcyBhdXRob3JdPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj5BIG5ldyB2ZXJzaW9uIHRoYXQgSSBiZWxpZXZlIGFkZHJlc3NlcyB0aGUgb3V0c3RhbmRp bmcgY29tbWVudHMgb24gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjY2NjUgY2xhcmlmaWNhdGlvbiBkb2N1bWVudCBp cyBhdmFpbGFibGUgaGVyZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2lwY29yZS02NjY1LWNsYXJp ZmljYXRpb24vIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246 bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaXBjb3Jl LTY2NjUtY2xhcmlmaWNhdGlvbi88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ SXZvIC8gQnJldHQ6IGFzIHlvdSB3ZXJlIHRoZSBwZW9wbGUgd2hvIHByb3ZpZGVkIHRoZSBmZWVk YmFjayB0aGF0IEkndmUgaW5jb3Jwb3JhdGVkLCBwbGVhc2UgbG9vayBvdmVyIHRoaXMgbGF0ZXN0 IHRleHQgdG8gbGV0IG1lIGtub3cgd2hldGhlciBpdCBhZGRyZXNzZXMgdGhlIHNwZWNpZmljIGNv bmNlcm4gdGhhdCBoYWQgYmVlbiByYWlzZWQuIFRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPi9hPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D775386ESESSMB209erics_-- From nobody Mon Mar 23 13:45:19 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD29E1B2A2A; Mon, 23 Mar 2015 13:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbAE5jCTk2BZ; Mon, 23 Mar 2015 13:45:15 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B08A1B2A0C; Mon, 23 Mar 2015 13:45:15 -0700 (PDT) Received: by labto5 with SMTP id to5so36395677lab.0; Mon, 23 Mar 2015 13:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JY5MKIgxpQASX3P+P8Pp5kNrv85F8kZwvhwi2Or/k80=; b=L/GSP62OeF/c1UV0NzmtzlS1t4nG0tfxqjJXmjChpyAUBiJULIcTZjbZuKLlpVgLgm zxGXpLOAGL3PaZ1xXgq/eg8mg9zp9+waPxMejfUbBpDW9AbrTTOq8h8mmgGs2ejnou8X PbdpdaUdE3fhRFIFLVfLInLgtn/RX2IHULLPvjLjgg0DIlK/urShAQ3xUXwT6i7TSNqI wZd9gh20KpYKGzBIO+T5elZjqy81ihJREQz6K2oN6/bhJWoVgIEZc7yegYgR9Tz08we3 HsQ7pzY4KOIfrq/+lJ4qvOFfh5JUrvIZ7mLkXmQV3tbXsfyk+q5W2XOH8rwe4H5PQfOc CbFw== MIME-Version: 1.0 X-Received: by 10.152.236.42 with SMTP id ur10mr763601lac.37.1427143513559; Mon, 23 Mar 2015 13:45:13 -0700 (PDT) Received: by 10.25.17.195 with HTTP; Mon, 23 Mar 2015 13:45:13 -0700 (PDT) In-Reply-To: <55105867.881fec0a.614d.fffffc9eSMTPIN_ADDED_BROKEN@mx.google.com> References: <55105867.881fec0a.614d.fffffc9eSMTPIN_ADDED_BROKEN@mx.google.com> Date: Mon, 23 Mar 2015 15:45:13 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=001a113465f82b56370511fabeac Archived-At: Cc: SIPCORE Subject: [sipcore] Fwd: [SIPForum-techwg] SIPNOC 2015 Call for Presentations Deadline Extended To April 1st X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:45:18 -0000 --001a113465f82b56370511fabeac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI...this was one of the items mentioned during the WG session today. Regards, Mary. ---------- Forwarded message ---------- From: Marc Robins Date: Mon, Mar 23, 2015 at 1:14 PM Subject: [SIPForum-techwg] SIPNOC 2015 Call for Presentations Deadline Extended To April 1st To: techwg@sipforum.org Dear SIP Forum TechWG Members, Based on a number of requests for an extension to submit speaking proposals for SIPNOC 2015, we have decided to extend the CFP deadline to April 1, 2015. SIPNOC 2015 Call for Presentations proposals can be submitted by visiting the SIP Forum SIPNOC 2015 Call for Presentations webpage . Possible topics can include SIP peering, SIP trunking, Emergency Services, Congestion Control, Scaling and Capacity Issues, SIP-based applications, Routing, Security, SIP-Network Operations Center Best Practices, IPv6 deployment challenges, NNI, HD Voice, Standardization Issues and Progress, HD voice deployments, Video Interoperability, WebRTC and SIP, Testing or other issues facing SIP network operations. SIPNOC 2015 offers several different types of speaking opportunities including: - General Session Talks: A General Session presentation should be on a topic of interest to the general SIPNOC audience, and may be up to 30 minutes long (including time for Q&A). - General Session Panels: Panels are sessions with a moderator and a team of panelists. The panel moderator should submit an abstract on the panel topic, a list of panelists, and how the panel will be organized. Panel selection is based on the importance, originality, focus and timeliness of the topic, expertise of proposed panelists, as well as the potential for informative and controversial discussion. - Special Workshops: The SIPNOC 2015 program has been expanded to include special workshops that run for 1-2 hours, providing time to focu= s in-depth on a variety of issues important to the SIPNOC community. Topic= s can include a review of SIP RFCs and standards development, the regulato= ry environment, etc. - Research Topics: Researchers are invited to present short summaries of their work for operator feedback. Topics may include call routing, netwo= rk performance, statistical measurement and analysis and protocol developme= nt and implementation. Studies presented may be works in progress. Research= ers from academia, government, and industry are encouraged to present. - BOFs: BOFs (Birds of a Feather sessions) are informal sessions on topics which are of interest to a portion of the SIPNOC community. BOFs = may be held in break=E2=80=90out areas or in an unscheduled room. Requests f= or scheduled BOFs can be made at any time, including on site at the confere= nce. Presented by the SIP Forum, the leading industry association focused on the advancement of IP communications products and services based on the Session Initiation Protocol (SIP), the fifth annual SIPNOC conference is a unique event for service providers and carriers to gather to discuss the challenges of deploying and implementing SIP-based communications technology, and to learn the best-practices and strategies that enable the successful and profitable operation of SIP-based services and applications. SIPNOC 2015 attendees will include telecommunications providers, major backbone operators, interconnect and wholesale solution providers, ISPs, cable operators, wireless network operators as well as large enterprises deploying major SIP initiatives. ------------------------------ *SIPNOC 2015 General Info* The SIPNOC 2015 event website is located at www.sipnoc.org. To view the official call for presentations, which includes instructions on submitting material and specific SIPNOC policies, please visit www.sipforum.org/content/view/374/275/. To submit, visit https://www.easychair.org/conferences/?conf=3Dsipnoc2015. Registration for SIPNOC 2015 is officially open! The regular SIPNOC 2015 conference registration fee is $995 for one full day of SIP Training and two days of conference proceedings, including all meals (breakfasts, lunches and dinners) and break refreshments. *Individuals from SIP Forum Full Member companies are entitled to special savings! Please contact Marc Robins, SIP Forum President and Managing Director, at marc.robins@sipforum.org to obtain the exclusive Full Member discount code.* Register today at http://www.regonline.com/sipnoc2015. ------------------------------ *SIPNOC 2015 Sponsorship Information* For information about corporate sponsorship opportunities at SIPNOC 2015, please contact Marc Robins, SIP Forum President and Managing Director, at 203-829-6307 or marc.robins@sipforum.org. ------------------------------ All best, Marc ************************* Marc Robins President and Managing Director SIP Forum http://www.sipforum.org Mobile: 203-829-6307 SkypeMe! marcrobins ************************* _______________________________________________ techwg mailing list Send mail to: techwg@sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techw= g --001a113465f82b56370511fabeac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI...this was one of the items mentioned during the WG se= ssion today. =C2=A0=C2=A0

Regards,
Mary.
=

---------- Forwarded message ----------=
From: Marc Robins &= lt;marc.robins@sipforum.org= >
Date: Mon, Mar 23, 2015 at 1:14 PM
Subject: [SIPForum-tec= hwg] SIPNOC 2015 Call for Presentations Deadline Extended To April 1st
T= o: techwg@sipforum.org

Dear SIP Forum Tec= hWG Members,

<= p>Ba= sed on a number of requests for an extension to submit speaking proposals f= or SIPNOC 2015, we have decided to extend the CFP deadline to April 1, 2015= .

SIPNOC 2015 Call for Presentations proposals can b= e submitted by visiting the SIP Forum SIPNOC 2015 Call for Presentations w= ebpage. Possible topics can include SIP peering, SIP trunking, Emergenc= y Services, Congestion Control, Scaling and Capacity Issues, SIP-based appl= ications, Routing, Security, SIP-Network Operations Center Best Practices, = IPv6 deployment challenges, NNI, HD Voice, Standardization Issues and Progr= ess, HD voice deployments, Video Interoperability, WebRTC and SIP, Testing = or other issues facing SIP network operations.

= SIPN= OC 2015 offers several different types of speaking opportunities including:=

  • General Session Talks: A General Session presentat= ion should be on a topic of interest to the general SIPNOC audience, and ma= y be up to 30 minutes long (including time for Q&A).
  • General Se= ssion Panels: Panels are sessions with a moderator and a team of panelists.= The panel moderator should submit an abstract on the panel topic, a list o= f panelists, and how the panel will be organized. Panel selection is based = on the importance, originality, focus and timeliness of the topic, expertis= e of proposed panelists, as well as the potential for informative and contr= oversial discussion.
  • Special Workshops: The SIPNOC 2015 program has = been expanded to include special workshops that run for 1-2 hours, providin= g time to focus in-depth on a variety of issues important to the SIPNOC com= munity. Topics can include a review of SIP RFCs and standards development, = the regulatory environment, etc.
  • Research Topics: Researchers are in= vited to present short summaries of their work for operator feedback. Topic= s may include call routing, network performance, statistical measurement an= d analysis and protocol development and implementation. Studies presented m= ay be works in progress. Researchers from academia, government, and industr= y are encouraged to present.
  • BOFs: BOFs (Birds of a Feather sessions) are informal se= ssions on topics which are of interest to a portion of the SIPNOC community= . BOFs may be held in break=E2=80=90out areas or in an unscheduled room. Re= quests for scheduled BOFs can be made at any time, including on site at the= conference.

Presented by the SIP Forum= , the leading industry association focused on the advancement of IP communi= cations products and services based on the Session Initiation Protocol (SIP= ), the fifth annual SIPNOC conference is a unique event for service provide= rs and carriers to gather to discuss the challenges of deploying and implem= enting SIP-based communications technology, and to learn the best-practices= and strategies that enable the successful and profitable operation of SIP-= based services and applications.

SIPNOC 2015 attendees wil= l include telecommunications providers, major backbone operators, interconn= ect and wholesale solution providers, ISPs, cable operators, wireless netwo= rk operators as well as large enterprises deploying major SIP initiatives.<= u>

SIPNOC 2015 General Info

The SIPNOC 2015 event website is located at www.sipnoc.org.

To view the official call for presentations, which includes instructio= ns on submitting material and specific SIPNOC policies, please visit www.s= ipforum.org/content/view/374/275/. To submit, visit https:/= /www.easychair.org/conferences/?conf=3Dsipnoc2015.=

Registration for SIPNOC 2015 is officially open!

= The regular SIPNOC 2015 conference registration fee is $995 for one full da= y of SIP Training and two days of conference proceedings, including all mea= ls (breakfasts, lunches and dinners) and break refreshments.<= /span>

Individuals from SIP Forum Full Member companies a= re entitled to special savings! Please contact Marc Robins, SIP Forum Presi= dent and Managing Director, at marc.robins@sipforum.org to obtain the exclusive Full= Member discount code.

Register today at http://www.regon= line.com/sipnoc2015.=C2=A0

<= span style=3D"font-family:"Calibri","sans-serif"">SIPNO= C 2015 Sponsorship Information

For information= about corporate sponsorship opportunities at SIPNOC 2015, please contact M= arc Robins, SIP Forum President and Managing Director, at 203-829-6307 or marc.robins@sip= forum.org.

= =C2=A0

All best,

<= p class=3D"MsoNormal">=C2=A0

Marc

=C2=A0

*************************

Marc Robins

President and Managing Directo= r

SIP Forum

http= ://www.sipforum.org

Mobile: 203-829-6307

SkypeMe! marcrobins<= u>

=C2=A0

*************************

=C2=A0


_________________________________= ______________
techwg mailing list
Send mail to: techwg@sipforum.org
Unsubscribe or edit options at:=C2=A0 http://sipforum.org/mailman/listinfo/t= echwg


--001a113465f82b56370511fabeac--