From nobody Tue Mar 1 02:41:01 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D201B3F1B for ; Tue, 1 Mar 2016 02:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 KZFsQZtcniCc for ; Tue, 1 Mar 2016 02:40:56 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF871B3F02 for ; Tue, 1 Mar 2016 02:40:55 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id E8D7023F0513; Tue, 1 Mar 2016 11:40:53 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0279.002; Tue, 1 Mar 2016 11:40:53 +0100 From: "Hutton, Andrew" To: "Peterson, Jon" , Ben Campbell , Mary Barnes Thread-Topic: [dispatch] Reminder: Deadlines for IETF-95 Thread-Index: AQHRZAqTJ+2zqOwoS02MQXPireE1/p8n/OoAgBuhi4CAAOZ7sA== Date: Tue, 1 Mar 2016 10:40:53 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF26050950@MCHP04MSX.global-ad.net> References: <8119825D-F91F-4494-AE59-39E3956B02F1@nostrum.com> In-Reply-To: Accept-Language: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Reminder: Deadlines for IETF-95 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 10:40:57 -0000 Definitely interested and obviously would like to see https://tools.ietf.or= g/html/draft-johnston-dispatch-osrtp-02 move forward as well. Andy > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of > Peterson, Jon > Sent: 29 February 2016 23:54 > To: Ben Campbell; Mary Barnes > Cc: DISPATCH > Subject: Re: [dispatch] Reminder: Deadlines for IETF-95 >=20 >=20 > I just wanted to confirm that Ben here is correct. This idea came out > of a > discussion in Yokohama about identifying the best practices for media > security when setting up sessions with SIP, and in particular the glue > that binds security in SIP to SDP and to RTP. This would invoke things > like STIR, and would also potentially nod to more opportunistic > approaches > like those outlined in Alan's draft, as media confidentiality is one of > the more important security properties in this post-PERPASS world of > ours. >=20 > So, we expect to have a draft before the deadline - happy to discuss > the > general topic here in the meantime if there's interest. >=20 > Jon Peterson > Neustar, Inc. >=20 > On 2/11/16, 5:56 PM, "dispatch on behalf of Ben Campbell" > wrote: >=20 > >Hi, > > > >I understand that Jon, Ekr, Richard, and Russ plan to submit a draft > on > >security recommendations for point-to-point, SIP-signaled RTP in time > >for Buenos Aires. While I would be pleasantly surprised if the > >discussion is far enough along by then for a charter proposal, I think > >discussion in DISPATCH would be worthwhile. > > > >So, please consider this notice of their intent to propose a > discussion > >topic, on their behalf. > > > >Thanks! > > > >Ben. > > > >On 10 Feb 2016, at 7:54, Mary Barnes wrote: > > > >> Hi all, > >> > >> Just a reminder of the DISPATCH WG deadlines for IETF-95: > >> https://trac.tools.ietf.org/wg/dispatch/trac/wiki > >> > >> > >> - February 22, 2016. Cutoff date to notify the chairs/DISPATCH WG > of > >> plans to submit a proposal. > >> > >> > >> - February 29, 2016. Cutoff for charter proposals for topics. > >> > >> > >> - March 7, 2016. Announcement of topics that have been dispatched > for > >> IETF-95. > >> > >> > >> - March 21, 2016. Draft deadline. > >> > >> > >> Regards, > >> Mary > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > >_______________________________________________ > >dispatch mailing list > >dispatch@ietf.org > >https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Mar 3 11:50:46 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278501B2DB9 for ; Thu, 3 Mar 2016 11:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 6j8_86SK7TLW for ; Thu, 3 Mar 2016 11:50:44 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 B1C511B4246 for ; Thu, 3 Mar 2016 11:50:44 -0800 (PST) Received: by mail-pa0-x22e.google.com with SMTP id fy10so20217512pac.1 for ; Thu, 03 Mar 2016 11:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hZIvQsqI4cPsXVndgtygLx/PALJB0WF48o268g6qb9o=; b=Kq4bkXvR+Rst2PNy8usU2CaQxMZT5znIMCBp+1fMeujQrKCqzgnSzuWVIoCx9LLXZr 6aqqBuXYmXuR5SLgDlE6La+KNf7q3blgvcVTQb9niK+Of4nMDJexkiJStyeoMVJQT6CK mmp/T/qpXgveR/9rzZeRC6ekHtZOwo1VJMWvf2VzW26f0u1m3sZM5nJaXjDnpulVokpX Vtdww9RjeHeaNT1MxyeFXeFO8YxFhT94O6VV5NqM0PuxY40RC/QYpG0409jMiksLiuzw xbhHN4SvPOAHTRVQAfwpHHfKvRMoEtrt59Ih6eu66qlBZTV13n7dvOyXLsehv/Nnyrhu aifw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hZIvQsqI4cPsXVndgtygLx/PALJB0WF48o268g6qb9o=; b=H/1DjRESgje3wq1RqzA00YVXsCp3hfWrb37h/GGQPDQNZ9YMA2XvJe432N3AvyscrL Tpopiir8b+Lm0n3j0G8DNhc8LcnxpYmp37lCeeNRpOxbmOe1RDuLVGn7Ugq55NxP7q/v 95L+Vz+e12mW3dKhelD7EOhEoWfMSk99VORxL+J3eUSCegAAXn2CyahmMVwmrFVUmOlF m3qYgP4GCGAkE7DComs2zqDPlNKtyQotbFn+UusTJ0nIl+dB5D9AhPShn3uHnWVnt4ll UY8/xwve9j5IpvKHj27Ia60CjqL88hCZ1dg11ROuGqRaDVxkxPqO7QJ1E9izNBdZXU6j k7dA== X-Gm-Message-State: AD7BkJIYwZxu9gPiI5stIdIZk+mhrMmh3k2MLfHOHE46+o2ZBKTo6XdNQc4nI6jhFc+ASg== X-Received: by 10.66.147.103 with SMTP id tj7mr6215428pab.72.1457034644397; Thu, 03 Mar 2016 11:50:44 -0800 (PST) Received: from [192.168.1.4] (203-158-52-225.dyn.iinet.net.au. [203.158.52.225]) by smtp.gmail.com with ESMTPSA id w20sm44353pfi.31.2016.03.03.11.50.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Mar 2016 11:50:42 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: James Winterbottom In-Reply-To: <6ED851DB-7951-4CE0-8674-A49120881DD4@nostrum.com> Date: Fri, 4 Mar 2016 06:50:36 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <941FFD59-7A78-4D2E-9088-A30328056957@gmail.com> References: <56D0BFBD.8080000@cs.tcd.ie> <6ED851DB-7951-4CE0-8674-A49120881DD4@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 19:50:46 -0000 Thanks All. This response has been a little slow. I shall make some text updates to try and address Ben=E2=80=99s concerns = below which, I hope, will also address Stephen=E2=80=99s. Cheers James > On 27 Feb 2016, at 9:52 am, Ben Campbell wrote: >=20 > On 26 Feb 2016, at 15:12, Stephen Farrell wrote: >=20 >> Hi Mary, >>=20 >> On 26/02/16 18:47, Mary Barnes wrote: >>> only >>> recommended to be used in the context of a trusted network. >>=20 >> What does that mean? >=20 > I think the point is, the draft needs to say what it means :-). >=20 > And actually, the current version does have a Spec(T) [RFC 3325] = reference. But I think the request here is for clarification of = application scope assumptions. For example, it mentions 3GPP and ETSI = architectures; do we expect its use to be limited to those = architectures? >=20 > This probably goes beyond just trust issues. For example, what = happens when a recipient that does not understand this extension tries = to interpret a location value that uses it. >=20 > Ben. (Who is answering off the top of his head, and apologizes in = advance if he forgot something in the draft that answers all this). >=20 From nobody Fri Mar 4 00:20:01 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64D31B34D9 for ; Fri, 4 Mar 2016 00:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G44Si0i3M1pW for ; Fri, 4 Mar 2016 00:19:57 -0800 (PST) Received: from mailrelay04.virginmedia.co.uk (mailrelay04.telewest.co.uk [193.38.82.68]) (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 E36821B34BA for ; Fri, 4 Mar 2016 00:19:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=virginmedia.co.uk; i=@virginmedia.co.uk; q=dns/txt; s=mailrelays; t=1457079596; x=1488615596; h=from:to:subject:date:message-id: content-transfer-encoding; bh=vUmNzbqem3gakuRHUYH54ZKb0ad9igaMLjk5ed+zIZI=; b=OPQ/XnFPvCJPoOYvAZG+ljni7BSc2tONM4IkWJ4sqpVzPKvQoKauUMpr kNW36p++NKjoVHFPVxW4Pru8cI+WxpcXnFPIc6kuacDA42VcIJr7HerUn KihPn6j8+g8XROnq0V0VS+z3iXi8NoYdaUUA+W8xy390LEpsfaQQYjrbJ o=; X-AddDisclaimer: Media X-SMTP-INT: T X-NonCorpAttach-CLI: false From: "Hutchison, Phil" To: "'dispatch@ietf.org'" Thread-Topic: draft-weinronk-dispatch-last-diverting-line-id Thread-Index: AdF17qENyZLD+5A8QJOT25urfAPpQA== Date: Fri, 4 Mar 2016 08:19:54 +0000 Message-ID: <6F1F19576314274FB33F9F02948A9AAACC732DD8@kn2-mbx-p0001> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6F1F19576314274FB33F9F02948A9AAACC732DD8kn2mbxp0001_" MIME-Version: 1.0 Archived-At: Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 08:19:59 -0000 --_000_6F1F19576314274FB33F9F02948A9AAACC732DD8kn2mbxp0001_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, I believe that this is required in the UK, and therefore would like to see = the draft accepted. Regards Phil ~~~~~~~~~~~~~~~~~ Phil Hutchison Liberty Global CAO - Communications Architecture Mobile +447775 938827 | Soft Client +44(0)3703 900464 | Email phil.hutchiso= n@virginmedia.co.uk Meet Me Conference: 0808 1074444 [+44 1723204444] PIN 1256450# Visit www.virginmedia.co.uk for more informa= tion, and more fun Save paper - do you really need to print this email? -------------------------------------------------------------------- Save Paper - Do you really need to print this e-mail? Visit www.virginmedia.com for more information, and more fun. This email and any attachments are or may be confidential and legally privi= leged and are sent solely for the attention of the addressee(s). If you have rece= ived this email in error, please delete it from your system: its use, disclosure or c= opying is unauthorised. Statements and opinions expressed in this email may not repre= sent those of Virgin Media. Any representations or commitments in this email are subject to contract. = Registered office: Media House, Bartley Wood Business Park, Hook, Hampshire= , RG27 9UP Registered in England and Wales with number 2591237 --_000_6F1F19576314274FB33F9F02948A9AAACC732DD8kn2mbxp0001_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

= Hi,=

=  

= I believe that this is requi= red in the UK, and therefore would like to see the draft accepted.

=  

= Regards

=  

Phil

~~~~~~~~~~~~~~~~~<= /font>

Phil Hutchison

Liberty Global CAO - Communications A= rchitecture

Mobile +447775 938827 | Soft Client +44(0)3703 900464 | Email phil.hutchison@virginmedia.co.uk

Meet Me Conference: 0808 1074444  [+44 1723204444]<= /span> PIN 1256450#

Visit www.virginmedia.co.uk for more information, and more fun

Save paper - do you really need= to print this email?

 


--------------------------------------------------------------------
Save Paper - Do you really need to print this e-mail?

Visit www.virginmedia.com for more information, and more fun.

This email and any attachments are or may be confidential and legally pr= ivileged
and are sent solely for the attention of the addressee(s). If you have rece= ived this
email in error, please delete it from your system: its use, disclosure or c= opying is
unauthorised. Statements and opinions expressed in this email may not repre= sent
those of Virgin Media. Any representations or commitments in this email are=
subject to contract.

Registered office: Media House, Bartley Wood Business Park, Hook, Hampsh= ire, RG27 9UP
Registered in England and Wales with number 2591237

--_000_6F1F19576314274FB33F9F02948A9AAACC732DD8kn2mbxp0001_-- From nobody Fri Mar 4 07:26:15 2016 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B231A1BF1; Fri, 4 Mar 2016 07:26:14 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160304152614.11396.70619.idtracker@ietfa.amsl.com> Date: Fri, 04 Mar 2016 07:26:14 -0800 Archived-At: Cc: dispatch@ietf.org, The IESG , dispatch-chairs@ietf.org Subject: [dispatch] WG Action: Rechartered Dispatch (dispatch) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 15:26:14 -0000 The Dispatch (dispatch) WG in the Applications and Real-Time Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Dispatch (dispatch) ----------------------------------------------------------------------- Current status: Active WG Chairs: Mary Barnes Cullen Jennings Murray Kucherawy Assigned Area Director: Ben Campbell Applications and Real-Time Area Directors: Barry Leiba Ben Campbell Alissa Cooper Mailing list: Address: dispatch@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/dispatch Archive: https://mailarchive.ietf.org/arch/browse/dispatch/ Charter: https://datatracker.ietf.org/doc/charter-ietf-dispatch/ The Dispatch working group is chartered to consider proposals for new work in the ART area and identify, or help create, an appropriate venue for the work. Guiding principles for the proposed new work include: 1. Providing a clear problem statement, motivation and deliverables for the proposed new work. 2. Ensuring there has been adequate mailing list discussion reflecting sufficient interest, individuals have expressed a willingness to contribute and there is WG consensus before new work is dispatched. 3. Looking for and identifying commonalities and overlap amongst published or ongoing protocol work. Such commonalities may indicate the possibility of reusing existing protocols or elements thereof published by other WGs, or expanding and/or refactoring the scope of deliverables in an active WG. 4. Protecting the architectural integrity of IETF protocols and ensuring that new work has general applicability. 5. Ensuring that the new work considers and seeks to improve security and privacy. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter for a new WG. - Making recommendations that documents be AD-sponsored (which ADs may or may not choose to follow). - By agreement with ART ADs, processing simple administrative documents. - Deferring the decision for the new work. - Rejecting the new work. If the group decides that a particular topic needs to be addressed by a new WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed charter. Proposals for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. The DISPATCH WG will not do any protocol work. Specifically, DISPATCH will always opt to find a location for technical work; the only work that DISPATCH is not required to delegate (or defer, or reject) is administrative work such as IANA actions. Documents progressed as AD-sponsored would typically include those that do not have general applicability to IETF protocols, but rather are only applicable to specific use cases and network deployments, for which the scope must be clearly specified. Proposed new work may be deferred in cases where the WG does not have enough information for the chairs to determine consensus. New work may be rejected in cases where there is not sufficient WG interest or the proposal has been considered and rejected in the past, unless a substantially revised proposal is put forth, including compelling new reasons for accepting the work. A major objective of the DISPATCH WG is to provide timely, clear dispositions of new efforts. Thus, where there is consensus to take on new work, the WG will strive to quickly find a home for it. While most new work in the ART area is expected to be considered in the DISPATCH working group, there may be times where that is not appropriate. At the discretion of the area directors, new efforts may follow other paths. For example work may go directly to BoFs, may be initiated in other working groups when it clearly belongs in that group, or may be directly AD sponsored. From nobody Sat Mar 5 10:53:06 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F5F1B358A for ; Sat, 5 Mar 2016 10:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkCEj9KlJY-x for ; Sat, 5 Mar 2016 10:53:01 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0739.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:739]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033341B35A8 for ; Sat, 5 Mar 2016 10:52:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MmCYIrCzKX2EOGb9ulD6B6C2dPMaaeCQIUxlBPVFYFk=; b=Aw1AbYLPKvEv3pSoMcQDiGRVqgwVWU1bgv5r+1TRfq0RRQUFEFo3Q/GJVKZvZVVYJ/tpXVmUjSX+iUB0OT7AHuzZhDcIQoMZfBOhPYq49tger4vuVHVfJV34ZktVW7XFMjQvtljRGaTI9GNF3gXwzsb38t7x+GrlmwFUknaHt5A= Received: from BY1PR02MB1194.namprd02.prod.outlook.com (10.162.108.16) by BY1PR02MB1194.namprd02.prod.outlook.com (10.162.108.16) with Microsoft SMTP Server (TLS) id 15.1.415.20; Sat, 5 Mar 2016 18:52:41 +0000 Received: from BY1PR02MB1194.namprd02.prod.outlook.com ([10.162.108.16]) by BY1PR02MB1194.namprd02.prod.outlook.com ([10.162.108.16]) with mapi id 15.01.0415.024; Sat, 5 Mar 2016 18:52:41 +0000 From: Martin Taylor To: "dispatch@ietf.org" Thread-Topic: I-D on RTP failover problem posted to mmusic Thread-Index: AdF3DhoOkQnpNWO+QpOR32SJexhDJw== Date: Sat, 5 Mar 2016 18:52:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=metaswitch.com; x-originating-ip: [185.82.159.246] x-microsoft-exchange-diagnostics: 1; BY1PR02MB1194; 5:usVCVNblDNjPdVdxvoy4rmxfWdbKal0lw6BU11iYNZvl9+1usj+hY5ZEyXHaJJWyFdku59uc52DsZizH8PPFutbFL4nO5mjB+wDcJxMyzEVpn3qkWmVV3e5SS0fbYA+27v1tOodoW/AD1sTsWF6pJQ==; 24:7vQ8TQpFCnKxC7PT+tisJN3mMwuPm1W2IHE1fw/P/DFvhmX2CZ/XyJj2vXiuBnqu56n9qIC/FpLD/mPrb5394QLi2JpxeQDo4hS69doro3c= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR02MB1194; x-ms-office365-filtering-correlation-id: 89ea3bc9-cd61-45d4-7cce-08d3452754bf x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY1PR02MB1194; BCL:0; PCL:0; RULEID:; SRVR:BY1PR02MB1194; x-forefront-prvs: 087223B4DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2501003)(76576001)(5002640100001)(11100500001)(81166005)(33656002)(102836003)(586003)(1220700001)(50986999)(5003600100002)(5008740100001)(3846002)(1096002)(10400500002)(54356999)(122556002)(99286002)(19580395003)(92566002)(2900100001)(66066001)(86362001)(1730700002)(77096005)(450100001)(87936001)(40100003)(2351001)(15975445007)(229853001)(189998001)(107886002)(110136002)(3660700001)(2906002)(5004730100002)(74316001)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR02MB1194; H:BY1PR02MB1194.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2016 18:52:40.6779 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR02MB1194 Archived-At: Subject: [dispatch] I-D on RTP failover problem posted to mmusic X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 18:53:04 -0000 I recently posted https://tools.ietf.org/html/draft-taylor-mmusic-rtp-failo= ver-problem-00 to mmusic. This I-D describes a common problem associated with network functions that = terminate or relay large numbers of concurrent RTP sessions such as session= border controllers or conference bridges. Network operators typically req= uire that no equipment or software failure shall cause more than a second o= r two's interruption to any of the RTP sessions handled by such functions. = The only practical solution capable of meeting this need currently is for = RTP packets to be sent to a service IP address which is capable of being mo= ved quickly from one system to another, and the only way to do this suffici= ently quickly is to for both active and standby systems to be connected to = the same L2 segment. This is problematic in two situations: (1) where acti= ve and standby systems are geographically separated and (2) in L3-centric d= ata center fabrics. This Informational I-D is intended to stimulate discussion leading to conse= nsus on the need for a solution. The solution is likely to involve extensi= ons to SDP to communicate multiple connection addresses at session setup ti= me, which is why I originally submitted the I-D to mmusic. However, the so= lution is also likely to require some new RTP and RTCP procedures - so I ha= ve posted an email to avtcore alerting them to the existence of this I-D. Martin=20 From nobody Mon Mar 7 07:33:41 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D591B42E6 for ; Mon, 7 Mar 2016 07:33:39 -0800 (PST) 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 GkidIFTWJ4YP for ; Mon, 7 Mar 2016 07:33:38 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 DBC351B42DC for ; Mon, 7 Mar 2016 07:33:37 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id g127so96320851ywf.2 for ; Mon, 07 Mar 2016 07:33:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=1WWFbXp51K5Cn+KsWpI3ngKu0NdUJsfaC1Ss+T60hoA=; b=TGz3+CHVuz8oenk+7Qp2j6Dq/tNW6GB0s9LrGxYp0EHrzXBhb+o5BTiUnCksFkYLFD vio8ymVRGasIYpkLDJOZvZmtzK3J+zJt8mQcoWjL1KMiyaw58iJ44B5ts3DPjVDVqouv +maLQT2EXSJUGYj8CssOnLJB0W2k05FIC8MA8IwumC+x8j0MEKyQU0ii0CmZb/0H/8Hl vREWgFIVS6SflcGdGc3ub5cQ14ruq2kZNOm0OaiLvDIV67G3gx0SvB/OKdK6y7m/TcYt hNu17Od1rS3YBHai6wrzA/zvPGV2pcFnn4sSNOCzHpJzF5AyYonBkxuziaRG7rLXkBK5 TFXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=1WWFbXp51K5Cn+KsWpI3ngKu0NdUJsfaC1Ss+T60hoA=; b=TsngNM4jijhNip4f8wu1a8V1PIloBWUTFrOU63Tv+/To6AM7J+JLU7+6A1K9cfIBW5 z2jL2XPPm5IVwugaE3LpEcaFu7m++nJGC64MXkKkT7NQMubiP9KcHuVII6BmQHToeuvX iv0KaOf4kLeVC+Ou2dhc50Y7xiByy1/7i5X8MdjpJtLrYxCNNPzO8H5n3P0HHpM8vVcg cPHnpBTlELa5+9CBNYUxkbDHc0gUKrBkJNjJb6JOYRz4q5m6fcSO+AkPefPEOC0xRapk BX6irqe9AKcHWb9AJH1lupWDc2GizObjFq9Lk3kT/K09qZXomCqIy/MUzxz6wpmJPFrC 2dZQ== X-Gm-Message-State: AD7BkJKEuCRu1z1RGdMyZ0iDbtLJ4iyRa0VrxcaFLI2ZaZ0cjhJq9iCh3o1QSDVDc23LygPdvMKZDFymCTc6nw== MIME-Version: 1.0 X-Received: by 10.129.34.133 with SMTP id i127mr13333539ywi.153.1457364817125; Mon, 07 Mar 2016 07:33:37 -0800 (PST) Received: by 10.37.105.196 with HTTP; Mon, 7 Mar 2016 07:33:37 -0800 (PST) Date: Mon, 7 Mar 2016 09:33:37 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=001a114091bc3ba80d052d7730af Archived-At: Subject: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 15:33:39 -0000 --001a114091bc3ba80d052d7730af Content-Type: text/plain; charset=UTF-8 Hi folks, This document has been proposed to be progressed as AD sponsored: https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updates/ The document has been carefully reviewed and it is now ready to move forward - Jean Mahoney is the shepherd. I don't anticipate anyone would have concerns about this decision, given that's how RFC 7315 was progressed and this update has actually been much more carefully reviewed. However, f anyone has any final comments, please post no later than Friday, March 11th, 2016. Note, that you will also still have IETF LC to provide any comments. Regards, Mary. --001a114091bc3ba80d052d7730af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

This document has been propos= ed to be progressed as AD sponsored:
The = document has been carefully reviewed and it is now ready to move forward - = Jean Mahoney is the shepherd. =C2=A0

I don'= ;t anticipate anyone would have concerns about this decision, given that= 9;s how RFC 7315 was progressed and this update has actually been much more= carefully reviewed.=C2=A0 However, f anyone has any final comments, please= post no later than Friday, March 11th, 2016.=C2=A0 Note, that you will als= o still have IETF LC to provide any comments.=C2=A0

Regards,
Mary.=C2=A0
--001a114091bc3ba80d052d7730af-- From nobody Mon Mar 7 12:08:49 2016 Return-Path: X-Original-To: dispatch@ietfc.amsl.com Delivered-To: dispatch@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CBA181CDAD4 for ; Mon, 7 Mar 2016 12:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_C7YtZif66i for ; Mon, 7 Mar 2016 12:08:46 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 9C9EF1CDACC for ; Mon, 7 Mar 2016 12:08:46 -0800 (PST) Received: from mutabilis-2.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u27K8jET058871 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 7 Mar 2016 14:08:46 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be mutabilis-2.local To: dispatch@ietf.org References: From: "A. Jean Mahoney" Message-ID: <56DDDFCD.5040604@nostrum.com> Date: Mon, 7 Mar 2016 14:08:45 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 20:08:48 -0000 Since this draft updates RFC 7315, which required expert review of its header fields, Adam Roach will be conducting an expert review of this draft according to the guidance given in RFC 5727. Thanks, Jean On 3/7/16 9:33 AM, Mary Barnes wrote: > Hi folks, > > This document has been proposed to be progressed as AD sponsored: > https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updates/ > The document has been carefully reviewed and it is now ready to move > forward - Jean Mahoney is the shepherd. > > I don't anticipate anyone would have concerns about this decision, given > that's how RFC 7315 was progressed and this update has actually been > much more carefully reviewed. However, f anyone has any final comments, > please post no later than Friday, March 11th, 2016. Note, that you will > also still have IETF LC to provide any comments. > > Regards, > Mary. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Tue Mar 8 18:47:32 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81E712DD8E for ; Tue, 8 Mar 2016 18:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.021 X-Spam-Level: X-Spam-Status: No, score=-5.021 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCvuPdCKtk8g for ; Tue, 8 Mar 2016 18:47:27 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 6D49212DD7F for ; Tue, 8 Mar 2016 18:47:27 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id 4E32D14474755; Wed, 9 Mar 2016 02:47:24 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u292lOoF027409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Mar 2016 02:47:25 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u292lLV9003725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Mar 2016 03:47:24 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.98]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 9 Mar 2016 03:47:23 +0100 From: "Drage, Keith (Nokia - GB)" To: "EXT Hutchison, Phil" , "'dispatch@ietf.org'" Thread-Topic: draft-weinronk-dispatch-last-diverting-line-id Thread-Index: AdF17qENyZLD+5A8QJOT25urfAPpQADvGqhw Date: Wed, 9 Mar 2016 02:47:23 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADE9B9DD@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <6F1F19576314274FB33F9F02948A9AAACC732DD8@kn2-mbx-p0001> In-Reply-To: <6F1F19576314274FB33F9F02948A9AAACC732DD8@kn2-mbx-p0001> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADE9B9DDFR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 02:47:31 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADE9B9DDFR712WXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can you explain where a proposed UK requirement comes from that is not cont= ained within the ETSI and ITU-T service definitions for the ISDN? Do you believe it is legacy from the early ISDN definitions or do you belie= ve it is new? I'd also note that I believe if this is required then an addition to the Hi= story-Info header field would be more appropriate. Regards Keith Drage From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of EXT Hutchiso= n, Phil Sent: 04 March 2016 08:20 To: 'dispatch@ietf.org' Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Hi, I believe that this is required in the UK, and therefore would like to see = the draft accepted. Regards Phil ~~~~~~~~~~~~~~~~~ Phil Hutchison Liberty Global CAO - Communications Architecture Mobile +447775 938827 | Soft Client +44(0)3703 900464 | Email phil.hutchiso= n@virginmedia.co.uk Meet Me Conference: 0808 1074444 [+44 1723204444] PIN 1256450# Visit www.virginmedia.co.uk for more informa= tion, and more fun Save paper - do you really need to print this email? -------------------------------------------------------------------- Save Paper - Do you really need to print this e-mail? Visit www.virginmedia.com for more information,= and more fun. This email and any attachments are or may be confidential and legally privi= leged and are sent solely for the attention of the addressee(s). If you have rece= ived this email in error, please delete it from your system: its use, disclosure or c= opying is unauthorised. Statements and opinions expressed in this email may not repre= sent those of Virgin Media. Any representations or commitments in this email are subject to contract. Registered office: Media House, Bartley Wood Business Park, Hook, Hampshire= , RG27 9UP Registered in England and Wales with number 2591237 --_000_949EF20990823C4C85C18D59AA11AD8BADE9B9DDFR712WXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can you explain where = a proposed UK requirement comes from that is not contained within the ETSI = and ITU-T service definitions for the ISDN?

 

Do you believe it is l= egacy from the early ISDN definitions or do you believe it is new?

 

I’d also note th= at I believe if this is required then an addition to the History-Info heade= r field would be more appropriate.

 

Regards

 

Keith Drage=

 

From: dispatch= [mailto:dispatch-bounces@ietf.org] On Behalf Of EXT Hutchison, Phil
Sent: 04 March 2016 08:20
To: 'dispatch@ietf.org'
Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id

 

Hi,

 

I believe that this is required in the UK, and therefore would li= ke to see the draft accepted.

 

Regards

 

Phil

~~~~~~~~~~~~~~~~~

Phil Hutchison<= span lang=3D"EN-GB" style=3D"font-size:12.0pt;font-family:"Times New R= oman","serif";color:#1F497D">

Liberty Global CAO<= /b> - Communications Archit= ecture

Mobile +447775 938827 | S= oft Client +44(0)3703 900464 | Email phil.hutchison@virginmedia.co= .uk

Meet Me Conference: 0808 1074444  [+44 172= 3204444] PIN 1256450#

Visit www.virginmedia.co.uk= for more information, and more fun

Save paper - do= you really need to print this email?

 


--------------------------------------------------------------------
Save Paper - Do you really need to print this e-mail?

Visit www.vi= rginmedia.com for more information, and more fun.

This email and any attachments are or may be confid= ential and legally privileged
and are sent solely for the attention of the addressee(s). If you have rece= ived this
email in error, please delete it from your system: its use, disclosure or c= opying is
unauthorised. Statements and opinions expressed in this email may not repre= sent
those of Virgin Media. Any representations or commitments in this email are=
subject to contract.

Registered office: Media House, Bartley Wood Busine= ss Park, Hook, Hampshire, RG27 9UP
Registered in England and Wales with number 2591237

--_000_949EF20990823C4C85C18D59AA11AD8BADE9B9DDFR712WXCHMBA11z_-- From nobody Wed Mar 9 03:05:22 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B232912D5DE for ; Wed, 9 Mar 2016 03:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btinternet.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MZPJhDBlxkJ for ; Wed, 9 Mar 2016 03:05:14 -0800 (PST) Received: from rgout0104.bt.lon5.cpcloud.co.uk (rgout0104.bt.lon5.cpcloud.co.uk [65.20.0.124]) by ietfa.amsl.com (Postfix) with ESMTP id 91DFD12D5A6 for ; Wed, 9 Mar 2016 03:05:13 -0800 (PST) X-OWM-Source-IP: 10.110.12.1 () X-OWM-Env-Sender: nweinronk@btinternet.com X-CTCH-RefID: str=0001.0A090204.56E00364.0049, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown X-RazorGate-Suspect: true Received: from webmail07.bt.ext.cpcloud.co.uk (10.110.12.1) by rgout01.bt.lon5.cpcloud.co.uk (8.6.122.06) (authenticated as nweinronk@btinternet.com) id 56B9DEA20319011A; Wed, 9 Mar 2016 11:05:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1457521513; bh=t2m/V7PbFMbzlKKp0SWmGSgXM9xkluYN4s5opxTBRP4=; h=Date:From:Reply-To:To:Message-ID:Subject:MIME-Version; b=nBD6NGN3WiK3KEojvhbjq32FHI6yNCPznrFxNlqa1/fL+F5tpw/DllrFzS3pdsJgwdvazv4Po6b9qsYogtyZbcIJzwnVWai4r8EocNedFTvAlRIKNkMmJbvwalqBjo2VrILO1WwKsj9AYO0odO+n1HqwNYlceHezEKpmKJbkH40= Date: Wed, 9 Mar 2016 11:05:08 +0000 (GMT) From: N WEINRONK To: keith.drage@nokia.com, dispatch@ietf.org Message-ID: <18432161.21187.1457521508041.JavaMail.defaultUser@defaultHost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_21186_4644852.1457521508020" X-CP-REPLY-UID: 25360 X-CP-REPLY-UID: 25360 X-CP-REPLY-UID: 25360 X-CP-REPLY-UID: 25360 X-CP-REPLY-UID: 25360 X-CP-REPLY-UID: 25360 X-CP-REPLY-UID: 25360 X-CP-REPLY-UID: 25360 X-CP-REPLY-UID: 25360 X-CP-REPLY-UID: 25360 X-CP-REPLY-UID: 25360 X-CP-REPLY-UID: 25360 X-CP-REPLY-PATH: INBOX X-CP-REPLY-PATH: INBOX X-CP-REPLY-PATH: INBOX X-CP-REPLY-PATH: INBOX X-CP-REPLY-PATH: INBOX X-CP-REPLY-PATH: INBOX X-CP-REPLY-PATH: INBOX X-CP-REPLY-PATH: INBOX X-CP-REPLY-PATH: INBOX X-CP-REPLY-PATH: INBOX X-CP-REPLY-PATH: INBOX X-CP-REPLY-PATH: INBOX Importance: 3 (Normal) X-Priority: 3 (Normal) X-Client-IP: IPv4[86.145.180.157] Epoch[1457521508020] Archived-At: Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nweinronk@btinternet.com List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 11:05:21 -0000 ------=_Part_21186_4644852.1457521508020 Content-Type: multipart/alternative; boundary="----=_Part_21185_31492369.1457521508020" ------=_Part_21185_31492369.1457521508020 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for your comments on this Internet Draft =E2=80=93 I will try and answer your points. Do you believe it is legacy from the early ISDN definitions or do you believe it is new?=20 Neither it a consequence of the way ETSI ISDN was implemented in the UK in the 1990s that is still in use today =E2=80=93 see= below. Note: I assume by early ISDN definitions you mean where ETSI ISDN was mappe= d to DASS and I am not talking about this. Can you explain where a proposed UK requirement comes from that is not contained within the ETSI and ITU-T service definitions for the ISDN?=20 This comes from current implementations in the UK based on NICC ND1007. In UK ISUP there is a parameter optional in the IAM =E2=80=93 Last Diverted Line Identity in additional to the ITU/ETSI parameter Redirecting Number. There are times when these parameters are both present and can hold different information. You could see this as being analogous to FROM and P-Asserted-Id headers in SIP with the Last Diverted Line Identity parameter= being the =E2=80=98network asserted identity=E2=80=99 used by networks other that= the network diverting the call to verify service and the Redirecting Number parameter b= eing the =E2=80=98presentation number=E2=80=99. The cases I am aware of where these parameters can hold different information come from ETSI ISDN diversion scenarios =E2=80=93 Cal= l Forwarding Unconditional / Call Forwarding Busy / Call Forwarding No Reply / Call Deflection / Partial Rerouting. For Partial Rerouting the Last Diverted Line Identity parameter is based on the =E2=80=98administration number=E2=80=99 as unders= tood by the network doing the diversion and the network doing the verification and billing for these calls. The Redirecting Number parameter is set from the lastRerouting= Nr from the ASN.1 the private network sets in the Q.931 SETUP message =E2=80= =93 these can/will be different. For Call Forwarding Unconditional / Call Forwarding Busy / Call Forwarding No Reply / Call Deflection the Last Diverted Line Identity = parameter is based on the =E2=80=98administration number=E2=80=99 as understood by th= e network doing the diversion and the network doing the verification and billing for these call= s. The Redirecting Number parameter is set to the Called Party Number used to = reach the diverting party =E2=80=93 these are not necessarily the same. I=E2=80=99d also note that I believe if this is required then an addition t= o the History-Info header field would be more appropriate.=20 We (myself and the UK NICC SIP Task Group) did consider using the History-Info header for this but as the mappings are already defi= ned from Redirecting Number parameter to History-Info by the IETF / ETSI / ITU = it was felt this would be confusing and make the mappings complicated. Also I would expect this header to (like the Last Diverted Line Identity parameter in UK ISUP) be limited in where it can be sent ie. between network operators and not to end users again making use of History-= Info more complicated. Nigel Weinronk ----Original message---- >From : keith.drage@nokia.com Date : 09/03/2016 - 02:47 (GMTST) To : Phil.Hutchison@virginmedia.co.uk, dispatch@ietf.org Subject : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Can you explain where a proposed UK requirement comes from that is not cont= ained within the ETSI and ITU-T service definitions for the ISDN? =20 Do you believe it is legacy from the early ISDN definitions or do you belie= ve it is new? =20 I=E2=80=99d also note that I believe if this is required then an addition t= o the History-Info header field would be more appropriate. =20 Regards =20 Keith Drage =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of EXT Hutchison, Phil Sent: 04 March 2016 08:20 To: 'dispatch@ietf.org' Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 Hi, =20 I believe that this is required in the UK, and therefore would like to see = the draft accepted. =20 Regards =20 Phil ~~~~~~~~~~~~~~~~~ Phil Hutchison Liberty Global CAO - Communications Architecture Mobile +447775 938827 | Soft Client +44(0)3703 900464 | Email phil.hutchison@virginmedia.co.uk Meet Me Conference: 0808 1074444 [+44 1723204444] PIN 1256450# Visit www.virginmedia.co.uk for more information, and more fun Save paper - do you really need to print this email? =20 -------------------------------------------------------------------- Save Paper - Do you really need to print this e-mail? Visit www.virginmedia.com for more information, and more fun. This email and any attachments are or may be confidential and legally privi= leged and are sent solely for the attention of the addressee(s). If you have rece= ived this email in error, please delete it from your system: its use, disclosure or c= opying is unauthorised. Statements and opinions expressed in this email may not repre= sent those of Virgin Media. Any representations or commitments in this email are subject to contract.=20 Registered office: Media House, Bartley Wood Business Park, Hook, Hampshire= , RG27 9UP Registered in England and Wales with number 2591237 ------=_Part_21185_31492369.1457521508020 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


=

Thank you for = your comments on this Internet Draft =E2=80=93 I will try and answer your points.

Do you believe= it is legacy from the early ISDN definitions or do you believe it is new?

Neither it = a consequence of the way ETSI ISDN was implemented in the UK in the 1990s that is still in use today =E2=80= =93 see below.

Note: I assume by early ISDN definitions you mean where ETSI ISDN wa= s mapped to DASS and I am not talking about this.

Can you explai= n where a proposed UK requirement comes from that is not contained within the ETSI and ITU-T service definitions for the ISDN?

This comes = from current implementations in the UK based on NICC ND1007.

In UK ISUP = there is a parameter optional in the IAM =E2=80=93 Last Diverted Line Identity in additional to the ITU/ETSI parameter Redirecting Number.

There are t= imes when these parameters are both present and can hold different information.

You could s= ee this as being analogous to FROM and P-Asserted-Id headers in SIP with the Last Diverted Line Identity parameter= being the =E2=80=98network asserted identity=E2=80=99 used by networks other that= the network diverting the call to verify service and the Redirecting Number parameter b= eing the =E2=80=98presentation number=E2=80=99.

The cases I= am aware of where these parameters can hold different information come from ETSI ISDN diversion scenarios =E2=80=93 Cal= l Forwarding Unconditional / Call Forwarding Busy / Call Forwarding No Reply / Call Deflection / Partial Rerouting.

For Partial= Rerouting the Last Diverted Line Identity parameter is based on the =E2=80=98administration number=E2=80=99 as unders= tood by the network doing the diversion and the network doing the verification and billing for these calls. The Redirecting Number parameter is set from the lastRerouting= Nr from the ASN.1 the private network sets in the Q.931 SETUP message =E2=80= =93 these can/will be different.

For Call Fo= rwarding Unconditional / Call Forwarding Busy / Call Forwarding No Reply / Call Deflection the Last Diverted Line Identity = parameter is based on the =E2=80=98administration number=E2=80=99 as understood by th= e network doing the diversion and the network doing the verification and billing for these call= s. The Redirecting Number parameter is set to the Called Party Number used to = reach the diverting party =E2=80=93 these are not necessarily the same.

I=E2=80=99d al= so note that I believe if this is required then an addition to the History-Info header field would be more appropriate.

We (myself = and the UK NICC SIP Task Group) did consider using the History-Info header for this but as the mappings are already defi= ned from Redirecting Number parameter to History-Info by the IETF / ETSI / ITU = it was felt this would be confusing and make the mappings complicated.<= /p>

Also I woul= d expect this header to (like the Last Diverted Line Identity parameter in UK ISUP) be limited in where it can be sent ie. between network operators and not to end users again making use of History-= Info more complicated.

Nigel Weinr= onk


----= Original message----
From : keith.drage@nokia.com
Date : 09/03/2016 -= 02:47 (GMTST)
To : Phil.Hutchison@virginmedia.co.uk, dispatch@ietf.org<= br>Subject : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id<= br>

Can you exp= lain where a proposed UK requirement comes from that is not contained withi= n the ETSI and ITU-T service definitions for the ISDN?

 =

Do you beli= eve it is legacy from the early ISDN definitions or do you believe it is ne= w?

 =

I=E2=80=99d= also note that I believe if this is required then an addition to the Histo= ry-Info header field would be more appropriate.

 =

Regards

 =

Keith Drage=

 =

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of EXT Hutchison, Phil
Sent: 04 March 2016 08:20
To: 'dispatch@ietf.org'
Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id

 

Hi,

 

I believe that this is required in the UK, and therefo= re would like to see the draft accepted.

 

Regards

 

Phil

~~~~~~~~~~~~~~~~~

Phil Hutchison

Liberty Global CAO - Communications Architecture

Mobile +447775 938827 | Soft Client +44(0= )3703 900464 | Email phil.hutchison@virginmedia.co.uk

Meet Me Conference: 0808 1074444  [+44 1723204444] PIN 1256450#

Visit www.virginmedia.co.uk for more information, and more fun

Save paper - do you really need= to print this email?

 


--------------------------------------------------------------------
Save Paper - Do you really need to print this e-mail?

Visit www.vi= rginmedia.com for more information, and more fun.

This email and any attachments are or may be confid= ential and legally privileged
and are sent solely for the attention of the addressee(s). If you have rece= ived this
email in error, please delete it from your system: its use, disclosure or c= opying is
unauthorised. Statements and opinions expressed in this email may not repre= sent
those of Virgin Media. Any representations or commitments in this email are=
subject to contract.

Registered office: Media House, Bartley Wood Busine= ss Park, Hook, Hampshire, RG27 9UP
Registered in England and Wales with number 2591237



------=_Part_21185_31492369.1457521508020-- ------=_Part_21186_4644852.1457521508020-- From nobody Wed Mar 9 08:15:12 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA14312D6BC for ; Wed, 9 Mar 2016 08:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OadRjnPgzSyu for ; Wed, 9 Mar 2016 08:13:32 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C7612E0AF for ; Wed, 9 Mar 2016 08:07:03 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E852B22CB33; Wed, 9 Mar 2016 17:07:01 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C441F27C053; Wed, 9 Mar 2016 17:07:01 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0279.002; Wed, 9 Mar 2016 17:07:01 +0100 From: To: DISPATCH Thread-Topic: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored Thread-Index: AQHReIa8W+0pDv/OfkidWJiHogr6Pp9RQm2g Date: Wed, 9 Mar 2016 16:07:01 +0000 Message-ID: <6303_1457539621_56E04A25_6303_1866_1_8B970F90C584EA4E97D5BAAC9172DBB815846652@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB815846652OPEXCLILMA4corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.8.144518 Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 16:13:34 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB815846652OPEXCLILMA4corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgZG8gc3VwcG9ydCB0aGlzIGRyYWZ0IHRvIGJlIHByb2dyZXNzZWQgYXMgQUQgc3Bv bnNvcmVkLg0KDQpIb3dldmVyLCBJIGhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50OiBJbiBzZWN0 aW9uIDQuIEkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIHRvIGFkZCBhIHRhYmxlIGFmdGVyIHRo ZSDigJxuZXcgdGV4dOKAnSBwYXJhZ3JhcGggdGhhdCBzdW1tYXJpemUgd2hlcmUgdGhlIGRpZmZl cmVudCBoZWFkZXIgZmllbGRzIGNhbiBhcHBlYXIgYXMgaXQgd2FzIGRvbmUgaW4gc2VjdGlvbiA1 Ljcgb2YgUkZDIDM0NTUuDQoNCkJlc3QgUmVnYXJkcywNCk1hcmlhbm5lIE1vaGFsaQ0KDQpEZSA6 IGRpc3BhdGNoIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBk ZSBNYXJ5IEJhcm5lcw0KRW52b3nDqSA6IGx1bmRpIDcgbWFycyAyMDE2IDE2OjM0DQrDgCA6IERJ U1BBVENIDQpPYmpldCA6IFtkaXNwYXRjaF0gUHJvZ3Jlc3NpbmcgZHJhZnQtaG9sbWJlcmctZGlz cGF0Y2gtcmZjNzMxNS11cGRhdGVzIGFzIEFEIHNwb25zb3JlZA0KDQpIaSBmb2xrcywNCg0KVGhp cyBkb2N1bWVudCBoYXMgYmVlbiBwcm9wb3NlZCB0byBiZSBwcm9ncmVzc2VkIGFzIEFEIHNwb25z b3JlZDoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhvbG1iZXJnLWRp c3BhdGNoLXJmYzczMTUtdXBkYXRlcy8NClRoZSBkb2N1bWVudCBoYXMgYmVlbiBjYXJlZnVsbHkg cmV2aWV3ZWQgYW5kIGl0IGlzIG5vdyByZWFkeSB0byBtb3ZlIGZvcndhcmQgLSBKZWFuIE1haG9u ZXkgaXMgdGhlIHNoZXBoZXJkLg0KDQpJIGRvbid0IGFudGljaXBhdGUgYW55b25lIHdvdWxkIGhh dmUgY29uY2VybnMgYWJvdXQgdGhpcyBkZWNpc2lvbiwgZ2l2ZW4gdGhhdCdzIGhvdyBSRkMgNzMx NSB3YXMgcHJvZ3Jlc3NlZCBhbmQgdGhpcyB1cGRhdGUgaGFzIGFjdHVhbGx5IGJlZW4gbXVjaCBt b3JlIGNhcmVmdWxseSByZXZpZXdlZC4gIEhvd2V2ZXIsIGYgYW55b25lIGhhcyBhbnkgZmluYWwg Y29tbWVudHMsIHBsZWFzZSBwb3N0IG5vIGxhdGVyIHRoYW4gRnJpZGF5LCBNYXJjaCAxMXRoLCAy MDE2LiAgTm90ZSwgdGhhdCB5b3Ugd2lsbCBhbHNvIHN0aWxsIGhhdmUgSUVURiBMQyB0byBwcm92 aWRlIGFueSBjb21tZW50cy4NCg0KUmVnYXJkcywNCk1hcnkuDQoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBl dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2 b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy CmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50 ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy YXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5v dCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3Uu Cgo= --_000_8B970F90C584EA4E97D5BAAC9172DBB815846652OPEXCLILMA4corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkbyBzdXBwb3J0IHRo aXMgZHJhZnQgdG8gYmUgcHJvZ3Jlc3NlZCBhcyBBRCBzcG9uc29yZWQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIEkgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1l bnQ6IEluIHNlY3Rpb24gNC4gSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gYWRkIGEgdGFi bGUgYWZ0ZXIgdGhlIOKAnG5ldyB0ZXh04oCdIHBhcmFncmFwaCB0aGF0IHN1bW1hcml6ZSB3aGVy ZQ0KIHRoZSBkaWZmZXJlbnQgaGVhZGVyIGZpZWxkcyBjYW4gYXBwZWFyIGFzIGl0IHdhcyBkb25l IGluIHNlY3Rpb24gNS43IG9mIFJGQyAzNDU1LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5NYXJpYW5uZSBNb2hhbGk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gZGlzcGF0Y2ggW21haWx0bzpkaXNwYXRjaC1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gTWFyeSBCYXJuZXM8YnI+DQo8Yj5F bnZvecOpJm5ic3A7OjwvYj4gbHVuZGkgNyBtYXJzIDIwMTYgMTY6MzQ8YnI+DQo8Yj7DgCZuYnNw Ozo8L2I+IERJU1BBVENIPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBbZGlzcGF0Y2hdIFByb2dy ZXNzaW5nIGRyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXJmYzczMTUtdXBkYXRlcyBhcyBBRCBzcG9u c29yZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBmb2xrcyw8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZG9jdW1lbnQg aGFzIGJlZW4gcHJvcG9zZWQgdG8gYmUgcHJvZ3Jlc3NlZCBhcyBBRCBzcG9uc29yZWQ6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1y ZmM3MzE1LXVwZGF0ZXMvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1o b2xtYmVyZy1kaXNwYXRjaC1yZmM3MzE1LXVwZGF0ZXMvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRvY3VtZW50IGhhcyBiZWVuIGNh cmVmdWxseSByZXZpZXdlZCBhbmQgaXQgaXMgbm93IHJlYWR5IHRvIG1vdmUgZm9yd2FyZCAtIEpl YW4gTWFob25leSBpcyB0aGUgc2hlcGhlcmQuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0IGFudGljaXBhdGUgYW55b25l IHdvdWxkIGhhdmUgY29uY2VybnMgYWJvdXQgdGhpcyBkZWNpc2lvbiwgZ2l2ZW4gdGhhdCdzIGhv dyBSRkMgNzMxNSB3YXMgcHJvZ3Jlc3NlZCBhbmQgdGhpcyB1cGRhdGUgaGFzIGFjdHVhbGx5IGJl ZW4gbXVjaCBtb3JlIGNhcmVmdWxseSByZXZpZXdlZC4mbmJzcDsgSG93ZXZlciwgZiBhbnlvbmUg aGFzIGFueSBmaW5hbCBjb21tZW50cywgcGxlYXNlIHBvc3Qgbm8gbGF0ZXINCiB0aGFuIEZyaWRh eSwgTWFyY2ggMTF0aCwgMjAxNi4mbmJzcDsgTm90ZSwgdGhhdCB5b3Ugd2lsbCBhbHNvIHN0aWxs IGhhdmUgSUVURiBMQyB0byBwcm92aWRlIGFueSBjb21tZW50cy4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1hcnkuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u YwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlv bi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBz aWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNo b3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNh dGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1l c3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhh bmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_8B970F90C584EA4E97D5BAAC9172DBB815846652OPEXCLILMA4corp_-- From nobody Wed Mar 9 09:29:08 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1C012E0B5 for ; Wed, 9 Mar 2016 09:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia3VwJA69aB9 for ; Wed, 9 Mar 2016 09:22:50 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E02812E0DC for ; Wed, 9 Mar 2016 09:20:09 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Wed, 9 Mar 2016 09:20:09 -0800 From: Michael Hammer To: "nweinronk@btinternet.com" , "keith.drage@nokia.com" , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Thread-Index: AQHRefOYNbUr3nADm0Si2d+pQhImgJ9RWrvA Date: Wed, 9 Mar 2016 17:20:08 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BC187888@sc9-ex2k10mb1.corp.yaanatech.com> References: <18432161.21187.1457521508041.JavaMail.defaultUser@defaultHost> In-Reply-To: <18432161.21187.1457521508041.JavaMail.defaultUser@defaultHost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.70] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0050_01D179FE.04382EE0" MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 17:22:53 -0000 ------=_NextPart_000_0050_01D179FE.04382EE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0051_01D179FE.04382EE0" ------=_NextPart_001_0051_01D179FE.04382EE0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable There is a danger here that this purpose could be supported by two = different headers=20 (a new header or an old header) with potential negative consequences. =20 Please show what prevents you from supporting this purpose with = History-Info? =20 The argument that because A is supported by B, therefore C is not = supported by B, is illogical. =20 ________________________________ Michael Hammer michael.hammer@yaanatech.com =20 +1 408 202 9291 =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email = confidentiality notice. This message is private and confidential. If you = have received this message in error, please notify us and remove it from = your system. =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of N = WEINRONK Sent: Wednesday, March 09, 2016 6:05 AM To: keith.drage@nokia.com; dispatch@ietf.org Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 =20 Thank you for your comments on this Internet Draft =E2=80=93 I will try = and answer your points. Do you believe it is legacy from the early ISDN definitions or do you = believe it is new?=20 Neither it a consequence of the way ETSI ISDN was implemented in the UK = in the 1990s that is still in use today =E2=80=93 see below. Note: I assume by early ISDN definitions you mean where ETSI ISDN was = mapped to DASS and I am not talking about this. Can you explain where a proposed UK requirement comes from that is not = contained within the ETSI and ITU-T service definitions for the ISDN?=20 This comes from current implementations in the UK based on NICC ND1007. In UK ISUP there is a parameter optional in the IAM =E2=80=93 Last = Diverted Line Identity in additional to the ITU/ETSI parameter = Redirecting Number. There are times when these parameters are both present and can hold = different information. You could see this as being analogous to FROM and P-Asserted-Id headers = in SIP with the Last Diverted Line Identity parameter being the = =E2=80=98network asserted identity=E2=80=99 used by networks other that = the network diverting the call to verify service and the Redirecting = Number parameter being the =E2=80=98presentation number=E2=80=99. The cases I am aware of where these parameters can hold different = information come from ETSI ISDN diversion scenarios =E2=80=93 Call = Forwarding Unconditional / Call Forwarding Busy / Call Forwarding No = Reply / Call Deflection / Partial Rerouting. For Partial Rerouting the Last Diverted Line Identity parameter is based = on the =E2=80=98administration number=E2=80=99 as understood by the = network doing the diversion and the network doing the verification and = billing for these calls. The Redirecting Number parameter is set from = the lastReroutingNr from the ASN.1 the private network sets in the Q.931 = SETUP message =E2=80=93 these can/will be different. For Call Forwarding Unconditional / Call Forwarding Busy / Call = Forwarding No Reply / Call Deflection the Last Diverted Line Identity = parameter is based on the =E2=80=98administration number=E2=80=99 as = understood by the network doing the diversion and the network doing the = verification and billing for these calls. The Redirecting Number = parameter is set to the Called Party Number used to reach the diverting = party =E2=80=93 these are not necessarily the same. I=E2=80=99d also note that I believe if this is required then an = addition to the History-Info header field would be more appropriate.=20 We (myself and the UK NICC SIP Task Group) did consider using the = History-Info header for this but as the mappings are already defined = from Redirecting Number parameter to History-Info by the IETF / ETSI / = ITU it was felt this would be confusing and make the mappings = complicated. Also I would expect this header to (like the Last Diverted Line Identity = parameter in UK ISUP) be limited in where it can be sent ie. between = network operators and not to end users again making use of History-Info = more complicated. Nigel Weinronk =20 ----Original message---- >From : keith.drage@nokia.com =20 Date : 09/03/2016 - 02:47 (GMTST) To : Phil.Hutchison@virginmedia.co.uk = , dispatch@ietf.org = =20 Subject : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Can you explain where a proposed UK requirement comes from that is not = contained within the ETSI and ITU-T service definitions for the ISDN? =20 Do you believe it is legacy from the early ISDN definitions or do you = believe it is new? =20 I=E2=80=99d also note that I believe if this is required then an = addition to the History-Info header field would be more appropriate. =20 Regards =20 Keith Drage =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of EXT = Hutchison, Phil Sent: 04 March 2016 08:20 To: 'dispatch@ietf.org' Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 Hi, =20 I believe that this is required in the UK, and therefore would like to = see the draft accepted. =20 Regards =20 Phil=20 ~~~~~~~~~~~~~~~~~=20 Phil Hutchison=20 Liberty Global CAO - Communications Architecture=20 Mobile +447775 938827 | Soft Client +44(0)3703 900464 | Email = = phil.hutchison@virginmedia.co.uk=20 Meet Me Conference: 0808 1074444 [+44 1723204444] PIN 1256450# Visit www.virginmedia.co.uk for more = information, and more fun=20 Save paper - do you really need to print this email? =20 -------------------------------------------------------------------- Save Paper - Do you really need to print this e-mail? Visit www.virginmedia.com for more = information, and more fun. This email and any attachments are or may be confidential and legally = privileged and are sent solely for the attention of the addressee(s). If you have = received this email in error, please delete it from your system: its use, disclosure = or copying is unauthorised. Statements and opinions expressed in this email may not = represent those of Virgin Media. Any representations or commitments in this email = are subject to contract.=20 Registered office: Media House, Bartley Wood Business Park, Hook, = Hampshire, RG27 9UP Registered in England and Wales with number 2591237 =20 =20 ------=_NextPart_001_0051_01D179FE.04382EE0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

There is a danger here that this purpose could = be supported by two different headers

(a new header or an old = header) with potential negative consequences.

 

Please show what = prevents you from supporting this purpose with = History-Info?

 

The argument that = because A is supported by B, therefore C is not supported by B, is = illogical.

 

________________________________=

Michael Hammer

michael.hammer@yaanatech.com=

+1 408 202 9291


=C2=A9 = 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality = notice. This message is private and confidential. If you have received = this message in error, please notify us and remove it from your = system.

 

From: dispatch = [mailto:dispatch-bounces@ietf.org] On Behalf Of N = WEINRONK
Sent: Wednesday, March 09, 2016 6:05 AM
To: = keith.drage@nokia.com; dispatch@ietf.org
Subject: Re: = [dispatch] = draft-weinronk-dispatch-last-diverting-line-id

 

 

Thank you = for your comments on this Internet Draft =E2=80=93 I will try and answer = your points.

Do you believe it is = legacy from the early ISDN definitions or do you believe it is new? =

Neither it = a consequence of the way ETSI ISDN was implemented in the UK in the = 1990s that is still in use today =E2=80=93 see = below.

Note: I = assume by early ISDN definitions you mean where ETSI ISDN was mapped to = DASS and I am not talking about this.

Can you explain where = a proposed UK requirement comes from that is not contained within the = ETSI and ITU-T service definitions for the ISDN? =

This comes = from current implementations in the UK based on NICC = ND1007.

In UK ISUP = there is a parameter optional in the IAM =E2=80=93 Last Diverted Line = Identity in additional to the ITU/ETSI parameter Redirecting = Number.

There are = times when these parameters are both present and can hold different = information.

You could = see this as being analogous to FROM and P-Asserted-Id headers in SIP = with the Last Diverted Line Identity parameter being the = =E2=80=98network asserted identity=E2=80=99 used by networks other that = the network diverting the call to verify service and the Redirecting = Number parameter being the =E2=80=98presentation = number=E2=80=99.

The cases = I am aware of where these parameters can hold different information come = from ETSI ISDN diversion scenarios =E2=80=93 Call Forwarding = Unconditional / Call Forwarding Busy / Call Forwarding No Reply / Call = Deflection / Partial Rerouting.

For = Partial Rerouting the Last Diverted Line Identity parameter is based on = the =E2=80=98administration number=E2=80=99 as understood by the network = doing the diversion and the network doing the verification and billing = for these calls. The Redirecting Number parameter is set from the = lastReroutingNr from the ASN.1 the private network sets in the Q.931 = SETUP message =E2=80=93 these can/will be = different.

For Call = Forwarding Unconditional / Call Forwarding Busy / Call Forwarding No = Reply / Call Deflection the Last Diverted Line Identity parameter is = based on the =E2=80=98administration number=E2=80=99 as understood by = the network doing the diversion and the network doing the verification = and billing for these calls. The Redirecting Number parameter is set to = the Called Party Number used to reach the diverting party =E2=80=93 = these are not necessarily the same.

I=E2=80=99d also note = that I believe if this is required then an addition to the History-Info = header field would be more appropriate.

We (myself = and the UK NICC SIP Task Group) did consider using the History-Info = header for this but as the mappings are already defined from Redirecting = Number parameter to History-Info by the IETF / ETSI / ITU it was felt = this would be confusing and make the mappings = complicated.

Also I = would expect this header to (like the Last Diverted Line Identity = parameter in UK ISUP) be limited in where it can be sent ie. between = network operators and not to end users again making use of History-Info = more complicated.

Nigel = Weinronk

 

----Original message----
From : keith.drage@nokia.com
Date = : 09/03/2016 - 02:47 (GMTST)
To : Phil.Hutchison@virginmed= ia.co.uk, dispatch@ietf.org
Subject : Re: = [dispatch] draft-weinronk-dispatch-last-diverting-line-id

Can you explain where a proposed UK requirement = comes from that is not contained within the ETSI and ITU-T service = definitions for the ISDN?

 

Do you believe it is = legacy from the early ISDN definitions or do you believe it is = new?

 

I=E2=80=99d also note = that I believe if this is required then an addition to the History-Info = header field would be more appropriate.

 

Regards

 

Keith = Drage

 

From: = dispatch [mailto:dispatch-bounces@ietf.or= g] On Behalf Of EXT Hutchison, Phil
Sent: 04 March = 2016 08:20
To: 'dispatch@ietf.org'
Subject: = [dispatch] = draft-weinronk-dispatch-last-diverting-line-id

 

Hi,

 

I believe that this is required = in the UK, and therefore would like to see the draft = accepted.

 

Regards

 

Phil=

~~~~= ~~~~~~~~~~~~~

Phil= Hutchison

Libe= rty Global CAO - Comm= unications Architecture

Mobi= le +447775 938827 | Soft Client +44(0)3703 900464 | Email phil.hutchison@virginmedia.co.uk=

Meet= Me Conference: 0808= 1074444  [+44 1723204444] PIN = 1256450#

Visi= t www.virginmedia.co.uk= = for more information, and more fun

Save= paper - do you really need to print this email?

 


--------------------------------------------------------= ------------
Save Paper - Do you really need to print this = e-mail?

Visit www.virginmedia.com for more = information, and more fun.

This email and any attachments are or may be confidential = and legally privileged
and are sent solely for the attention of the = addressee(s). If you have received this
email in error, please delete = it from your system: its use, disclosure or copying is
unauthorised. = Statements and opinions expressed in this email may not = represent
those of Virgin Media. Any representations or commitments = in this email are
subject to contract.

Registered office: Media House, Bartley Wood Business Park, = Hook, Hampshire, RG27 9UP
Registered in England and Wales with number = 2591237

 

 

------=_NextPart_001_0051_01D179FE.04382EE0-- ------=_NextPart_000_0050_01D179FE.04382EE0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8DCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBmAwggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJ KoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAw MDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFu dGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2Fm TDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNN RNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0aNomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZ BP+gfz+j25FFdmaja/OFI15O2YVddaegFffBAHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6kl QrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gz AgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJLTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9v YIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMp IDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcC ARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5z eW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEFBQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVn Mc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGiSNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlU zd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5sZ8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs 1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAq WDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7eDROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gu d1wnwTkwggdrMIIGU6ADAgECAhBMAzfzqk7mKu8vbItErxUIMA0GCSqGSIb3DQEBBQUAMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1l ZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDIyOTAwMDAwMFoXDTE4MDIyODIzNTk1 OVoweTEXMBUGA1UEAwwOTWljaGFlbCBIYW1tZXIxDzANBgNVBAsMBlMvTUlNRTEgMB4GA1UECgwX WWFhbmEgVGVjaG5vbG9naWVzLCBMTEMxKzApBgkqhkiG9w0BCQEWHG1pY2hhZWwuaGFtbWVyQHlh YW5hdGVjaC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWEk4s5ORfNfQ/oXDD k4mHDQDDpO3s2oEy7055JdLoleNQXEJGsv8EsqPagYul55uVZ57tmx2H1LjM6QfD7N821joisKa4 +l92JImsffrTnll8gxJ9VV9/WmGpPWwFg4ipw3qRdDhQJnQiNKzlqPMSIDE76uhrKv3hYE30tVIO R8U9erAprCBoHd2Ch1+pIGlFjl91//BR1sehnJR9Z1gZHMEqjto/jYPR1uEapueR6W+YuL9O9HmW RLA925xiZmzwKqB8HS0wG+PjLnMRnohdIh4e+/FKWksC82rP7vmP3SHOzQKdgdapaavCTx/1ZYiR N6cMT95ZCgB1aHXR1lCfAgMBAAGjggOcMIIDmDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF oDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFFaFSmgtcRDwfRFi qt3Vq8LJCLn5MCcGA1UdEQQgMB6BHG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20wHwYDVR0j BBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFxBggrBgEFBQcBAQSCAWMwggFfMCcGCCsGAQUF BzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5jb20wggEyBggrBgEFBQcwAoaCASRsZGFwOi8v ZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUzRCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIw U2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUz RCUyMENsYXNzJTIwMiUyME1hbmFnZWQlMjBQS0klMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUy MENBJTJDT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBT eW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5 MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0 NzdjZjRmNmJlOTZhZjFiMzZjYWJkMzE2L0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgB hvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEF BQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqG SIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUB EAMEHjAcBhJghkgBhvhFARABAgIBAYabp24WBjE4NzIwOTA5BgpghkgBhvhFARAFBCswKQIBABYk YUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQBX iSRv04vVx/Y5lWWITUJhWXUTnhM70UUqIEinNF+cV9+zY0lomYqoB8ovCfWrvx232tzX86NtreSn 9UjhBRj61oqSyK9v6P14dunX1MjRZmOVeKws3+XDS3NPsopui5YOPjSy02qhyVN4tIDCokj71db1 wO7uZ/DehNWkwFUgMKdVKM5LAGIDHgWn2dvzGi+ipdDNjMD2SxMnCSOiZ3z9gh/Yy+flNaXn5vLL O0AJEW5xCl2tbuPh/DghqlaiVeCLaCar3cj2Ka6ew5wRhNpvmno47b0C5w6JDxx++ijXjGPzYr57 J8QvCDs9f3Cn5doEF3bTQmcab+s3VEgIhAt1MYIE4zCCBN8CAQEwgd4wgckxCzAJBgNVBAYTAlVT MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkCEEwDN/OqTuYq7y9si0SvFQgwCQYFKw4DAhoFAKCCAtkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMzA5MTcyMDA2WjAjBgkqhkiG 9w0BCQQxFgQUlmpmRL/t8/T4CbRBq73Y2LboFiAwgZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgB ZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglg hkgBZQMEAgEwge8GCSsGAQQBgjcQBDGB4TCB3jCByTELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UE AxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRlIEF1dGhv cml0eQIQTAM386pO5irvL2yLRK8VCDCB8QYLKoZIhvcNAQkQAgsxgeGggd4wgckxCzAJBgNVBAYT AlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1 c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEEwDN/OqTuYq7y9si0SvFQgwDQYJKoZIhvcNAQEBBQAEggEA ESJjrENRHdZZJjQQ4y4yQibW6o6Ag8C7kf5PZ/neBIAObHHPQTwTJ8DiCRt3jQdlz5Ck496zvRI1 77iCENX9zmLEfMSGiwAPpPWZCV+sjleByrVobKEMt2d5RTcV4VpMH+0d20f/o5ZRyQo5VHjckf0/ WNREyuwXpJbC8G8KZcn4r80ZdW+Cpf7hRtVB0o+Aug1u8ppMNMi0Sg9/qMmOQgm/9SSEIr3OiLLE qPjGFYn+2mZqyzEn7wdU4m+4qErmFvxUeZv3yF735jIccx6BIp7VhgNyPWuIbravpIyoA+FXyOoK wiU6+lS5JIHpfsAu2inNp4sqPF9EHLch5qvangAAAAAAAA== ------=_NextPart_000_0050_01D179FE.04382EE0-- From nobody Wed Mar 9 10:59:50 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4903F12D924 for ; Wed, 9 Mar 2016 10:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btinternet.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIsiCJW40UG9 for ; Wed, 9 Mar 2016 10:59:42 -0800 (PST) Received: from rgout02.bt.lon5.cpcloud.co.uk (rgout02.bt.lon5.cpcloud.co.uk [65.20.0.179]) by ietfa.amsl.com (Postfix) with ESMTP id DF6C812D55E for ; Wed, 9 Mar 2016 10:59:41 -0800 (PST) X-OWM-Source-IP: 10.110.12.2 () X-OWM-Env-Sender: nweinronk@btinternet.com X-CTCH-RefID: str=0001.0A090202.56E07299.009A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-Junkmail-Premium-Raw: score=12/50, refid=2.7.2:2016.3.9.171516:17:12.271, ip=, rules=__HAS_FROM, __PHISH_FROM2, __FRAUD_WEBMAIL_FROM, FROM_NAME_ALLCAPS, __HAS_REPLYTO, __FRAUD_WEBMAIL_REPLYTO, __TO_MALFORMED_2, __TO_NO_NAME, __HAS_MSGID, __SANE_MSGID, INVALID_MSGID_NO_FQDN, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_PRIORITY, __REPLYTO_SAMEAS_FROM_ADDY, __REPLYTO_SAMEAS_FROM_ACC, __REPLYTO_SAMEAS_FROM_DOMAIN, __ANY_URI, __FRAUD_BODY_WEBMAIL, __FRAUD_INTRO, __FRAUD_CONTACT_NAME, __CANPHARM_COPYRIGHT, __C230066_P5, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __HTML_FONT_BLUE, __FORWARDED_MSG, __HAS_HTML, HTML_NO_HTTP, BODY_SIZE_10000_PLUS, BODYTEXTH_SIZE_3000_MORE, __MIME_HTML, __STYLE_RATWARE_NEG, __URI_NS, HTML_50_70, __PHISH_SPEAR_GREETING, __PHISH_FROM, __PHISH_SPEAR_STRUCTURE_1, PRIORITY_NO_NAME, __FRAUD_WEBMAIL, NO_URI_HTTPS X-CTCH-Spam: Unknown Received: from webmail18.bt.ext.cpcloud.co.uk (10.110.12.2) by rgout02.bt.lon5.cpcloud.co.uk (8.6.122.06) (authenticated as nweinronk@btinternet.com) id 56DDD316003E3471; Wed, 9 Mar 2016 18:59:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1457549970; bh=yW9rG78uWXKgmpM71txNsuCfImtvWRIHUdCko8EAtz0=; h=Date:From:Reply-To:To:Message-ID:Subject:MIME-Version; b=gsaXIxlL664/uz5ywTdEorcXTOaRpqdXGCYCPF5BXttDnX20JhhaNUpHVrUSYCyIvNh0JiViwgnVp68HMf3wefgpthDG/KeKpk2IyeaxkEn6roqtosjN9jIWOphbaRSRBPAfscMH4+7/p2GM9108WCB/BYwQejFEEjtlvSu1qSY= Date: Wed, 9 Mar 2016 18:59:37 +0000 (GMT) From: N WEINRONK To: michael.hammer@yaanatech.com, keith.drage@nokia.com, dispatch@ietf.org Message-ID: <11749955.65086.1457549977256.JavaMail.defaultUser@defaultHost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_65083_26114023.1457549977231" X-CP-REPLY-ALL-UID: 25404 X-CP-REPLY-ALL-UID: 25404 X-CP-REPLY-ALL-UID: 25404 X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: Importance: 3 (Normal) X-Priority: 3 (Normal) X-Client-IP: IPv4[86.145.180.157] Epoch[1457549977233] Archived-At: Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nweinronk@btinternet.com List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 18:59:46 -0000 ------=_Part_65083_26114023.1457549977231 Content-Type: multipart/alternative; boundary="----=_Part_65082_29964361.1457549977230" ------=_Part_65082_29964361.1457549977230 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your time. Please explain the negative consequences of a separate header ? The only place I saw that this could have been placed in History-Info was a= s an hi-extension because it is really a 'network asserted id' of the hi-ta= rgeted-to-uri and this would place requirements on lots of functions to sea= rch History-Info entries to remove this 'network asserted' identity when re= quired.=20 To me this is the same as From / P-Asserted-Identity - the P-Asserted_Ident= ity was not place in the From header as a parameter - I guess it could have= been. I think the same argument applies here in keeping the 'network asserted ide= ntity' and the 'presentation identity' for the same user apart in the signa= lling. Note: This also matches the ISUP implementation - a separate distinct param= eter. I see nothing illogical in a separate header. Thanks, Nigel ----Original message---- >From : michael.hammer@yaanatech.com Date : 09/03/2016 - 17:20 (GMTST) To : nweinronk@btinternet.com, keith.drage@nokia.com, dispatch@ietf.org Subject : RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id There is a danger here that this purpose could be supported by two differen= t headers=20 (a new header or an old header) with potential negative consequences. =20 Please show what prevents you from supporting this purpose with History-Inf= o? =20 The argument that because A is supported by B, therefore C is not supported= by B, is illogical. =20 ________________________________ Michael Hammer michael.hammer@yaanatech.com +1 408 202 9291 =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentia= lity notice. This message is private and confidential. If you have received= this message in error, please notify us and remove it from your system. =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of N WEINRONK Sent: Wednesday, March 09, 2016 6:05 AM To: keith.drage@nokia.com; dispatch@ietf.org Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 =20 Thank you for your comments on this Internet Draft =E2=80=93 I will try and= answer your points. Do you believe it is legacy from the early ISDN definitions or do you belie= ve it is new?=20 Neither it a consequence of the way ETSI ISDN was implemented in the UK in = the 1990s that is still in use today =E2=80=93 see below. Note: I assume by early ISDN definitions you mean where ETSI ISDN was mappe= d to DASS and I am not talking about this. Can you explain where a proposed UK requirement comes from that is not cont= ained within the ETSI and ITU-T service definitions for the ISDN?=20 This comes from current implementations in the UK based on NICC ND1007. In UK ISUP there is a parameter optional in the IAM =E2=80=93 Last Diverted= Line Identity in additional to the ITU/ETSI parameter Redirecting Number. There are times when these parameters are both present and can hold differe= nt information. You could see this as being analogous to FROM and P-Asserted-Id headers in = SIP with the Last Diverted Line Identity parameter being the =E2=80=98netwo= rk asserted identity=E2=80=99 used by networks other that the network diver= ting the call to verify service and the Redirecting Number parameter being = the =E2=80=98presentation number=E2=80=99. The cases I am aware of where these parameters can hold different informati= on come from ETSI ISDN diversion scenarios =E2=80=93 Call Forwarding Uncond= itional / Call Forwarding Busy / Call Forwarding No Reply / Call Deflection= / Partial Rerouting. For Partial Rerouting the Last Diverted Line Identity parameter is based on= the =E2=80=98administration number=E2=80=99 as understood by the network d= oing the diversion and the network doing the verification and billing for t= hese calls. The Redirecting Number parameter is set from the lastReroutingN= r from the ASN.1 the private network sets in the Q.931 SETUP message =E2=80= =93 these can/will be different. For Call Forwarding Unconditional / Call Forwarding Busy / Call Forwarding = No Reply / Call Deflection the Last Diverted Line Identity parameter is bas= ed on the =E2=80=98administration number=E2=80=99 as understood by the netw= ork doing the diversion and the network doing the verification and billing = for these calls. The Redirecting Number parameter is set to the Called Part= y Number used to reach the diverting party =E2=80=93 these are not necessar= ily the same. I=E2=80=99d also note that I believe if this is required then an addition t= o the History-Info header field would be more appropriate.=20 We (myself and the UK NICC SIP Task Group) did consider using the History-I= nfo header for this but as the mappings are already defined from Redirectin= g Number parameter to History-Info by the IETF / ETSI / ITU it was felt thi= s would be confusing and make the mappings complicated. Also I would expect this header to (like the Last Diverted Line Identity pa= rameter in UK ISUP) be limited in where it can be sent ie. between network = operators and not to end users again making use of History-Info more compli= cated. Nigel Weinronk =20 ----Original message---- >From : keith.drage@nokia.com Date : 09/03/2016 - 02:47 (GMTST) To : Phil.Hutchison@virginmedia.co.uk, dispatch@ietf.org Subject : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Can you explain where a proposed UK requirement comes from that is not cont= ained within the ETSI and ITU-T service definitions for the ISDN? =20 Do you believe it is legacy from the early ISDN definitions or do you belie= ve it is new? =20 I=E2=80=99d also note that I believe if this is required then an addition t= o the History-Info header field would be more appropriate. =20 Regards =20 Keith Drage =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of EXT Hutchiso= n, Phil Sent: 04 March 2016 08:20 To: 'dispatch@ietf.org' Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 Hi, =20 I believe that this is required in the UK, and therefore would like to see = the draft accepted. =20 Regards =20 Phil=20 ~~~~~~~~~~~~~~~~~=20 Phil Hutchison=20 Liberty Global CAO - Communications Architecture=20 Mobile +447775 938827 | Soft Client +44(0)3703 900464 | Email phil.hutchiso= n@virginmedia.co.uk=20 Meet Me Conference: 0808 1074444 [+44 1723204444] PIN 1256450# Visit www.virginmedia.co.uk for more information, and more fun=20 Save paper - do you really need to print this email? =20 -------------------------------------------------------------------- Save Paper - Do you really need to print this e-mail? Visit www.virginmedia.com for more information, and more fun. This email and any attachments are or may be confidential and legally privi= leged and are sent solely for the attention of the addressee(s). If you have rece= ived this email in error, please delete it from your system: its use, disclosure or c= opying is unauthorised. Statements and opinions expressed in this email may not repre= sent those of Virgin Media. Any representations or commitments in this email are subject to contract.=20 Registered office: Media House, Bartley Wood Business Park, Hook, Hampshire= , RG27 9UP Registered in England and Wales with number 2591237 =20 =20 ------=_Part_65082_29964361.1457549977230 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Thanks for your time.


Please explain the neg= ative consequences of a separate header ?


The only place I= saw that this could have been placed in History-Info was as an hi-extensio= n because it is really a 'network asserted id' of the hi-targeted-to-u= ri and this would place requirements on lots of functions to search Hi= story-Info entries to remove this 'network asserted' identity when required= . 

To me this is the same as From / P-Asserted-Identity - the P-= Asserted_Identity was not place in the From header as a parameter - I guess= it could have been.

I think the same argument applies here in keepin= g the 'network asserted identity' and the 'presentation identity' for the s= ame user apart in the signalling.

Note: This also matches the ISUP im= plementation - a separate distinct parameter.

I see nothing illogical= in a separate header.

Thanks,

Nigel


----Original message----From : michael.hammer@yaanatech.com
Date : 09/03/2016 - 17:20 (GMTST)To : nweinronk@btinternet.com, keith.drage@nokia.com, dispatch@ietf.orgSubject : RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id

There is a danger here t= hat this purpose could be supported by two different headers

(a = new header or an old header) with potential negative consequences.

Please show what prevents you from supporting this purpo= se with History-Info?

 

The argument that because = A is supported by B, therefore C is not supported by B, is illogical.<= /o:p>

 

___________________= _____________

Michael Hammer

michael.hammer@yaanatech.com

+1 408 202 9291<= span style=3D"color: black; font-size: 10.5pt;">


=C2=A9 = 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality no= tice. This message is private and confidential. If you have received this m= essage in error, please notify us and remove it from your system.

 <= /span>

From: dispatch [mailto:dispatch-bou= nces@ietf.org] On Behalf Of N WEINRONK
Sent: Wednesday, Ma= rch 09, 2016 6:05 AM
To: keith.drage@nokia.com; dispatch@ietf.org=
Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-l= ine-id

 

 

Thank you for your comments on this Internet D= raft =E2=80=93 I will try and answer your points.

<= span style=3D"color: rgb(31, 73, 125); mso-fareast-language: EN-GB;">Do you= believe it is legacy from the early ISDN definitions or do you believe it = is new?

Neither it a consequence of the way ETSI ISDN was= implemented in the UK in the 1990s that is still in use today =E2=80= =93 see below.

Note: I assume by early ISDN definitions yo= u mean where ETSI ISDN was mapped to DASS and I am not talking about this.<= /span>

Can you explain where a proposed UK requirement comes fr= om that is not contained within the ETSI and ITU-T service definitions for = the ISDN?

This comes from current implementations in the = UK based on NICC ND1007.

In UK ISUP there is a parameter o= ptional in the IAM =E2=80=93 Last Diverted Line Identity in additional to t= he ITU/ETSI parameter Redirecting Number.

There are times = when these parameters are both present and can hold different information.<= /span>

You could see this as being analogous to FROM and P-Assert= ed-Id headers in SIP with the Last Diverted Line Identity parameter being t= he =E2=80=98network asserted identity=E2=80=99 used by networks other that = the network diverting the call to verify service and the Redirecting Number= parameter being the =E2=80=98presentation number=E2=80=99.

For Partial Rerouting the Last Div= erted Line Identity parameter is based on the =E2=80=98administration numbe= r=E2=80=99 as understood by the network doing the diversion and the network= doing the verification and billing for these calls. The Redirecting Number= parameter is set from the lastReroutingNr from the ASN.1 the private netwo= rk sets in the Q.931 SETUP message =E2=80=93 these can/will be different.

For Call Forwarding Unconditional / Call Forwarding Busy / = Call Forwarding No Reply / Call Deflection the Last Diverted Line Identity = parameter is based on the =E2=80=98administration number=E2=80=99 as unders= tood by the network doing the diversion and the network doing the verificat= ion and billing for these calls. The Redirecting Number parameter is set to= the Called Party Number used to reach the diverting party =E2=80=93 these = are not necessarily the same.

I=E2=80=99d also note that= I believe if this is required then an addition to the History-Info header = field would be more appropriate.

= We (myself and the UK NI= CC SIP Task Group) did consider using the History-Info header for this but = as the mappings are already defined from Redirecting Number parameter to Hi= story-Info by the IETF / ETSI / ITU it was felt this would be confusing and= make the mappings complicated.

Also I would expect this h= eader to (like the Last Diverted Line Identity parameter in UK ISUP) be lim= ited in where it can be sent ie. between network operators and not to end u= sers again making use of History-Info more complicated.

Ni= gel Weinronk

 

=

----Original message----
From : keith.drage@nokia.com
Date : 09/03/20= 16 - 02:47 (GMTST)
To : Phil.Hutchison@virginmedia.co.uk, dispatch@ietf.org
Subject : Re: [dispatch] draft-weinronk-dispat= ch-last-diverting-line-id

Can you explain where a proposed UK require= ment comes from that is not contained within the ETSI and ITU-T service def= initions for the ISDN?

 

Do you believe it is lega= cy from the early ISDN definitions or do you believe it is new?=

&= nbsp;

I=E2=80=99d also note that I believe if this is required th= en an addition to the History-Info header field would be more appropriate.<= /span>

 

Regards

 

Keith Drage

 

From:= dispatc= h [mailto:dispatch-bounces@iet= f.org] On Behalf Of EXT Hutchison, Phil
Sent: 04 March= 2016 08:20
To: 'dispatch@ietf.org'
Subject: [dispatch]= draft-weinronk-dispatch-last-diverting-line-id

=

 

Hi,<= /span>

 

I believe that this is required in the UK, and therefore wo= uld like to see the draft accepted.

 

Regards

 

Phil

~~~~~~~~~~~~~~~~~

Phil Hutchison=

Liberty Global CA= O - Communications Architecture

Mobile = +447775 938827 | Soft Client +44(0)3703 900464 | Email = phil.hutchison@virginmedia= .co.uk

Mee= t Me Conference: 0808 1074444  [+44 1723204444] PIN 1256450#

=

www.virginmedia.co.uk for more information, and more fun

= Save paper - do you really need to print this email?

<= p class=3D"MsoNormal"> 

<= span lang=3D"EN-GB">
---------------------------------------------------= -----------------
Save Paper - Do you really need to print this e-mail?<= /span>

Visit www.virginmedia.com for more information, and more fun.<= /span>

This email and any attachments= are or may be confidential and legally privileged
and are sent solely f= or the attention of the addressee(s). If you have received this
email in= error, please delete it from your system: its use, disclosure or copying i= s
unauthorised. Statements and opinions expressed in this email may not = represent
those of Virgin Media. Any representations or commitments in t= his email are
subject to contract.

Registered office: Media House, Bartley Wood Business Park, Hook= , Hampshire, RG27 9UP
Registered in England and Wales with number 259123= 7

 

Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nweinronk@btinternet.com List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 22:10:50 -0000 ------=_Part_78796_27512377.1457561267613 Content-Type: multipart/alternative; boundary="----=_Part_78795_10207518.1457561267613" ------=_Part_78795_10207518.1457561267613 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Not sure I agree with the non-sequitur statement but lets move on. Let us explore the statement that History-Info "should" work a little more: Can you explain how 1 entry can have a 'presentation' and a 'network assert= ed' identity that can be different - were you thinking of the hi-extension = ? Just to add to this in the UK (I can only really comment on this) the speci= fication of ETSI ISDN diversion services mandates that both the 'network as= serted' and the 'presentation' identities of the Diverting Party are passed= between operator networks on Diverted calls. This allows 'transit' operators handling Carrier Pre-select Diverted calls = to verify and bill the user.=20 All the documents I have seen be it 3GPP/IETF maps History-Info into Redire= cting Number - Redirecting Number does not have a screening indicator and i= s used directly for display in ETSI ISDN.=20 In cases where the 'network asserted' identify is different from the 'prese= ntation' identity it is not clear to me how the information in the History-= Info header can be 'network asserted'. I do not think it is 'this diversion' that is different it is the ability t= o consistently pass 'network asserted' and 'presentation' identities for Di= version information.=20 Not sure how STIR is related ?=20 =20 Thanks, Nigel ----Original message---- >From : michael.hammer@yaanatech.com Date : 09/03/2016 - 20:13 (GMTST) To : nweinronk@btinternet.com, keith.drage@nokia.com, dispatch@ietf.org Subject : RE: RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Nigel, =20 Your logic was a non-sequitor. Like saying cats like milk, therefore don=E2=80=99t give chocolate to a dog= . =20 The conclusion has nothing to do with cats and milk. =20 So, while such logic is not conclusive for or against a separate header,=20 the burden of proof for a separate header should lie on the one proposing a= new header,=20 when face with the existing of a header that =E2=80=9Cshould=E2=80=9D work.= (the question at hand) =20 A separate header is warranted when an existing header has the wrong semant= ics=20 and the existing syntax just won=E2=80=99t work. However, that doesn=E2=80= =99t seem to be the case. =20 If another implementation judges that the H-I header is a perfect fit, then= you won=E2=80=99t be looking there. Some existing implementations just might be doing this already. So, just want to be careful about willy nilly adding new headers. =20 I would note that both the Route header and the H-I header can be =E2=80=9C= network asserted=E2=80=9D. So, what makes this particular diversion different from H-I envisaged? =20 You make it sound like it should be part of the STIR discussion, when you c= ompare to P-Asserted-ID. Have you looked into that WG? =20 ________________________________ Michael Hammer michael.hammer@yaanatech.com +1 408 202 9291 =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentia= lity notice. This message is private and confidential. If you have received= this message in error, please notify us and remove it from your system. =20 From: N WEINRONK [mailto:nweinronk@btinternet.com]=20 Sent: Wednesday, March 09, 2016 2:00 PM To: Michael Hammer ; keith.drage@nokia.com; d= ispatch@ietf.org Subject: Re: RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 =20 Thanks for your time. =20 Please explain the negative consequences of a separate header ? =20 The only place I saw that this could have been placed in History-Info was a= s an hi-extension because it is really a 'network asserted id' of the hi-ta= rgeted-to-uri and this would place requirements on lots of functions to sea= rch History-Info entries to remove this 'network asserted' identity when re= quired.=20 To me this is the same as From / P-Asserted-Identity - the P-Asserted_Ident= ity was not place in the From header as a parameter - I guess it could have= been. I think the same argument applies here in keeping the 'network asserted ide= ntity' and the 'presentation identity' for the same user apart in the signa= lling. Note: This also matches the ISUP implementation - a separate distinct param= eter. I see nothing illogical in a separate header. Thanks, Nigel =20 ----Original message---- >From : michael.hammer@yaanatech.com Date : 09/03/2016 - 17:20 (GMTST) To : nweinronk@btinternet.com, keith.drage@nokia.com, dispatch@ietf.org Subject : RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id There is a danger here that this purpose could be supported by two differen= t headers=20 (a new header or an old header) with potential negative consequences. =20 Please show what prevents you from supporting this purpose with History-Inf= o? =20 The argument that because A is supported by B, therefore C is not supported= by B, is illogical. =20 ________________________________ Michael Hammer michael.hammer@yaanatech.com +1 408 202 9291 =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentia= lity notice. This message is private and confidential. If you have received= this message in error, please notify us and remove it from your system. =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of N WEINRONK Sent: Wednesday, March 09, 2016 6:05 AM To: keith.drage@nokia.com; dispatch@ietf.org Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 =20 Thank you for your comments on this Internet Draft =E2=80=93 I will try and= answer your points. Do you believe it is legacy from the early ISDN definitions or do you belie= ve it is new?=20 Neither it a consequence of the way ETSI ISDN was implemented in the UK in = the 1990s that is still in use today =E2=80=93 see below. Note: I assume by early ISDN definitions you mean where ETSI ISDN was mappe= d to DASS and I am not talking about this. Can you explain where a proposed UK requirement comes from that is not cont= ained within the ETSI and ITU-T service definitions for the ISDN?=20 This comes from current implementations in the UK based on NICC ND1007. In UK ISUP there is a parameter optional in the IAM =E2=80=93 Last Diverted= Line Identity in additional to the ITU/ETSI parameter Redirecting Number. There are times when these parameters are both present and can hold differe= nt information. You could see this as being analogous to FROM and P-Asserted-Id headers in = SIP with the Last Diverted Line Identity parameter being the =E2=80=98netwo= rk asserted identity=E2=80=99 used by networks other that the network diver= ting the call to verify service and the Redirecting Number parameter being = the =E2=80=98presentation number=E2=80=99. The cases I am aware of where these parameters can hold different informati= on come from ETSI ISDN diversion scenarios =E2=80=93 Call Forwarding Uncond= itional / Call Forwarding Busy / Call Forwarding No Reply / Call Deflection= / Partial Rerouting. For Partial Rerouting the Last Diverted Line Identity parameter is based on= the =E2=80=98administration number=E2=80=99 as understood by the network d= oing the diversion and the network doing the verification and billing for t= hese calls. The Redirecting Number parameter is set from the lastReroutingN= r from the ASN.1 the private network sets in the Q.931 SETUP message =E2=80= =93 these can/will be different. For Call Forwarding Unconditional / Call Forwarding Busy / Call Forwarding = No Reply / Call Deflection the Last Diverted Line Identity parameter is bas= ed on the =E2=80=98administration number=E2=80=99 as understood by the netw= ork doing the diversion and the network doing the verification and billing = for these calls. The Redirecting Number parameter is set to the Called Part= y Number used to reach the diverting party =E2=80=93 these are not necessar= ily the same. I=E2=80=99d also note that I believe if this is required then an addition t= o the History-Info header field would be more appropriate.=20 We (myself and the UK NICC SIP Task Group) did consider using the History-I= nfo header for this but as the mappings are already defined from Redirectin= g Number parameter to History-Info by the IETF / ETSI / ITU it was felt thi= s would be confusing and make the mappings complicated. Also I would expect this header to (like the Last Diverted Line Identity pa= rameter in UK ISUP) be limited in where it can be sent ie. between network = operators and not to end users again making use of History-Info more compli= cated. Nigel Weinronk =20 ----Original message---- >From : keith.drage@nokia.com Date : 09/03/2016 - 02:47 (GMTST) To : Phil.Hutchison@virginmedia.co.uk, dispatch@ietf.org Subject : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Can you explain where a proposed UK requirement comes from that is not cont= ained within the ETSI and ITU-T service definitions for the ISDN? =20 Do you believe it is legacy from the early ISDN definitions or do you belie= ve it is new? =20 I=E2=80=99d also note that I believe if this is required then an addition t= o the History-Info header field would be more appropriate. =20 Regards =20 Keith Drage =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of EXT Hutchiso= n, Phil Sent: 04 March 2016 08:20 To: 'dispatch@ietf.org' Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 Hi, =20 I believe that this is required in the UK, and therefore would like to see = the draft accepted. =20 Regards =20 Phil=20 ~~~~~~~~~~~~~~~~~=20 Phil Hutchison=20 Liberty Global CAO - Communications Architecture=20 Mobile +447775 938827 | Soft Client +44(0)3703 900464 | Email phil.hutchiso= n@virginmedia.co.uk=20 Meet Me Conference: 0808 1074444 [+44 1723204444] PIN 1256450# Visit www.virginmedia.co.uk for more information, and more fun=20 Save paper - do you really need to print this email? =20 -------------------------------------------------------------------- Save Paper - Do you really need to print this e-mail? Visit www.virginmedia.com for more information, and more fun. This email and any attachments are or may be confidential and legally privi= leged and are sent solely for the attention of the addressee(s). If you have rece= ived this email in error, please delete it from your system: its use, disclosure or c= opying is unauthorised. Statements and opinions expressed in this email may not repre= sent those of Virgin Media. Any representations or commitments in this email are subject to contract.=20 Registered office: Media House, Bartley Wood Business Park, Hook, Hampshire= , RG27 9UP Registered in England and Wales with number 2591237 =20 =20 =20 =20 ------=_Part_78795_10207518.1457561267613 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Not sure I agree with the non-sequitur statement but lets mov= e on.

Let us explore the statement that History-Info "should" work a = little more:


Can you explain how 1 entry can have a 'pr= esentation' and a 'network asserted' identity that can be different - were = you thinking of the hi-extension ?

Just to add to this in the UK (I c= an only really comment on this) the specification of ETSI ISDN diversion se= rvices mandates that both the 'network asserted' and the 'present= ation' identities of the Diverting Party are passed between operator networ= ks on Diverted calls.

This allows 'transit' operators handling Carrie= r Pre-select Diverted calls to verify and bill the user. 

All th= e documents I have seen be it 3GPP/IETF maps History-Info into Redirec= ting Number - Redirecting Number does not have a screening indicator and is= used directly for display in ETSI ISDN.

In cases where = the 'network asserted' identify is different from the 'presentation' identi= ty it is not clear to me how the information in the History-Info heade= r can be 'network asserted'.


I do not think it is 'this di= version' that is different it is the ability to consistently pass 'net= work asserted' and 'presentation' identities for Diversion information= . 


Not sure how STIR is related ? 

 <= /p>

Thanks,

Nigel




----Original message----
= >From : michael.hammer@yaanatech.com
Date : 09/03/2016 - 20:13 (GMTST)To : nweinronk@btinternet.com, keith.drage@nokia.com, dispatch@ietf.orgSubject : RE: RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-i= d

Nigel,=

&n= bsp;

Your logic was a non-sequitor.

Like saying cats like mi= lk, therefore don=E2=80=99t give chocolate to a dog. 

The c= onclusion has nothing to do with cats and milk.

 =

= So, while such logic is not conclusive for or against a separate header,

the burden of proof for a separate header should lie on the one pr= oposing a new header,

when face with the existing of a header th= at =E2=80=9Cshould=E2=80=9D work.  (the question at hand)

 

A separate header is warranted when an existing header has t= he wrong semantics

and the existing syntax just won=E2=80=99t wo= rk.  However, that doesn=E2=80=99t seem to be the case.

 

If another implementation judges that the H-I header is a perf= ect fit, then you won=E2=80=99t be looking there.

Some existing i= mplementations just might be doing this already.

So, just want to= be careful about willy nilly adding new headers.

 

<= span style=3D"color: rgb(31, 73, 125);">So, what makes this particular dive= rsion different from H-I envisaged?

 

<= p class=3D"MsoNormal">You make it = sound like it should be part of the STIR discussion, when you compare to P-= Asserted-ID.

Have you looked into that WG?

<= p class=3D"MsoNormal"> <= /o:p>

________________________________<= /p>

<= b>Michael Hammer

michael.hammer@yaanatech.com

+1 408 202 9291


=C2=A9 2016 Yaana Techno= logies, LLC. All Rights Reserved. Email confidentiality notice. This messag= e is private and confidential. If you have received this message in error, = please notify us and remove it from your system.

<= span style=3D"color: rgb(31, 73, 125);"> 

From: N WEINRONK [mailto:nweinronk@btinternet.com] <= br>Sent: Wednesday, March 09, 2016 2:00 PM
To: Michael Ham= mer <michael.hammer@yaanatech.com>; keith.drage@nokia.com; dispatch@i= etf.org
Subject: Re: RE: [dispatch] draft-weinronk-dispatch-last-= diverting-line-id

 

 

Thanks for your time.

&nb= sp;

Please explain the negative consequences of a separate head= er ?

 

The only place I saw that thi= s could have been placed in History-Info was as an hi-extension because it = is really a 'network asserted id' of the hi-targeted-to-uri and t= his would place requirements on lots of functions to search History-Info en= tries to remove this 'network asserted' identity when required. <= /o:p>

To me this is the same as From / P-Asserted-Identity - the P-As= serted_Identity was not place in the From header as a parameter - I guess i= t could have been.

I think the same argument applies here = in keeping the 'network asserted identity' and the 'presentation identity' = for the same user apart in the signalling.

Note: This also= matches the ISUP implementation - a separate distinct parameter.

I see nothing illogical in a separate header.

Than= ks,

Nigel

 

----Original message----
From : michael.hammer@yaanatech.com
Date : 09/0= 3/2016 - 17:20 (GMTST)
To : = nweinronk@btinternet.com, keit= h.drage@nokia.com, dispatch@ietf.o= rg
Subject : RE: [dispatch] draft-weinronk-dispatch-last-diverting-l= ine-id________________________________

= Michael Hammer

michael.hammer@yaanatech.com

+1 4= 08 202 9291


=C2=A9 2016 Yaana Technologies, LLC. All Rig= hts Reserved. Email confidentiality notice. This message is private and con= fidential. If you have received this message in error, please notify us and= remove it from your system.

 

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of N WEINRON= K
Sent: Wednesday, March 09, 2016 6:05 AM
To: keith.drage@nokia.com; dispatch@ietf.org
Subject: Re: [dispat= ch] draft-weinronk-dispatch-last-diverting-line-id

 

 

Th= ank you for your comments on this Internet Draft =E2=80=93 I will try and a= nswer your points.

Do you believe it is legacy from the = early ISDN definitions or do you believe it is new?

<= p style=3D"margin-right: 0in; margin-bottom: 8pt; margin-left: 0in; mso-mar= gin-top-alt: 0in;">Neith= er it a consequence of the way ETSI ISDN was implemented in the UK in the 1= 990s that is still in use today =E2=80=93 see below.=

= Note: I assume by early ISDN definitions you mean where ETSI ISDN was mappe= d to DASS and I am not talking about this.

Can you expla= in where a proposed UK requirement comes from that is not contained within = the ETSI and ITU-T service definitions for the ISDN?

=

This= comes from current implementations in the UK based on NICC ND1007.<= o:p>

In UK ISUP there is a parameter optional in the IAM =E2=80=93 Las= t Diverted Line Identity in additional to the ITU/ETSI parameter Redirectin= g Number.

There are times when these parameters are both p= resent and can hold different information.

You could see t= his as being analogous to FROM and P-Asserted-Id headers in SIP with the La= st Diverted Line Identity parameter being the =E2=80=98network asserted ide= ntity=E2=80=99 used by networks other that the network diverting the call t= o verify service and the Redirecting Number parameter being the =E2=80=98pr= esentation number=E2=80=99.

The cases I am aware of where = these parameters can hold different information come from ETSI ISDN diversi= on scenarios =E2=80=93 Call Forwarding Unconditional / Call Forwarding Busy= / Call Forwarding No Reply / Call Deflection / Partial Rerouting.

For Partial Rerouting the Last Diverted Line Identity parameter is= based on the =E2=80=98administration number=E2=80=99 as understood by the = network doing the diversion and the network doing the verification and bill= ing for these calls. The Redirecting Number parameter is set from the lastR= eroutingNr from the ASN.1 the private network sets in the Q.931 SETUP messa= ge =E2=80=93 these can/will be different.

For Call Forward= ing Unconditional / Call Forwarding Busy / Call Forwarding No Reply / Call = Deflection the Last Diverted Line Identity parameter is based on the =E2=80= =98administration number=E2=80=99 as understood by the network doing the di= version and the network doing the verification and billing for these calls.= The Redirecting Number parameter is set to the Called Party Number used to= reach the diverting party =E2=80=93 these are not necessarily the same.

I=E2=80=99d also note that I believe if this is required t= hen an addition to the History-Info header field would be more appropriate.=

We (myself and the UK NICC SIP Task Group) did consider = using the History-Info header for this but as the mappings are already defi= ned from Redirecting Number parameter to History-Info by the IETF / ETSI / = ITU it was felt this would be confusing and make the mappings complicated.<= /span>

Also I would expect this header to (like the Last Diverted= Line Identity parameter in UK ISUP) be limited in where it can be sent ie.= between network operators and not to end users again making use of History= -Info more complicated.

Nigel Weinronk

 

--= --Original message----
From : k= eith.drage@nokia.com
Date : 09/03/2016 - 02:47 (GMTST)
To : Phil.Hutchison@virginmedia.c= o.uk, dispatch@ietf.org
Sub= ject : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id

Can= you explain where a proposed UK requirement comes from that is not contain= ed within the ETSI and ITU-T service definitions for the ISDN?<= /o:p>

&n= bsp;

Do you believe it is legacy from the early ISDN definitions = or do you believe it is new?

 

I=E2=80=99d also no= te that I believe if this is required then an addition to the History-Info = header field would be more appropriate.

 <= /p>

Regards<= /span>

 

Keith Drage

 

From:mailto:dispatch-bounces@ietf.org] On Behalf Of EXT = Hutchison, Phil
Sent: 04 March 2016 08:20
To: 'dispatch= @ietf.org'
Subject: [dispatch] draft-weinronk-dispatch-last-diver= ting-line-id

 =

Hi,

 

I believe that this= is required in the UK, and therefore would like to see the draft accepted.=

 

Regards

 

Phil

~~~~~~~~~~~~~~~~~ <= /span>

Phil Hutchison

Liberty Global CAO - Communications Arch= itecture <= /p>

Mobile +447775 938827 | Soft Client +44(= 0)3703 900464 | Email phil.hutchison@virginmedia.co.uk

Meet Me Conference: 0808 1074444  [+4= 4 1723204444] PIN 1256450#

= Visit www.virgin= media.co.uk for more information, and = more fun

<= p class=3D"MsoNormal">Save paper - do you really need to= print this email?

 


--------= ------------------------------------------------------------
Save Paper = - Do you really need to print this e-mail?

Visit www.virginmedia.c= om for more information, and more fun.

This email and any attachments are or may be confidential and = legally privileged
and are sent solely for the attention of the addresse= e(s). If you have received this
email in error, please delete it from yo= ur system: its use, disclosure or copying is
unauthorised. Statements an= d opinions expressed in this email may not represent
those of Virgin Med= ia. Any representations or commitments in this email are
subject to cont= ract.

Registered office: Medi= a House, Bartley Wood Business Park, Hook, Hampshire, RG27 9UP
Registere= d in England and Wales with number 2591237

 

 <= /span>

 

 



------=_Part_78795_10207518.1457561267613-- ------=_Part_78796_27512377.1457561267613-- From nobody Wed Mar 9 14:42:05 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905CB12DA90 for ; Wed, 9 Mar 2016 14:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 PwoOpoFot8Cw for ; Wed, 9 Mar 2016 14:41:23 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BC912D980 for ; Wed, 9 Mar 2016 14:41:18 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 7AE1318E2EF; Wed, 9 Mar 2016 23:41:16 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 53C92238074; Wed, 9 Mar 2016 23:41:16 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0279.002; Wed, 9 Mar 2016 23:41:16 +0100 From: To: "nweinronk@btinternet.com" , "michael.hammer@yaanatech.com" , "keith.drage@nokia.com" , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Thread-Index: AQHRelAc/8b1C5jv/0eBD3gng80cGJ9RrLqg Date: Wed, 9 Mar 2016 22:41:15 +0000 Message-ID: <29641_1457563276_56E0A68C_29641_2783_1_8B970F90C584EA4E97D5BAAC9172DBB8158472E0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <21219125.78797.1457561267637.JavaMail.defaultUser@defaultHost> In-Reply-To: <21219125.78797.1457561267637.JavaMail.defaultUser@defaultHost> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB8158472E0OPEXCLILMA4corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.9.210617 Archived-At: Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 22:41:45 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB8158472E0OPEXCLILMA4corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBOaWdlbCwNCg0KQWZ0ZXIgYSByZWFkaW5nIG9mIHRoZSBkcmFmdCwgSSBoYXZlIHRoZSBm b2xsb3dpbmcgY29tbWVudHMgOg0KDQotICAgICAgICAgIEZpcnN0LCBJIHdvbmRlciBhYm91dCBo YXZpbmcgYSBzdGFuZGFyZCwgZXZlbiBpbmZvcm1hdGlvbmFsLCB0byBzb2x2ZSBhIGNvdW50cnkt c3BlY2lmaWMgbmVlZCB0byBjb252ZXkgYW4gSVNVUCBOYXRpb25hbCBwYXJhbWV0ZXLigKZodW0N Cg0KLSAgICAgICAgICBTZWNvbmQsIEkgZG8gdGhpbmsgd2UgY2FuIGZpbmQgYSBzb2x1dGlvbiB0 byBzb2x2ZSB5b3VyIGlzc3VlIGJ5IHVzaW5nIHRoZSBIaXN0b3J5LUluZm8gaGVhZGVyLiBJIGRv buKAmXQga25vdyB5ZXQgaG93LiDimLoNCg0KSUlVQywgeW91IG5lZWQgdG8gY29udmV5IHRoZSBh c3NlcnRlZCBpZGVudGl0eSBvZiB0aGUgZGl2ZXJ0aW5nIHVzZXIgaW50byB0aGUgZm9yd2FyZGVk IGxlZyBldmVuIHdoZW4gaGUgaGFzIGJlZW4gY2FsbGVkIHRvIGhpcyBkZWNsYXJhdGl2ZSBpZGVu dGl0eS4NCkkgc2VlIHNldmVyYWwgbWVjaGFuaXNtcyBpbiBIaXN0b3J5LUluZm8gaGVhZGVyIHRo YXQgY291bGQgYmUgdXNlZCBmb3IgdGhpcyBwdXJwb3NlOg0KDQotICAgICAgICAgIGZpcnN0IHlv dSBzaG91bGQga25vdyB0aGF0IGl0IGNhbiBiZSBhZGRlZCBhZGRpdGlvbmFsIGVudHJpZXMgaW4g dGhlIEhpc3RvcnktSW5mbyBoZWFkZXIgZXZlbiB3aGVuIHRoZSBSZXF1ZXN0IFVSSSBkb2VzIG5v dCBjaGFuZ2UuIEluIHRoaXMgY2FzZSwgdGhlIGluZGV4IHNob3VsZCBiZSBpbmNyZWFzZWQgKDEt PjIpIGFuZCBub3QgZXh0ZW5kZWQgKDEgLT4gMS4xKSBhcyB3aGVuIGZvcmtpbmcgaXMgZXhlY3V0 ZWQNCg0KLSAgICAgICAgICB0byBiZSBhYmxlIHRvIGRpc3Rpbmd1aXNoIHRoaXMgaWRlbnRpdHkg ZnJvbSB0aGUgbm9ybWFsIGRpdmVydGluZyBpZGVudGl0eSwgeW91IGNvdWxkIHVzZSB0aGUgInJj IiBoaS10YXJnZXQtcGFyYW0gdG8gcmVmZXIgdG8gdGhlIG5vcm1hbCBIaXN0b3J5LUluZm8gZW50 cnkgZm9yIHRoZSBkaXZlcnNpb24gYW5kIGxpbmsgYm90aC4gV2l0aCB0aGlzIG1lY2hhbmlzbSwg YXQgdGhlIGludGVyd29ya2luZyB5b3UgY291bGQgZmluZCB0aGUgbGFzdCBkaXZlcnRpbmcgaWRl bnRpdHkgYXMgZGVzY3JpYmVkIGluIDI5LjE2MyBhbmQgdGhlbiBzZWFyY2ggZm9yIHRoZSBlbnRy eSBoYXZpbmcgYSAicmMiIHBhcmFtZXRlciBoYXZpbmcgYSB2YWx1ZSBlcXVhbHMgdG8gdGhlIGN1 cnJlbnQgKGxhc3QgZGl2ZXJ0aW5nIGFkZHJlc3MpIGhpLWVudHJ5IGluZGV4IHZhbHVlLg0KDQot ICAgICAgICAgIGZpbmFsbHksIHlvdSBjb3VsZCBpbWFnaW5lIGEgZGVkaWNhdGVkIGNhdXNlIFVS SSBwYXJhbWV0ZXIgKGRpZmZlcmVudCBmcm9tIHRob3NlIGRlZmluZWQgaW4gUkZDNDQ1OCBmb3Ig Y2FsbCBkaXZlcnNpb24gc2VydmljZSkNCg0KDQpCZXN0IHJlZ2FyZHMsDQpNYXJpYW5uZQ0KDQpE ZSA6IGRpc3BhdGNoIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFy dCBkZSBOIFdFSU5ST05LDQpFbnZvecOpIDogbWVyY3JlZGkgOSBtYXJzIDIwMTYgMjM6MDgNCsOA IDogbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTsga2VpdGguZHJhZ2VAbm9raWEuY29tOyBk aXNwYXRjaEBpZXRmLm9yZw0KT2JqZXQgOiBSZTogW2Rpc3BhdGNoXSBkcmFmdC13ZWlucm9uay1k aXNwYXRjaC1sYXN0LWRpdmVydGluZy1saW5lLWlkDQoNCg0KDQoNCk5vdCBzdXJlIEkgYWdyZWUg d2l0aCB0aGUgbm9uLXNlcXVpdHVyIHN0YXRlbWVudCBidXQgbGV0cyBtb3ZlIG9uLg0KDQpMZXQg dXMgZXhwbG9yZSB0aGUgc3RhdGVtZW50IHRoYXQgSGlzdG9yeS1JbmZvICJzaG91bGQiIHdvcmsg YSBsaXR0bGUgbW9yZToNCg0KDQoNCkNhbiB5b3UgZXhwbGFpbiBob3cgMSBlbnRyeSBjYW4gaGF2 ZSBhICdwcmVzZW50YXRpb24nIGFuZCBhICduZXR3b3JrIGFzc2VydGVkJyBpZGVudGl0eSB0aGF0 IGNhbiBiZSBkaWZmZXJlbnQgLSB3ZXJlIHlvdSB0aGlua2luZyBvZiB0aGUgaGktZXh0ZW5zaW9u ID8NCg0KSnVzdCB0byBhZGQgdG8gdGhpcyBpbiB0aGUgVUsgKEkgY2FuIG9ubHkgcmVhbGx5IGNv bW1lbnQgb24gdGhpcykgdGhlIHNwZWNpZmljYXRpb24gb2YgRVRTSSBJU0ROIGRpdmVyc2lvbiBz ZXJ2aWNlcyBtYW5kYXRlcyB0aGF0IGJvdGggdGhlICduZXR3b3JrIGFzc2VydGVkJyBhbmQgdGhl ICdwcmVzZW50YXRpb24nIGlkZW50aXRpZXMgb2YgdGhlIERpdmVydGluZyBQYXJ0eSBhcmUgcGFz c2VkIGJldHdlZW4gb3BlcmF0b3IgbmV0d29ya3Mgb24gRGl2ZXJ0ZWQgY2FsbHMuDQoNClRoaXMg YWxsb3dzICd0cmFuc2l0JyBvcGVyYXRvcnMgaGFuZGxpbmcgQ2FycmllciBQcmUtc2VsZWN0IERp dmVydGVkIGNhbGxzIHRvIHZlcmlmeSBhbmQgYmlsbCB0aGUgdXNlci4NCg0KQWxsIHRoZSBkb2N1 bWVudHMgSSBoYXZlIHNlZW4gYmUgaXQgM0dQUC9JRVRGIG1hcHMgSGlzdG9yeS1JbmZvIGludG8g UmVkaXJlY3RpbmcgTnVtYmVyIC0gUmVkaXJlY3RpbmcgTnVtYmVyIGRvZXMgbm90IGhhdmUgYSBz Y3JlZW5pbmcgaW5kaWNhdG9yIGFuZCBpcyB1c2VkIGRpcmVjdGx5IGZvciBkaXNwbGF5IGluIEVU U0kgSVNETi4NCg0KSW4gY2FzZXMgd2hlcmUgdGhlICduZXR3b3JrIGFzc2VydGVkJyBpZGVudGlm eSBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgJ3ByZXNlbnRhdGlvbicgaWRlbnRpdHkgaXQgaXMgbm90 IGNsZWFyIHRvIG1lIGhvdyB0aGUgaW5mb3JtYXRpb24gaW4gdGhlIEhpc3RvcnktSW5mbyBoZWFk ZXIgY2FuIGJlICduZXR3b3JrIGFzc2VydGVkJy4NCg0KDQoNCkkgZG8gbm90IHRoaW5rIGl0IGlz ICd0aGlzIGRpdmVyc2lvbicgdGhhdCBpcyBkaWZmZXJlbnQgaXQgaXMgdGhlIGFiaWxpdHkgdG8g Y29uc2lzdGVudGx5IHBhc3MgJ25ldHdvcmsgYXNzZXJ0ZWQnIGFuZCAncHJlc2VudGF0aW9uJyBp ZGVudGl0aWVzIGZvciBEaXZlcnNpb24gaW5mb3JtYXRpb24uDQoNCg0KDQpOb3Qgc3VyZSBob3cg U1RJUiBpcyByZWxhdGVkID8NCg0KDQoNClRoYW5rcywNCg0KTmlnZWwNCg0KDQoNCg0KDQoNCi0t LS1PcmlnaW5hbCBtZXNzYWdlLS0tLQ0KPkZyb20gOiBtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2gu Y29tPG1haWx0bzptaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tPg0KRGF0ZSA6IDA5LzAzLzIw MTYgLSAyMDoxMyAoR01UU1QpDQpUbyA6IG53ZWlucm9ua0BidGludGVybmV0LmNvbTxtYWlsdG86 bndlaW5yb25rQGJ0aW50ZXJuZXQuY29tPiwga2VpdGguZHJhZ2VAbm9raWEuY29tPG1haWx0bzpr ZWl0aC5kcmFnZUBub2tpYS5jb20+LCBkaXNwYXRjaEBpZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2hA aWV0Zi5vcmc+DQpTdWJqZWN0IDogUkU6IFJFOiBbZGlzcGF0Y2hdIGRyYWZ0LXdlaW5yb25rLWRp c3BhdGNoLWxhc3QtZGl2ZXJ0aW5nLWxpbmUtaWQNCk5pZ2VsLA0KDQpZb3VyIGxvZ2ljIHdhcyBh IG5vbi1zZXF1aXRvci4NCkxpa2Ugc2F5aW5nIGNhdHMgbGlrZSBtaWxrLCB0aGVyZWZvcmUgZG9u 4oCZdCBnaXZlIGNob2NvbGF0ZSB0byBhIGRvZy4NClRoZSBjb25jbHVzaW9uIGhhcyBub3RoaW5n IHRvIGRvIHdpdGggY2F0cyBhbmQgbWlsay4NCg0KU28sIHdoaWxlIHN1Y2ggbG9naWMgaXMgbm90 IGNvbmNsdXNpdmUgZm9yIG9yIGFnYWluc3QgYSBzZXBhcmF0ZSBoZWFkZXIsDQp0aGUgYnVyZGVu IG9mIHByb29mIGZvciBhIHNlcGFyYXRlIGhlYWRlciBzaG91bGQgbGllIG9uIHRoZSBvbmUgcHJv cG9zaW5nIGEgbmV3IGhlYWRlciwNCndoZW4gZmFjZSB3aXRoIHRoZSBleGlzdGluZyBvZiBhIGhl YWRlciB0aGF0IOKAnHNob3VsZOKAnSB3b3JrLiAgKHRoZSBxdWVzdGlvbiBhdCBoYW5kKQ0KDQpB IHNlcGFyYXRlIGhlYWRlciBpcyB3YXJyYW50ZWQgd2hlbiBhbiBleGlzdGluZyBoZWFkZXIgaGFz IHRoZSB3cm9uZyBzZW1hbnRpY3MNCmFuZCB0aGUgZXhpc3Rpbmcgc3ludGF4IGp1c3Qgd29u4oCZ dCB3b3JrLiAgSG93ZXZlciwgdGhhdCBkb2VzbuKAmXQgc2VlbSB0byBiZSB0aGUgY2FzZS4NCg0K SWYgYW5vdGhlciBpbXBsZW1lbnRhdGlvbiBqdWRnZXMgdGhhdCB0aGUgSC1JIGhlYWRlciBpcyBh IHBlcmZlY3QgZml0LCB0aGVuIHlvdSB3b27igJl0IGJlIGxvb2tpbmcgdGhlcmUuDQpTb21lIGV4 aXN0aW5nIGltcGxlbWVudGF0aW9ucyBqdXN0IG1pZ2h0IGJlIGRvaW5nIHRoaXMgYWxyZWFkeS4N ClNvLCBqdXN0IHdhbnQgdG8gYmUgY2FyZWZ1bCBhYm91dCB3aWxseSBuaWxseSBhZGRpbmcgbmV3 IGhlYWRlcnMuDQoNCkkgd291bGQgbm90ZSB0aGF0IGJvdGggdGhlIFJvdXRlIGhlYWRlciBhbmQg dGhlIEgtSSBoZWFkZXIgY2FuIGJlIOKAnG5ldHdvcmsgYXNzZXJ0ZWTigJ0uDQpTbywgd2hhdCBt YWtlcyB0aGlzIHBhcnRpY3VsYXIgZGl2ZXJzaW9uIGRpZmZlcmVudCBmcm9tIEgtSSBlbnZpc2Fn ZWQ/DQoNCllvdSBtYWtlIGl0IHNvdW5kIGxpa2UgaXQgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIFNU SVIgZGlzY3Vzc2lvbiwgd2hlbiB5b3UgY29tcGFyZSB0byBQLUFzc2VydGVkLUlELg0KSGF2ZSB5 b3UgbG9va2VkIGludG8gdGhhdCBXRz8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCk1pY2hhZWwgSGFtbWVyDQptaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tPG1haWx0bzpt aWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tPg0KKzEgNDA4IDIwMiA5MjkxDQoNCsKpIDIwMTYg WWFhbmEgVGVjaG5vbG9naWVzLCBMTEMuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuIEVtYWlsIGNvbmZp ZGVudGlhbGl0eSBub3RpY2UuIFRoaXMgbWVzc2FnZSBpcyBwcml2YXRlIGFuZCBjb25maWRlbnRp YWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB1cyBhbmQgcmVtb3ZlIGl0IGZyb20geW91ciBzeXN0ZW0uDQoNCkZyb206IE4gV0VJTlJP TksgW21haWx0bzpud2VpbnJvbmtAYnRpbnRlcm5ldC5jb21dDQpTZW50OiBXZWRuZXNkYXksIE1h cmNoIDA5LCAyMDE2IDI6MDAgUE0NClRvOiBNaWNoYWVsIEhhbW1lciA8bWljaGFlbC5oYW1tZXJA eWFhbmF0ZWNoLmNvbTxtYWlsdG86bWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbT4+OyBrZWl0 aC5kcmFnZUBub2tpYS5jb208bWFpbHRvOmtlaXRoLmRyYWdlQG5va2lhLmNvbT47IGRpc3BhdGNo QGlldGYub3JnPG1haWx0bzpkaXNwYXRjaEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBSRTogW2Rp c3BhdGNoXSBkcmFmdC13ZWlucm9uay1kaXNwYXRjaC1sYXN0LWRpdmVydGluZy1saW5lLWlkDQoN Cg0KDQoNClRoYW5rcyBmb3IgeW91ciB0aW1lLg0KDQoNCg0KUGxlYXNlIGV4cGxhaW4gdGhlIG5l Z2F0aXZlIGNvbnNlcXVlbmNlcyBvZiBhIHNlcGFyYXRlIGhlYWRlciA/DQoNCg0KDQpUaGUgb25s eSBwbGFjZSBJIHNhdyB0aGF0IHRoaXMgY291bGQgaGF2ZSBiZWVuIHBsYWNlZCBpbiBIaXN0b3J5 LUluZm8gd2FzIGFzIGFuIGhpLWV4dGVuc2lvbiBiZWNhdXNlIGl0IGlzIHJlYWxseSBhICduZXR3 b3JrIGFzc2VydGVkIGlkJyBvZiB0aGUgaGktdGFyZ2V0ZWQtdG8tdXJpIGFuZCB0aGlzIHdvdWxk IHBsYWNlIHJlcXVpcmVtZW50cyBvbiBsb3RzIG9mIGZ1bmN0aW9ucyB0byBzZWFyY2ggSGlzdG9y eS1JbmZvIGVudHJpZXMgdG8gcmVtb3ZlIHRoaXMgJ25ldHdvcmsgYXNzZXJ0ZWQnIGlkZW50aXR5 IHdoZW4gcmVxdWlyZWQuDQoNClRvIG1lIHRoaXMgaXMgdGhlIHNhbWUgYXMgRnJvbSAvIFAtQXNz ZXJ0ZWQtSWRlbnRpdHkgLSB0aGUgUC1Bc3NlcnRlZF9JZGVudGl0eSB3YXMgbm90IHBsYWNlIGlu IHRoZSBGcm9tIGhlYWRlciBhcyBhIHBhcmFtZXRlciAtIEkgZ3Vlc3MgaXQgY291bGQgaGF2ZSBi ZWVuLg0KDQpJIHRoaW5rIHRoZSBzYW1lIGFyZ3VtZW50IGFwcGxpZXMgaGVyZSBpbiBrZWVwaW5n IHRoZSAnbmV0d29yayBhc3NlcnRlZCBpZGVudGl0eScgYW5kIHRoZSAncHJlc2VudGF0aW9uIGlk ZW50aXR5JyBmb3IgdGhlIHNhbWUgdXNlciBhcGFydCBpbiB0aGUgc2lnbmFsbGluZy4NCg0KTm90 ZTogVGhpcyBhbHNvIG1hdGNoZXMgdGhlIElTVVAgaW1wbGVtZW50YXRpb24gLSBhIHNlcGFyYXRl IGRpc3RpbmN0IHBhcmFtZXRlci4NCg0KSSBzZWUgbm90aGluZyBpbGxvZ2ljYWwgaW4gYSBzZXBh cmF0ZSBoZWFkZXIuDQoNClRoYW5rcywNCg0KTmlnZWwNCg0KDQotLS0tT3JpZ2luYWwgbWVzc2Fn ZS0tLS0NCkZyb20gOiBtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tPG1haWx0bzptaWNoYWVs LmhhbW1lckB5YWFuYXRlY2guY29tPg0KRGF0ZSA6IDA5LzAzLzIwMTYgLSAxNzoyMCAoR01UU1Qp DQpUbyA6IG53ZWlucm9ua0BidGludGVybmV0LmNvbTxtYWlsdG86bndlaW5yb25rQGJ0aW50ZXJu ZXQuY29tPiwga2VpdGguZHJhZ2VAbm9raWEuY29tPG1haWx0bzprZWl0aC5kcmFnZUBub2tpYS5j b20+LCBkaXNwYXRjaEBpZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmc+DQpTdWJqZWN0 IDogUkU6IFtkaXNwYXRjaF0gZHJhZnQtd2VpbnJvbmstZGlzcGF0Y2gtbGFzdC1kaXZlcnRpbmct bGluZS1pZA0KVGhlcmUgaXMgYSBkYW5nZXIgaGVyZSB0aGF0IHRoaXMgcHVycG9zZSBjb3VsZCBi ZSBzdXBwb3J0ZWQgYnkgdHdvIGRpZmZlcmVudCBoZWFkZXJzDQooYSBuZXcgaGVhZGVyIG9yIGFu IG9sZCBoZWFkZXIpIHdpdGggcG90ZW50aWFsIG5lZ2F0aXZlIGNvbnNlcXVlbmNlcy4NCg0KUGxl YXNlIHNob3cgd2hhdCBwcmV2ZW50cyB5b3UgZnJvbSBzdXBwb3J0aW5nIHRoaXMgcHVycG9zZSB3 aXRoIEhpc3RvcnktSW5mbz8NCg0KVGhlIGFyZ3VtZW50IHRoYXQgYmVjYXVzZSBBIGlzIHN1cHBv cnRlZCBieSBCLCB0aGVyZWZvcmUgQyBpcyBub3Qgc3VwcG9ydGVkIGJ5IEIsIGlzIGlsbG9naWNh bC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1pY2hhZWwgSGFtbWVyDQpt aWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tPG1haWx0bzptaWNoYWVsLmhhbW1lckB5YWFuYXRl Y2guY29tPg0KKzEgNDA4IDIwMiA5MjkxDQoNCsKpIDIwMTYgWWFhbmEgVGVjaG5vbG9naWVzLCBM TEMuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuIEVtYWlsIGNvbmZpZGVudGlhbGl0eSBub3RpY2UuIFRo aXMgbWVzc2FnZSBpcyBwcml2YXRlIGFuZCBjb25maWRlbnRpYWwuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBhbmQgcmVtb3ZlIGl0 IGZyb20geW91ciBzeXN0ZW0uDQoNCkZyb206IGRpc3BhdGNoIFttYWlsdG86ZGlzcGF0Y2gtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE4gV0VJTlJPTksNClNlbnQ6IFdlZG5lc2RheSwg TWFyY2ggMDksIDIwMTYgNjowNSBBTQ0KVG86IGtlaXRoLmRyYWdlQG5va2lhLmNvbTxtYWlsdG86 a2VpdGguZHJhZ2VAbm9raWEuY29tPjsgZGlzcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNo QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gZHJhZnQtd2VpbnJvbmstZGlzcGF0 Y2gtbGFzdC1kaXZlcnRpbmctbGluZS1pZA0KDQoNCg0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29t bWVudHMgb24gdGhpcyBJbnRlcm5ldCBEcmFmdCDigJMgSSB3aWxsIHRyeSBhbmQgYW5zd2VyIHlv dXIgcG9pbnRzLg0KDQpEbyB5b3UgYmVsaWV2ZSBpdCBpcyBsZWdhY3kgZnJvbSB0aGUgZWFybHkg SVNETiBkZWZpbml0aW9ucyBvciBkbyB5b3UgYmVsaWV2ZSBpdCBpcyBuZXc/DQoNCk5laXRoZXIg aXQgYSBjb25zZXF1ZW5jZSBvZiB0aGUgd2F5IEVUU0kgSVNETiB3YXMgaW1wbGVtZW50ZWQgaW4g dGhlIFVLIGluIHRoZSAxOTkwcyB0aGF0IGlzIHN0aWxsIGluIHVzZSB0b2RheSDigJMgc2VlIGJl bG93Lg0KDQpOb3RlOiBJIGFzc3VtZSBieSBlYXJseSBJU0ROIGRlZmluaXRpb25zIHlvdSBtZWFu IHdoZXJlIEVUU0kgSVNETiB3YXMgbWFwcGVkIHRvIERBU1MgYW5kIEkgYW0gbm90IHRhbGtpbmcg YWJvdXQgdGhpcy4NCg0KQ2FuIHlvdSBleHBsYWluIHdoZXJlIGEgcHJvcG9zZWQgVUsgcmVxdWly ZW1lbnQgY29tZXMgZnJvbSB0aGF0IGlzIG5vdCBjb250YWluZWQgd2l0aGluIHRoZSBFVFNJIGFu ZCBJVFUtVCBzZXJ2aWNlIGRlZmluaXRpb25zIGZvciB0aGUgSVNETj8NCg0KVGhpcyBjb21lcyBm cm9tIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIGluIHRoZSBVSyBiYXNlZCBvbiBOSUNDIE5EMTAw Ny4NCg0KSW4gVUsgSVNVUCB0aGVyZSBpcyBhIHBhcmFtZXRlciBvcHRpb25hbCBpbiB0aGUgSUFN IOKAkyBMYXN0IERpdmVydGVkIExpbmUgSWRlbnRpdHkgaW4gYWRkaXRpb25hbCB0byB0aGUgSVRV L0VUU0kgcGFyYW1ldGVyIFJlZGlyZWN0aW5nIE51bWJlci4NCg0KVGhlcmUgYXJlIHRpbWVzIHdo ZW4gdGhlc2UgcGFyYW1ldGVycyBhcmUgYm90aCBwcmVzZW50IGFuZCBjYW4gaG9sZCBkaWZmZXJl bnQgaW5mb3JtYXRpb24uDQoNCllvdSBjb3VsZCBzZWUgdGhpcyBhcyBiZWluZyBhbmFsb2dvdXMg dG8gRlJPTSBhbmQgUC1Bc3NlcnRlZC1JZCBoZWFkZXJzIGluIFNJUCB3aXRoIHRoZSBMYXN0IERp dmVydGVkIExpbmUgSWRlbnRpdHkgcGFyYW1ldGVyIGJlaW5nIHRoZSDigJhuZXR3b3JrIGFzc2Vy dGVkIGlkZW50aXR54oCZIHVzZWQgYnkgbmV0d29ya3Mgb3RoZXIgdGhhdCB0aGUgbmV0d29yayBk aXZlcnRpbmcgdGhlIGNhbGwgdG8gdmVyaWZ5IHNlcnZpY2UgYW5kIHRoZSBSZWRpcmVjdGluZyBO dW1iZXIgcGFyYW1ldGVyIGJlaW5nIHRoZSDigJhwcmVzZW50YXRpb24gbnVtYmVy4oCZLg0KDQpU aGUgY2FzZXMgSSBhbSBhd2FyZSBvZiB3aGVyZSB0aGVzZSBwYXJhbWV0ZXJzIGNhbiBob2xkIGRp ZmZlcmVudCBpbmZvcm1hdGlvbiBjb21lIGZyb20gRVRTSSBJU0ROIGRpdmVyc2lvbiBzY2VuYXJp b3Mg4oCTIENhbGwgRm9yd2FyZGluZyBVbmNvbmRpdGlvbmFsIC8gQ2FsbCBGb3J3YXJkaW5nIEJ1 c3kgLyBDYWxsIEZvcndhcmRpbmcgTm8gUmVwbHkgLyBDYWxsIERlZmxlY3Rpb24gLyBQYXJ0aWFs IFJlcm91dGluZy4NCg0KRm9yIFBhcnRpYWwgUmVyb3V0aW5nIHRoZSBMYXN0IERpdmVydGVkIExp bmUgSWRlbnRpdHkgcGFyYW1ldGVyIGlzIGJhc2VkIG9uIHRoZSDigJhhZG1pbmlzdHJhdGlvbiBu dW1iZXLigJkgYXMgdW5kZXJzdG9vZCBieSB0aGUgbmV0d29yayBkb2luZyB0aGUgZGl2ZXJzaW9u IGFuZCB0aGUgbmV0d29yayBkb2luZyB0aGUgdmVyaWZpY2F0aW9uIGFuZCBiaWxsaW5nIGZvciB0 aGVzZSBjYWxscy4gVGhlIFJlZGlyZWN0aW5nIE51bWJlciBwYXJhbWV0ZXIgaXMgc2V0IGZyb20g dGhlIGxhc3RSZXJvdXRpbmdOciBmcm9tIHRoZSBBU04uMSB0aGUgcHJpdmF0ZSBuZXR3b3JrIHNl dHMgaW4gdGhlIFEuOTMxIFNFVFVQIG1lc3NhZ2Ug4oCTIHRoZXNlIGNhbi93aWxsIGJlIGRpZmZl cmVudC4NCg0KRm9yIENhbGwgRm9yd2FyZGluZyBVbmNvbmRpdGlvbmFsIC8gQ2FsbCBGb3J3YXJk aW5nIEJ1c3kgLyBDYWxsIEZvcndhcmRpbmcgTm8gUmVwbHkgLyBDYWxsIERlZmxlY3Rpb24gdGhl IExhc3QgRGl2ZXJ0ZWQgTGluZSBJZGVudGl0eSBwYXJhbWV0ZXIgaXMgYmFzZWQgb24gdGhlIOKA mGFkbWluaXN0cmF0aW9uIG51bWJlcuKAmSBhcyB1bmRlcnN0b29kIGJ5IHRoZSBuZXR3b3JrIGRv aW5nIHRoZSBkaXZlcnNpb24gYW5kIHRoZSBuZXR3b3JrIGRvaW5nIHRoZSB2ZXJpZmljYXRpb24g YW5kIGJpbGxpbmcgZm9yIHRoZXNlIGNhbGxzLiBUaGUgUmVkaXJlY3RpbmcgTnVtYmVyIHBhcmFt ZXRlciBpcyBzZXQgdG8gdGhlIENhbGxlZCBQYXJ0eSBOdW1iZXIgdXNlZCB0byByZWFjaCB0aGUg ZGl2ZXJ0aW5nIHBhcnR5IOKAkyB0aGVzZSBhcmUgbm90IG5lY2Vzc2FyaWx5IHRoZSBzYW1lLg0K DQpJ4oCZZCBhbHNvIG5vdGUgdGhhdCBJIGJlbGlldmUgaWYgdGhpcyBpcyByZXF1aXJlZCB0aGVu IGFuIGFkZGl0aW9uIHRvIHRoZSBIaXN0b3J5LUluZm8gaGVhZGVyIGZpZWxkIHdvdWxkIGJlIG1v cmUgYXBwcm9wcmlhdGUuDQoNCldlIChteXNlbGYgYW5kIHRoZSBVSyBOSUNDIFNJUCBUYXNrIEdy b3VwKSBkaWQgY29uc2lkZXIgdXNpbmcgdGhlIEhpc3RvcnktSW5mbyBoZWFkZXIgZm9yIHRoaXMg YnV0IGFzIHRoZSBtYXBwaW5ncyBhcmUgYWxyZWFkeSBkZWZpbmVkIGZyb20gUmVkaXJlY3Rpbmcg TnVtYmVyIHBhcmFtZXRlciB0byBIaXN0b3J5LUluZm8gYnkgdGhlIElFVEYgLyBFVFNJIC8gSVRV IGl0IHdhcyBmZWx0IHRoaXMgd291bGQgYmUgY29uZnVzaW5nIGFuZCBtYWtlIHRoZSBtYXBwaW5n cyBjb21wbGljYXRlZC4NCg0KQWxzbyBJIHdvdWxkIGV4cGVjdCB0aGlzIGhlYWRlciB0byAobGlr ZSB0aGUgTGFzdCBEaXZlcnRlZCBMaW5lIElkZW50aXR5IHBhcmFtZXRlciBpbiBVSyBJU1VQKSBi ZSBsaW1pdGVkIGluIHdoZXJlIGl0IGNhbiBiZSBzZW50IGllLiBiZXR3ZWVuIG5ldHdvcmsgb3Bl cmF0b3JzIGFuZCBub3QgdG8gZW5kIHVzZXJzIGFnYWluIG1ha2luZyB1c2Ugb2YgSGlzdG9yeS1J bmZvIG1vcmUgY29tcGxpY2F0ZWQuDQoNCk5pZ2VsIFdlaW5yb25rDQoNCg0KLS0tLU9yaWdpbmFs IG1lc3NhZ2UtLS0tDQpGcm9tIDoga2VpdGguZHJhZ2VAbm9raWEuY29tPG1haWx0bzprZWl0aC5k cmFnZUBub2tpYS5jb20+DQpEYXRlIDogMDkvMDMvMjAxNiAtIDAyOjQ3IChHTVRTVCkNClRvIDog UGhpbC5IdXRjaGlzb25AdmlyZ2lubWVkaWEuY28udWs8bWFpbHRvOlBoaWwuSHV0Y2hpc29uQHZp cmdpbm1lZGlhLmNvLnVrPiwgZGlzcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoQGlldGYu b3JnPg0KU3ViamVjdCA6IFJlOiBbZGlzcGF0Y2hdIGRyYWZ0LXdlaW5yb25rLWRpc3BhdGNoLWxh c3QtZGl2ZXJ0aW5nLWxpbmUtaWQNCkNhbiB5b3UgZXhwbGFpbiB3aGVyZSBhIHByb3Bvc2VkIFVL IHJlcXVpcmVtZW50IGNvbWVzIGZyb20gdGhhdCBpcyBub3QgY29udGFpbmVkIHdpdGhpbiB0aGUg RVRTSSBhbmQgSVRVLVQgc2VydmljZSBkZWZpbml0aW9ucyBmb3IgdGhlIElTRE4/DQoNCkRvIHlv dSBiZWxpZXZlIGl0IGlzIGxlZ2FjeSBmcm9tIHRoZSBlYXJseSBJU0ROIGRlZmluaXRpb25zIG9y IGRvIHlvdSBiZWxpZXZlIGl0IGlzIG5ldz8NCg0KSeKAmWQgYWxzbyBub3RlIHRoYXQgSSBiZWxp ZXZlIGlmIHRoaXMgaXMgcmVxdWlyZWQgdGhlbiBhbiBhZGRpdGlvbiB0byB0aGUgSGlzdG9yeS1J bmZvIGhlYWRlciBmaWVsZCB3b3VsZCBiZSBtb3JlIGFwcHJvcHJpYXRlLg0KDQpSZWdhcmRzDQoN CktlaXRoIERyYWdlDQoNCkZyb206IGRpc3BhdGNoIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVYVCBIdXRjaGlzb24sIFBoaWwNClNlbnQ6IDA0IE1hcmNo IDIwMTYgMDg6MjANClRvOiAnZGlzcGF0Y2hAaWV0Zi5vcmcnDQpTdWJqZWN0OiBbZGlzcGF0Y2hd IGRyYWZ0LXdlaW5yb25rLWRpc3BhdGNoLWxhc3QtZGl2ZXJ0aW5nLWxpbmUtaWQNCg0KSGksDQoN CkkgYmVsaWV2ZSB0aGF0IHRoaXMgaXMgcmVxdWlyZWQgaW4gdGhlIFVLLCBhbmQgdGhlcmVmb3Jl IHdvdWxkIGxpa2UgdG8gc2VlIHRoZSBkcmFmdCBhY2NlcHRlZC4NCg0KUmVnYXJkcw0KDQpQaGls DQp+fn5+fn5+fn5+fn5+fn5+fg0KUGhpbCBIdXRjaGlzb24NCkxpYmVydHkgR2xvYmFsIENBTyAt IENvbW11bmljYXRpb25zIEFyY2hpdGVjdHVyZQ0KTW9iaWxlICs0NDc3NzUgOTM4ODI3IHwgU29m dCBDbGllbnQgKzQ0KDApMzcwMyA5MDA0NjQgfCBFbWFpbCBwaGlsLmh1dGNoaXNvbkB2aXJnaW5t ZWRpYS5jby51azxtYWlsdG86cGhpbC5odXRjaGlzb25AdmlyZ2lubWVkaWEuY28udWs+DQpNZWV0 IE1lIENvbmZlcmVuY2U6IDA4MDggMTA3NDQ0NCAgWys0NCAxNzIzMjA0NDQ0XSBQSU4gMTI1NjQ1 MCMNClZpc2l0IHd3dy52aXJnaW5tZWRpYS5jby51azxodHRwOi8vd3d3LnZpcmdpbm1lZGlhLmNv LnVrLz4gZm9yIG1vcmUgaW5mb3JtYXRpb24sIGFuZCBtb3JlIGZ1bg0KU2F2ZSBwYXBlciAtIGRv IHlvdSByZWFsbHkgbmVlZCB0byBwcmludCB0aGlzIGVtYWlsPw0KDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpT YXZlIFBhcGVyIC0gRG8geW91IHJlYWxseSBuZWVkIHRvIHByaW50IHRoaXMgZS1tYWlsPw0KDQpW aXNpdCB3d3cudmlyZ2lubWVkaWEuY29tPGh0dHA6Ly93d3cudmlyZ2lubWVkaWEuY29tPiBmb3Ig bW9yZSBpbmZvcm1hdGlvbiwgYW5kIG1vcmUgZnVuLg0KDQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIG9yIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJpdmlsZWdl ZA0KYW5kIGFyZSBzZW50IHNvbGVseSBmb3IgdGhlIGF0dGVudGlvbiBvZiB0aGUgYWRkcmVzc2Vl KHMpLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzDQplbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRl bGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtOiBpdHMgdXNlLCBkaXNjbG9zdXJlIG9yIGNvcHlpbmcg aXMNCnVuYXV0aG9yaXNlZC4gU3RhdGVtZW50cyBhbmQgb3BpbmlvbnMgZXhwcmVzc2VkIGluIHRo aXMgZW1haWwgbWF5IG5vdCByZXByZXNlbnQNCnRob3NlIG9mIFZpcmdpbiBNZWRpYS4gQW55IHJl cHJlc2VudGF0aW9ucyBvciBjb21taXRtZW50cyBpbiB0aGlzIGVtYWlsIGFyZQ0Kc3ViamVjdCB0 byBjb250cmFjdC4NCg0KUmVnaXN0ZXJlZCBvZmZpY2U6IE1lZGlhIEhvdXNlLCBCYXJ0bGV5IFdv b2QgQnVzaW5lc3MgUGFyaywgSG9vaywgSGFtcHNoaXJlLCBSRzI3IDlVUA0KUmVnaXN0ZXJlZCBp biBFbmdsYW5kIGFuZCBXYWxlcyB3aXRoIG51bWJlciAyNTkxMjM3DQoNCg0KDQoNCg0KDQoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2Nl cHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4K ClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh dXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLgpUaGFuayB5b3UuCgo= --_000_8B970F90C584EA4E97D5BAAC9172DBB8158472E0OPEXCLILMA4corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkFyaWFsIE5hcnJv dyI7DQoJcGFub3NlLTE6MiAxMSA2IDYgMiAyIDIgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2 LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOiMxRjQ5N0Q7DQoJ dGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LXNoYWRvdzpub25lOw0KCWZvbnQtd2VpZ2h0Om5v cm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lOw0K CXZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlRleHRl ZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RlI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjMxNTY5NDA5ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6MTE2NTY4MzY4OCA4NDA0NTI3NTQgNjc4OTUyOTkgNjc4OTUzMDEgNjc4 OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDE7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRlYXIgTmlnZWwsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFmdGVyIGEgcmVh ZGluZyBvZiB0aGUgZHJhZnQsIEkgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzJm5ic3A7Ojxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkZpcnN0LCBJIHdvbmRlciBhYm91dCBo YXZpbmcgYSBzdGFuZGFyZCwgZXZlbiBpbmZvcm1hdGlvbmFsLCB0byBzb2x2ZSBhIGNvdW50cnkt c3BlY2lmaWMgbmVlZCB0byBjb252ZXkgYW4gSVNVUCBOYXRpb25hbCBwYXJhbWV0ZXLigKZodW08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TZWNvbmQsIEkgZG8gdGhpbmsgd2Ug Y2FuIGZpbmQgYSBzb2x1dGlvbiB0byBzb2x2ZSB5b3VyIGlzc3VlIGJ5IHVzaW5nIHRoZSBIaXN0 b3J5LUluZm8gaGVhZGVyLiBJIGRvbuKAmXQga25vdyB5ZXQgaG93Lg0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SUlV QywgeW91IG5lZWQgdG8gY29udmV5IHRoZSBhc3NlcnRlZCBpZGVudGl0eSBvZiB0aGUgZGl2ZXJ0 aW5nIHVzZXIgaW50byB0aGUgZm9yd2FyZGVkIGxlZyBldmVuIHdoZW4gaGUgaGFzIGJlZW4gY2Fs bGVkIHRvIGhpcyBkZWNsYXJhdGl2ZSBpZGVudGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPkkgc2VlIHNldmVyYWwgbWVjaGFuaXNtcyBpbiBIaXN0b3J5LUluZm8gaGVhZGVyIHRoYXQg Y291bGQgYmUgdXNlZCBmb3IgdGhpcyBwdXJwb3NlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4t PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPmZpcnN0IHlvdSBzaG91bGQga25vdyB0aGF0IGl0IGNhbiBiZSBhZGRlZCBhZGRp dGlvbmFsIGVudHJpZXMgaW4gdGhlIEhpc3RvcnktSW5mbyBoZWFkZXIgZXZlbiB3aGVuIHRoZSBS ZXF1ZXN0IFVSSSBkb2VzIG5vdCBjaGFuZ2UuIEluIHRoaXMgY2FzZSwgdGhlIGluZGV4IHNob3Vs ZCBiZSBpbmNyZWFzZWQgKDEtJmd0OzIpIGFuZA0KIG5vdCBleHRlbmRlZCAoMSAtJmd0OyAxLjEp IGFzIHdoZW4gZm9ya2luZyBpcyBleGVjdXRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPnRvIGJlIGFibGUgdG8gZGlzdGluZ3Vpc2ggdGhpcyBpZGVudGl0eSBmcm9tIHRoZSBu b3JtYWwgZGl2ZXJ0aW5nIGlkZW50aXR5LCB5b3UgY291bGQgdXNlIHRoZSAmcXVvdDtyYyZxdW90 OyBoaS10YXJnZXQtcGFyYW0gdG8gcmVmZXIgdG8gdGhlIG5vcm1hbCBIaXN0b3J5LUluZm8gZW50 cnkgZm9yIHRoZSBkaXZlcnNpb24gYW5kIGxpbmsgYm90aC4NCiBXaXRoIHRoaXMgbWVjaGFuaXNt LCBhdCB0aGUgaW50ZXJ3b3JraW5nIHlvdSBjb3VsZCBmaW5kIHRoZSBsYXN0IGRpdmVydGluZyBp ZGVudGl0eSBhcyBkZXNjcmliZWQgaW4gMjkuMTYzIGFuZCB0aGVuIHNlYXJjaCBmb3IgdGhlIGVu dHJ5IGhhdmluZyBhICZxdW90O3JjJnF1b3Q7IHBhcmFtZXRlciBoYXZpbmcgYSB2YWx1ZSBlcXVh bHMgdG8gdGhlIGN1cnJlbnQgKGxhc3QgZGl2ZXJ0aW5nIGFkZHJlc3MpIGhpLWVudHJ5IGluZGV4 IHZhbHVlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ZmluYWxseSwgeW91 IGNvdWxkIGltYWdpbmUgYSBkZWRpY2F0ZWQgY2F1c2UgVVJJIHBhcmFtZXRlciAoZGlmZmVyZW50 IGZyb20gdGhvc2UgZGVmaW5lZCBpbiBSRkM0NDU4IGZvciBjYWxsIGRpdmVyc2lvbiBzZXJ2aWNl KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk1hcmlhbm5lPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gZGlzcGF0 Y2ggW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwv Yj4gTiBXRUlOUk9OSzxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSA5IG1hcnMg Mjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MDE2IDIzOjA4PGJyPg0KPGI+w4Am bmJzcDs6PC9iPiBtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tOyBrZWl0aC5kcmFnZUBub2tp YS5jb207IGRpc3BhdGNoQGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW2Rp c3BhdGNoXSBkcmFmdC13ZWlucm9uay1kaXNwYXRjaC1sYXN0LWRpdmVydGluZy1saW5lLWlkPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPk5vdCBzdXJlIEkgYWdyZWUgd2l0 aCB0aGUgbm9uLXNlcXVpdHVyIHN0YXRlbWVudCBidXQgbGV0cyBtb3ZlIG9uLjxvOnA+PC9vOnA+ PC9wPg0KPHA+TGV0IHVzIGV4cGxvcmUgdGhlIHN0YXRlbWVudCB0aGF0IEhpc3RvcnktSW5mbyAm cXVvdDtzaG91bGQmcXVvdDsgd29yayBhIGxpdHRsZSBtb3JlOjxvOnA+PC9vOnA+PC9wPg0KPHA+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5DYW4geW91IGV4cGxhaW4gaG93IDEgZW50cnkgY2Fu IGhhdmUgYSAncHJlc2VudGF0aW9uJyBhbmQgYSAnbmV0d29yayBhc3NlcnRlZCcgaWRlbnRpdHkg dGhhdCBjYW4gYmUgZGlmZmVyZW50IC0gd2VyZSB5b3UgdGhpbmtpbmcgb2YgdGhlIGhpLWV4dGVu c2lvbiA/PG86cD48L286cD48L3A+DQo8cD5KdXN0IHRvIGFkZCB0byB0aGlzIGluIHRoZSBVSyAo SSBjYW4gb25seSByZWFsbHkgY29tbWVudCBvbiB0aGlzKSB0aGUgc3BlY2lmaWNhdGlvbiBvZiBF VFNJIElTRE4gZGl2ZXJzaW9uIHNlcnZpY2VzJm5ic3A7bWFuZGF0ZXMgdGhhdCBib3RoJm5ic3A7 dGhlICduZXR3b3JrIGFzc2VydGVkJyBhbmQgdGhlICdwcmVzZW50YXRpb24nIGlkZW50aXRpZXMg b2YgdGhlIERpdmVydGluZyBQYXJ0eSBhcmUgcGFzc2VkIGJldHdlZW4gb3BlcmF0b3IgbmV0d29y a3Mgb24NCiBEaXZlcnRlZCBjYWxscy48bzpwPjwvbzpwPjwvcD4NCjxwPlRoaXMgYWxsb3dzICd0 cmFuc2l0JyBvcGVyYXRvcnMgaGFuZGxpbmcgQ2FycmllciBQcmUtc2VsZWN0IERpdmVydGVkIGNh bGxzIHRvIHZlcmlmeSBhbmQgYmlsbCB0aGUgdXNlci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw PkFsbCB0aGUmbmJzcDtkb2N1bWVudHMgSSBoYXZlIHNlZW4gYmUgaXQgM0dQUC9JRVRGIG1hcHMg SGlzdG9yeS1JbmZvIGludG8gUmVkaXJlY3RpbmcgTnVtYmVyIC0gUmVkaXJlY3RpbmcgTnVtYmVy IGRvZXMgbm90IGhhdmUgYSBzY3JlZW5pbmcgaW5kaWNhdG9yIGFuZCBpcyB1c2VkIGRpcmVjdGx5 IGZvciBkaXNwbGF5Jm5ic3A7aW4gRVRTSSBJU0ROLg0KPG86cD48L286cD48L3A+DQo8cD5JbiBj YXNlcyB3aGVyZSB0aGUgJ25ldHdvcmsgYXNzZXJ0ZWQnIGlkZW50aWZ5IGlzIGRpZmZlcmVudCBm cm9tIHRoZSAncHJlc2VudGF0aW9uJyBpZGVudGl0eSZuYnNwO2l0IGlzIG5vdCBjbGVhciB0byBt ZSBob3cgdGhlIGluZm9ybWF0aW9uIGluIHRoZSBIaXN0b3J5LUluZm8gaGVhZGVyIGNhbiBiZSAn bmV0d29yayBhc3NlcnRlZCcuPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwPkkgZG8gbm90IHRoaW5rIGl0IGlzICd0aGlzIGRpdmVyc2lvbicgdGhhdCBpcyBkaWZm ZXJlbnQgaXQgaXMgdGhlIGFiaWxpdHkgdG8gY29uc2lzdGVudGx5IHBhc3MmbmJzcDsnbmV0d29y ayBhc3NlcnRlZCcgYW5kICdwcmVzZW50YXRpb24nIGlkZW50aXRpZXMmbmJzcDtmb3IgRGl2ZXJz aW9uIGluZm9ybWF0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cD5Ob3Qgc3VyZSBob3cgU1RJUiBpcyByZWxhdGVkID8mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+VGhhbmtzLDxvOnA+PC9vOnA+PC9w Pg0KPHA+TmlnZWw8bzpwPjwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDoxMS4yNXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+LS0tLU9yaWdpbmFsIG1lc3NhZ2UtLS0tPGJyPg0KJmd0 O0Zyb20gOiA8YSBocmVmPSJtYWlsdG86bWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbSI+bWlj aGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTwvYT48YnI+DQpEYXRlIDogMDkvMDMvMjAxNiAtIDIw OjEzIChHTVRTVCk8YnI+DQpUbyA6IDxhIGhyZWY9Im1haWx0bzpud2VpbnJvbmtAYnRpbnRlcm5l dC5jb20iPm53ZWlucm9ua0BidGludGVybmV0LmNvbTwvYT4sIDxhIGhyZWY9Im1haWx0bzprZWl0 aC5kcmFnZUBub2tpYS5jb20iPg0Ka2VpdGguZHJhZ2VAbm9raWEuY29tPC9hPiwgPGEgaHJlZj0i bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnIj5kaXNwYXRjaEBpZXRmLm9yZzwvYT48YnI+DQpTdWJq ZWN0IDogUkU6IFJFOiBbZGlzcGF0Y2hdIGRyYWZ0LXdlaW5yb25rLWRpc3BhdGNoLWxhc3QtZGl2 ZXJ0aW5nLWxpbmUtaWQ8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5OaWdlbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPllvdXIgbG9n aWMgd2FzIGEgbm9uLXNlcXVpdG9yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5MaWtlIHNheWluZyBjYXRzIGxp a2UgbWlsaywgdGhlcmVmb3JlIGRvbuKAmXQgZ2l2ZSBjaG9jb2xhdGUgdG8gYSBkb2cuJm5ic3A7 DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+VGhlIGNvbmNsdXNpb24gaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBj YXRzIGFuZCBtaWxrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U28sIHdo aWxlIHN1Y2ggbG9naWMgaXMgbm90IGNvbmNsdXNpdmUgZm9yIG9yIGFnYWluc3QgYSBzZXBhcmF0 ZSBoZWFkZXIsDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+dGhlIGJ1cmRlbiBvZiBwcm9vZiBmb3IgYSBzZXBh cmF0ZSBoZWFkZXIgc2hvdWxkIGxpZSBvbiB0aGUgb25lIHByb3Bvc2luZyBhIG5ldyBoZWFkZXIs DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+d2hlbiBmYWNlIHdpdGggdGhlIGV4aXN0aW5nIG9mIGEgaGVhZGVy IHRoYXQg4oCcc2hvdWxk4oCdIHdvcmsuJm5ic3A7ICh0aGUgcXVlc3Rpb24gYXQgaGFuZCk8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkEgc2VwYXJhdGUgaGVhZGVyIGlzIHdh cnJhbnRlZCB3aGVuIGFuIGV4aXN0aW5nIGhlYWRlciBoYXMgdGhlIHdyb25nIHNlbWFudGljcw0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPmFuZCB0aGUgZXhpc3Rpbmcgc3ludGF4IGp1c3Qgd29u4oCZdCB3b3Jr LiAmbmJzcDtIb3dldmVyLCB0aGF0IGRvZXNu4oCZdCBzZWVtIHRvIGJlIHRoZSBjYXNlLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SWYgYW5vdGhlciBpbXBsZW1lbnRhdGlv biBqdWRnZXMgdGhhdCB0aGUgSC1JIGhlYWRlciBpcyBhIHBlcmZlY3QgZml0LCB0aGVuIHlvdSB3 b27igJl0IGJlIGxvb2tpbmcgdGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNvbWUgZXhpc3RpbmcgaW1w bGVtZW50YXRpb25zIGp1c3QgbWlnaHQgYmUgZG9pbmcgdGhpcyBhbHJlYWR5Ljwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5TbywganVzdCB3YW50IHRvIGJlIGNhcmVmdWwgYWJvdXQgd2lsbHkgbmlsbHkgYWRkaW5n IG5ldyBoZWFkZXJzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSB3b3Vs ZCBub3RlIHRoYXQgYm90aCB0aGUgUm91dGUgaGVhZGVyIGFuZCB0aGUgSC1JIGhlYWRlciBjYW4g YmUg4oCcbmV0d29yayBhc3NlcnRlZOKAnS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U28sIHdoYXQgbWFrZXMg dGhpcyBwYXJ0aWN1bGFyIGRpdmVyc2lvbiBkaWZmZXJlbnQgZnJvbSBILUkgZW52aXNhZ2VkPzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WW91IG1ha2UgaXQgc291bmQgbGlr ZSBpdCBzaG91bGQgYmUgcGFydCBvZiB0aGUgU1RJUiBkaXNjdXNzaW9uLCB3aGVuIHlvdSBjb21w YXJlIHRvIFAtQXNzZXJ0ZWQtSUQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhhdmUgeW91IGxvb2tlZCBpbnRv IHRoYXQgV0c/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4wcHQ7YmFja2dyb3VuZDp3 aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwgTmFycm93JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0E4MTQwMCI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjBwdDtiYWNrZ3Jv dW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCBOYXJyb3cmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQTgx NDAwIj5NaWNoYWVsIEhhbW1lcjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsIE5hcnJv dyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWls dG86bWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbSI+bWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNo LmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCBOYXJyb3cm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+JiM0MzsxPGI+Jm5ic3A7 PC9iPjQwOCAyMDIgOTI5MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Y29sb3I6YmxhY2siPjxicj4NCsKpIDIw MTYgWWFhbmEgVGVjaG5vbG9naWVzLCBMTEMuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuIEVtYWlsIGNv bmZpZGVudGlhbGl0eSBub3RpY2UuIFRoaXMgbWVzc2FnZSBpcyBwcml2YXRlIGFuZCBjb25maWRl bnRpYWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB1cyBhbmQgcmVtb3ZlIGl0IGZyb20geW91ciBzeXN0ZW0uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBOIFdFSU5ST05LIFs8YSBocmVmPSJtYWlsdG86bndlaW5yb25rQGJ0aW50ZXJuZXQu Y29tIj5tYWlsdG86bndlaW5yb25rQGJ0aW50ZXJuZXQuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBXZWRuZXNkYXksIE1hcmNoIDA5LCAyMDE2IDI6MDAgUE08YnI+DQo8Yj5Ubzo8L2I+IE1p Y2hhZWwgSGFtbWVyICZsdDs8YSBocmVmPSJtYWlsdG86bWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNo LmNvbSI+bWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFp bHRvOmtlaXRoLmRyYWdlQG5va2lhLmNvbSI+a2VpdGguZHJhZ2VAbm9raWEuY29tPC9hPjsgPGEg aHJlZj0ibWFpbHRvOmRpc3BhdGNoQGlldGYub3JnIj4NCmRpc3BhdGNoQGlldGYub3JnPC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUkU6IFtkaXNwYXRjaF0gZHJhZnQtd2VpbnJvbmstZGlz cGF0Y2gtbGFzdC1kaXZlcnRpbmctbGluZS1pZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwPlRoYW5rcyBmb3IgeW91ciB0aW1lLjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cD5QbGVhc2UgZXhwbGFpbiB0aGUgbmVnYXRpdmUgY29uc2VxdWVuY2VzIG9m IGEgc2VwYXJhdGUgaGVhZGVyID88bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHA+VGhlIG9ubHkgcGxhY2UgSSBzYXcgdGhhdCB0aGlzIGNvdWxkIGhhdmUgYmVlbiBw bGFjZWQgaW4gSGlzdG9yeS1JbmZvIHdhcyBhcyBhbiBoaS1leHRlbnNpb24gYmVjYXVzZSBpdCBp cyByZWFsbHkmbmJzcDthICduZXR3b3JrIGFzc2VydGVkIGlkJyBvZiB0aGUgaGktdGFyZ2V0ZWQt dG8tdXJpJm5ic3A7YW5kIHRoaXMgd291bGQgcGxhY2UgcmVxdWlyZW1lbnRzIG9uIGxvdHMgb2Yg ZnVuY3Rpb25zIHRvIHNlYXJjaCBIaXN0b3J5LUluZm8gZW50cmllcyB0byByZW1vdmUNCiB0aGlz ICduZXR3b3JrIGFzc2VydGVkJyBpZGVudGl0eSB3aGVuIHJlcXVpcmVkLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHA+VG8gbWUgdGhpcyBpcyB0aGUgc2FtZSBhcyBGcm9tIC8gUC1Bc3NlcnRlZC1J ZGVudGl0eSAtIHRoZSBQLUFzc2VydGVkX0lkZW50aXR5IHdhcyBub3QgcGxhY2UgaW4gdGhlIEZy b20gaGVhZGVyIGFzIGEgcGFyYW1ldGVyIC0gSSBndWVzcyBpdCBjb3VsZCBoYXZlIGJlZW4uPG86 cD48L286cD48L3A+DQo8cD5JIHRoaW5rIHRoZSBzYW1lIGFyZ3VtZW50IGFwcGxpZXMgaGVyZSBp biBrZWVwaW5nIHRoZSAnbmV0d29yayBhc3NlcnRlZCBpZGVudGl0eScgYW5kIHRoZSAncHJlc2Vu dGF0aW9uIGlkZW50aXR5JyBmb3IgdGhlIHNhbWUgdXNlciBhcGFydCBpbiB0aGUgc2lnbmFsbGlu Zy48bzpwPjwvbzpwPjwvcD4NCjxwPk5vdGU6IFRoaXMgYWxzbyBtYXRjaGVzIHRoZSBJU1VQIGlt cGxlbWVudGF0aW9uIC0gYSBzZXBhcmF0ZSBkaXN0aW5jdCBwYXJhbWV0ZXIuPG86cD48L286cD48 L3A+DQo8cD5JIHNlZSBub3RoaW5nIGlsbG9naWNhbCBpbiBhIHNlcGFyYXRlIGhlYWRlci48bzpw PjwvbzpwPjwvcD4NCjxwPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwPk5pZ2VsPG86cD48L286 cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tbGVmdDoxMS4yNXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+LS0tLU9yaWdpbmFsIG1lc3NhZ2UtLS0tPGJyPg0KRnJvbSA6IDxhIGhyZWY9Im1h aWx0bzptaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tIj5taWNoYWVsLmhhbW1lckB5YWFuYXRl Y2guY29tPC9hPjxicj4NCkRhdGUgOiAwOS8wMy8yMDE2IC0gMTc6MjAgKEdNVFNUKTxicj4NClRv IDogPGEgaHJlZj0ibWFpbHRvOm53ZWlucm9ua0BidGludGVybmV0LmNvbSI+bndlaW5yb25rQGJ0 aW50ZXJuZXQuY29tPC9hPiwgPGEgaHJlZj0ibWFpbHRvOmtlaXRoLmRyYWdlQG5va2lhLmNvbSI+ DQprZWl0aC5kcmFnZUBub2tpYS5jb208L2E+LCA8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2hAaWV0 Zi5vcmciPmRpc3BhdGNoQGlldGYub3JnPC9hPjxicj4NClN1YmplY3QgOiBSRTogW2Rpc3BhdGNo XSBkcmFmdC13ZWlucm9uay1kaXNwYXRjaC1sYXN0LWRpdmVydGluZy1saW5lLWlkPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ VGhlcmUgaXMgYSBkYW5nZXIgaGVyZSB0aGF0IHRoaXMgcHVycG9zZSBjb3VsZCBiZSBzdXBwb3J0 ZWQgYnkgdHdvIGRpZmZlcmVudCBoZWFkZXJzDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+KGEgbmV3IGhlYWRl ciBvciBhbiBvbGQgaGVhZGVyKSB3aXRoIHBvdGVudGlhbCBuZWdhdGl2ZSBjb25zZXF1ZW5jZXMu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5QbGVhc2Ugc2hvdyB3aGF0IHBy ZXZlbnRzIHlvdSBmcm9tIHN1cHBvcnRpbmcgdGhpcyBwdXJwb3NlIHdpdGggSGlzdG9yeS1JbmZv Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIGFyZ3VtZW50IHRoYXQg YmVjYXVzZSBBIGlzIHN1cHBvcnRlZCBieSBCLCB0aGVyZWZvcmUgQyBpcyBub3Qgc3VwcG9ydGVk IGJ5IEIsIGlzIGlsbG9naWNhbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjBwdDti YWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCBOYXJyb3cmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojQTgxNDAwIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48L2I+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMu MHB0O2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsIE5hcnJvdyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiNBODE0MDAiPk1pY2hhZWwgSGFtbWVyPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4wcHQ7YmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwgTmFycm93JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxh IGhyZWY9Im1haWx0bzptaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tIj5taWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsIE5hcnJvdyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mIzQz OzE8Yj4mbmJzcDs8L2I+NDA4IDIwMiA5MjkxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtjb2xvcjpibGFjayI+ PGJyPg0KwqkgMjAxNiBZYWFuYSBUZWNobm9sb2dpZXMsIExMQy4gQWxsIFJpZ2h0cyBSZXNlcnZl ZC4gRW1haWwgY29uZmlkZW50aWFsaXR5IG5vdGljZS4gVGhpcyBtZXNzYWdlIGlzIHByaXZhdGUg YW5kIGNvbmZpZGVudGlhbC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHVzIGFuZCByZW1vdmUgaXQgZnJvbSB5b3VyIHN5c3RlbS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+RnJvbTo8L2I+IGRpc3BhdGNoIFs8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2gtYm91 bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5OIFdFSU5ST05LPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg TWFyY2ggMDksIDIwMTYgNjowNSBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmtl aXRoLmRyYWdlQG5va2lhLmNvbSI+a2VpdGguZHJhZ2VAbm9raWEuY29tPC9hPjsgPGEgaHJlZj0i bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnIj4NCmRpc3BhdGNoQGlldGYub3JnPC9hPjxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW2Rpc3BhdGNoXSBkcmFmdC13ZWlucm9uay1kaXNwYXRjaC1sYXN0 LWRpdmVydGluZy1saW5lLWlkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo4LjBwdDttYXJnaW4tbGVmdDowY20iPg0KJm5i c3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206OC4wcHQ7bWFyZ2luLWxlZnQ6MGNtIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPlRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cyBvbiB0aGlzIEludGVybmV0IERyYWZ0 IOKAkyBJIHdpbGwgdHJ5IGFuZCBhbnN3ZXIgeW91ciBwb2ludHMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tR0IiPkRvIHlvdSBiZWxpZXZlIGl0IGlzIGxlZ2FjeSBmcm9tIHRoZSBlYXJseSBJU0ROIGRl ZmluaXRpb25zIG9yIGRvIHlvdSBiZWxpZXZlIGl0IGlzIG5ldz8NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207 bWFyZ2luLWJvdHRvbTo4LjBwdDttYXJnaW4tbGVmdDowY20iPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TmVpdGhl ciBpdCBhIGNvbnNlcXVlbmNlIG9mIHRoZSB3YXkgRVRTSSBJU0ROIHdhcyBpbXBsZW1lbnRlZCBp biB0aGUgVUsgaW4gdGhlIDE5OTBzIHRoYXQgaXMgc3RpbGwgaW4mbmJzcDt1c2UgdG9kYXkg4oCT IHNlZSBiZWxvdy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206OC4wcHQ7bWFyZ2luLWxl ZnQ6MGNtIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPk5vdGU6IEkgYXNzdW1lIGJ5IGVhcmx5IElTRE4gZGVmaW5p dGlvbnMgeW91IG1lYW4gd2hlcmUgRVRTSSBJU0ROIHdhcyBtYXBwZWQgdG8gREFTUyBhbmQgSSBh bSBub3QgdGFsa2luZyBhYm91dCB0aGlzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5DYW4geW91 IGV4cGxhaW4gd2hlcmUgYSBwcm9wb3NlZCBVSyByZXF1aXJlbWVudCBjb21lcyBmcm9tIHRoYXQg aXMgbm90IGNvbnRhaW5lZCB3aXRoaW4gdGhlIEVUU0kgYW5kIElUVS1UIHNlcnZpY2UgZGVmaW5p dGlvbnMgZm9yIHRoZSBJU0ROPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjguMHB0 O21hcmdpbi1sZWZ0OjBjbSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGlzIGNvbWVzIGZyb20gY3VycmVudCBp bXBsZW1lbnRhdGlvbnMgaW4gdGhlIFVLIGJhc2VkIG9uIE5JQ0MgTkQxMDA3Ljwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbTo4LjBwdDttYXJnaW4tbGVmdDowY20iPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ SW4gVUsgSVNVUCB0aGVyZSBpcyBhIHBhcmFtZXRlciBvcHRpb25hbCBpbiB0aGUgSUFNIOKAkyBM YXN0IERpdmVydGVkIExpbmUgSWRlbnRpdHkgaW4gYWRkaXRpb25hbCB0byB0aGUgSVRVL0VUU0kg cGFyYW1ldGVyIFJlZGlyZWN0aW5nIE51bWJlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206OC4wcHQ7bWFyZ2luLWxlZnQ6MGNtIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZXJlIGFyZSB0aW1lcyB3 aGVuIHRoZXNlIHBhcmFtZXRlcnMgYXJlIGJvdGggcHJlc2VudCBhbmQgY2FuIGhvbGQgZGlmZmVy ZW50IGluZm9ybWF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo4LjBwdDttYXJn aW4tbGVmdDowY20iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+WW91IGNvdWxkIHNlZSB0aGlzIGFzIGJlaW5nIGFu YWxvZ291cyB0byBGUk9NIGFuZCBQLUFzc2VydGVkLUlkIGhlYWRlcnMgaW4gU0lQIHdpdGggdGhl IExhc3QgRGl2ZXJ0ZWQgTGluZSBJZGVudGl0eSBwYXJhbWV0ZXIgYmVpbmcgdGhlIOKAmG5ldHdv cmsgYXNzZXJ0ZWQgaWRlbnRpdHnigJkgdXNlZCBieSBuZXR3b3JrcyBvdGhlciB0aGF0IHRoZSBu ZXR3b3JrIGRpdmVydGluZw0KIHRoZSBjYWxsIHRvIHZlcmlmeSBzZXJ2aWNlIGFuZCB0aGUgUmVk aXJlY3RpbmcgTnVtYmVyIHBhcmFtZXRlciBiZWluZyB0aGUg4oCYcHJlc2VudGF0aW9uIG51bWJl cuKAmS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206OC4wcHQ7bWFyZ2luLWxlZnQ6MGNt Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlRoZSBjYXNlcyBJIGFtIGF3YXJlIG9mIHdoZXJlIHRoZXNlIHBhcmFt ZXRlcnMgY2FuIGhvbGQgZGlmZmVyZW50IGluZm9ybWF0aW9uIGNvbWUgZnJvbSBFVFNJIElTRE4g ZGl2ZXJzaW9uIHNjZW5hcmlvcyDigJMgQ2FsbCBGb3J3YXJkaW5nIFVuY29uZGl0aW9uYWwgLyBD YWxsIEZvcndhcmRpbmcgQnVzeSAvIENhbGwgRm9yd2FyZGluZyBObyBSZXBseSAvIENhbGwgRGVm bGVjdGlvbg0KIC8gUGFydGlhbCBSZXJvdXRpbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjguMHB0O21hcmdpbi1sZWZ0OjBjbSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgUGFydGlhbCBSZXJv dXRpbmcgdGhlIExhc3QgRGl2ZXJ0ZWQgTGluZSBJZGVudGl0eSBwYXJhbWV0ZXIgaXMgYmFzZWQg b24gdGhlIOKAmGFkbWluaXN0cmF0aW9uIG51bWJlcuKAmSBhcyB1bmRlcnN0b29kIGJ5IHRoZSBu ZXR3b3JrIGRvaW5nIHRoZSBkaXZlcnNpb24gYW5kIHRoZSBuZXR3b3JrIGRvaW5nIHRoZSB2ZXJp ZmljYXRpb24gYW5kIGJpbGxpbmcgZm9yDQogdGhlc2UgY2FsbHMuIFRoZSBSZWRpcmVjdGluZyBO dW1iZXIgcGFyYW1ldGVyIGlzIHNldCBmcm9tIHRoZSBsYXN0UmVyb3V0aW5nTnIgZnJvbSB0aGUg QVNOLjEgdGhlIHByaXZhdGUgbmV0d29yayBzZXRzIGluIHRoZSBRLjkzMSBTRVRVUCBtZXNzYWdl IOKAkyB0aGVzZSBjYW4vd2lsbCBiZSBkaWZmZXJlbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjguMHB0O21hcmdpbi1sZWZ0OjBjbSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgQ2FsbCBGb3J3 YXJkaW5nIFVuY29uZGl0aW9uYWwgLyBDYWxsIEZvcndhcmRpbmcgQnVzeSAvIENhbGwgRm9yd2Fy ZGluZyBObyBSZXBseSAvIENhbGwgRGVmbGVjdGlvbiB0aGUgTGFzdCBEaXZlcnRlZCBMaW5lIElk ZW50aXR5IHBhcmFtZXRlciBpcyBiYXNlZCBvbiB0aGUg4oCYYWRtaW5pc3RyYXRpb24gbnVtYmVy 4oCZIGFzIHVuZGVyc3Rvb2QgYnkgdGhlIG5ldHdvcmsNCiBkb2luZyB0aGUgZGl2ZXJzaW9uIGFu ZCB0aGUgbmV0d29yayBkb2luZyB0aGUgdmVyaWZpY2F0aW9uIGFuZCBiaWxsaW5nIGZvciB0aGVz ZSBjYWxscy4gVGhlIFJlZGlyZWN0aW5nIE51bWJlciBwYXJhbWV0ZXIgaXMgc2V0IHRvIHRoZSBD YWxsZWQgUGFydHkgTnVtYmVyIHVzZWQgdG8gcmVhY2ggdGhlIGRpdmVydGluZyBwYXJ0eSDigJMg dGhlc2UgYXJlIG5vdCBuZWNlc3NhcmlseSB0aGUgc2FtZS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H QiI+SeKAmWQgYWxzbyBub3RlIHRoYXQgSSBiZWxpZXZlIGlmIHRoaXMgaXMgcmVxdWlyZWQgdGhl biBhbiBhZGRpdGlvbiB0byB0aGUgSGlzdG9yeS1JbmZvIGhlYWRlciBmaWVsZCB3b3VsZCBiZSBt b3JlIGFwcHJvcHJpYXRlLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjguMHB0O21h cmdpbi1sZWZ0OjBjbSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XZSAobXlzZWxmIGFuZCB0aGUgVUsgTklDQyBT SVAgVGFzayBHcm91cCkgZGlkIGNvbnNpZGVyIHVzaW5nIHRoZSBIaXN0b3J5LUluZm8gaGVhZGVy IGZvciB0aGlzIGJ1dCBhcyB0aGUgbWFwcGluZ3MgYXJlIGFscmVhZHkgZGVmaW5lZCBmcm9tIFJl ZGlyZWN0aW5nIE51bWJlciBwYXJhbWV0ZXIgdG8gSGlzdG9yeS1JbmZvIGJ5IHRoZSBJRVRGIC8g RVRTSSAvIElUVQ0KIGl0IHdhcyBmZWx0IHRoaXMgd291bGQgYmUgY29uZnVzaW5nIGFuZCBtYWtl IHRoZSBtYXBwaW5ncyBjb21wbGljYXRlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 OC4wcHQ7bWFyZ2luLWxlZnQ6MGNtIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFsc28gSSB3b3VsZCBleHBlY3Qg dGhpcyBoZWFkZXIgdG8gKGxpa2UgdGhlIExhc3QgRGl2ZXJ0ZWQgTGluZSBJZGVudGl0eSBwYXJh bWV0ZXIgaW4gVUsgSVNVUCkgYmUgbGltaXRlZCBpbiB3aGVyZSBpdCBjYW4gYmUgc2VudCBpZS4g YmV0d2VlbiBuZXR3b3JrIG9wZXJhdG9ycyBhbmQgbm90IHRvIGVuZCB1c2VycyBhZ2FpbiBtYWtp bmcgdXNlIG9mIEhpc3RvcnktSW5mbw0KIG1vcmUgY29tcGxpY2F0ZWQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBj bTttYXJnaW4tYm90dG9tOjguMHB0O21hcmdpbi1sZWZ0OjBjbSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5OaWdl bCBXZWlucm9uazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo4LjBwdDttYXJnaW4tbGVm dDowY20iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MTEuMjVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPi0tLS1PcmlnaW5hbCBtZXNzYWdlLS0tLTxicj4NCkZyb20gOiA8YSBocmVmPSJtYWls dG86a2VpdGguZHJhZ2VAbm9raWEuY29tIj5rZWl0aC5kcmFnZUBub2tpYS5jb208L2E+PGJyPg0K RGF0ZSA6IDA5LzAzLzIwMTYgLSAwMjo0NyAoR01UU1QpPGJyPg0KVG8gOiA8YSBocmVmPSJtYWls dG86UGhpbC5IdXRjaGlzb25AdmlyZ2lubWVkaWEuY28udWsiPlBoaWwuSHV0Y2hpc29uQHZpcmdp bm1lZGlhLmNvLnVrPC9hPiwNCjxhIGhyZWY9Im1haWx0bzpkaXNwYXRjaEBpZXRmLm9yZyI+ZGlz cGF0Y2hAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdCA6IFJlOiBbZGlzcGF0Y2hdIGRyYWZ0LXdl aW5yb25rLWRpc3BhdGNoLWxhc3QtZGl2ZXJ0aW5nLWxpbmUtaWQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DYW4geW91IGV4 cGxhaW4gd2hlcmUgYSBwcm9wb3NlZCBVSyByZXF1aXJlbWVudCBjb21lcyBmcm9tIHRoYXQgaXMg bm90IGNvbnRhaW5lZCB3aXRoaW4gdGhlIEVUU0kgYW5kIElUVS1UIHNlcnZpY2UgZGVmaW5pdGlv bnMgZm9yIHRoZSBJU0ROPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RG8g eW91IGJlbGlldmUgaXQgaXMgbGVnYWN5IGZyb20gdGhlIGVhcmx5IElTRE4gZGVmaW5pdGlvbnMg b3IgZG8geW91IGJlbGlldmUgaXQgaXMgbmV3Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+SeKAmWQgYWxzbyBub3RlIHRoYXQgSSBiZWxpZXZlIGlmIHRoaXMgaXMgcmVxdWly ZWQgdGhlbiBhbiBhZGRpdGlvbiB0byB0aGUgSGlzdG9yeS1JbmZvIGhlYWRlciBmaWVsZCB3b3Vs ZCBiZSBtb3JlIGFwcHJvcHJpYXRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+UmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+S2VpdGggRHJh Z2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtO2JvcmRlci1jb2xvcjpjdXJyZW50Q29sb3I7Ym9yZGVy LWltYWdlOiBub25lIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBk aXNwYXRjaCBbPGEgaHJlZj0ibWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0 bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RVhU IEh1dGNoaXNvbiwgUGhpbDxicj4NCjxiPlNlbnQ6PC9iPiAwNCBNYXJjaCAyMDE2IDA4OjIwPGJy Pg0KPGI+VG86PC9iPiAnZGlzcGF0Y2hAaWV0Zi5vcmcnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtk aXNwYXRjaF0gZHJhZnQtd2VpbnJvbmstZGlzcGF0Y2gtbGFzdC1kaXZlcnRpbmctbGluZS1pZDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojMUY0OTdEIj5IaSw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPkkgYmVsaWV2ZSB0aGF0IHRoaXMgaXMg cmVxdWlyZWQgaW4gdGhlIFVLLCBhbmQgdGhlcmVmb3JlIHdvdWxkIGxpa2UgdG8gc2VlIHRoZSBk cmFmdCBhY2NlcHRlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPlJl Z2FyZHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij5QaGlsPC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+DQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPn5+fn5+fn5+fn5+fn5+ fn5+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpu YXZ5Ij5QaGlsIEh1dGNoaXNvbjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6bmF2eSI+TGliZXJ0eSBHbG9iYWwgQ0FPPC9zcGFuPjwvYj48Yj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0K IC0gPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpuYXZ5Ij5Db21tdW5pY2F0aW9ucyBBcmNoaXRlY3R1cmU8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+DQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPk1vYmlsZSAmIzQzOzQ0Nzc3NSA5 Mzg4MjcgfCBTb2Z0IENsaWVudCAmIzQzOzQ0KDApMzcwMyA5MDA0NjQgfCBFbWFpbDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pg0KPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHV0Y2hpc29uQHZpcmdpbm1lZGlhLmNvLnVrIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+cGhpbC5odXRjaGlzb25AdmlyZ2lubWVkaWEuY28udWs8L3NwYW4+PC9hPg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij5NZWV0IE1lIENvbmZlcmVuY2U6PC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6bmF2eSI+MDgwOCAxMDc0NDQ0Jm5ic3A7IFsmIzQzOzQ0IDE3MjMyMDQ0NDRdPC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2 eSI+UElOIDEyNTY0NTAjPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij5W aXNpdDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPg0KPGEgaHJlZj0iaHR0cDovL3d3dy52aXJnaW5tZWRpYS5jby51ay8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij53d3cudmlyZ2lubWVkaWEuY28udWs8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij4gZm9yIG1vcmUgaW5mb3Jt YXRpb24sIGFuZCBtb3JlIGZ1bjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6bmF2eSI+U2F2ZSBwYXBlciAtIGRvIHlvdSByZWFsbHkgbmVlZCB0byBwcmludCB0aGlz IGVtYWlsPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1HQiI+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpTYXZlIFBhcGVyIC0gRG8geW91IHJlYWxs eSBuZWVkIHRvIHByaW50IHRoaXMgZS1tYWlsPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIGxhbmc9IkVOLUdCIj5WaXNpdCA8YSBocmVmPSJodHRwOi8vd3d3LnZpcmdpbm1lZGlhLmNv bSI+d3d3LnZpcmdpbm1lZGlhLmNvbTwvYT4gZm9yIG1vcmUgaW5mb3JtYXRpb24sIGFuZCBtb3Jl IGZ1bi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+VGhpcyBl bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBvciBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBs ZWdhbGx5IHByaXZpbGVnZWQ8YnI+DQphbmQgYXJlIHNlbnQgc29sZWx5IGZvciB0aGUgYXR0ZW50 aW9uIG9mIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXM8YnI+DQpl bWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtOiBpdHMgdXNl LCBkaXNjbG9zdXJlIG9yIGNvcHlpbmcgaXM8YnI+DQp1bmF1dGhvcmlzZWQuIFN0YXRlbWVudHMg YW5kIG9waW5pb25zIGV4cHJlc3NlZCBpbiB0aGlzIGVtYWlsIG1heSBub3QgcmVwcmVzZW50PGJy Pg0KdGhvc2Ugb2YgVmlyZ2luIE1lZGlhLiBBbnkgcmVwcmVzZW50YXRpb25zIG9yIGNvbW1pdG1l bnRzIGluIHRoaXMgZW1haWwgYXJlPGJyPg0Kc3ViamVjdCB0byBjb250cmFjdC4gPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPlJlZ2lzdGVyZWQgb2ZmaWNlOiBN ZWRpYSBIb3VzZSwgQmFydGxleSBXb29kIEJ1c2luZXNzIFBhcmssIEhvb2ssIEhhbXBzaGlyZSwg UkcyNyA5VVA8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzIHdpdGggbnVtYmVy IDI1OTEyMzc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRt bD4NCg== --_000_8B970F90C584EA4E97D5BAAC9172DBB8158472E0OPEXCLILMA4corp_-- From nobody Wed Mar 9 16:05:42 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030FF12DBEB for ; Wed, 9 Mar 2016 16:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ozyQrPpif0fv for ; Wed, 9 Mar 2016 16:05:33 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A0D012DBB4 for ; Wed, 9 Mar 2016 16:05:33 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Wed, 9 Mar 2016 16:05:32 -0800 From: Michael Hammer To: "marianne.mohali@orange.com" , "nweinronk@btinternet.com" , "keith.drage@nokia.com" , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Thread-Index: AQHRelTNKo5ngHlnyk6auwQNTLk13J9RyD3A Date: Thu, 10 Mar 2016 00:05:32 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BC187D83@sc9-ex2k10mb1.corp.yaanatech.com> References: <21219125.78797.1457561267637.JavaMail.defaultUser@defaultHost> <29641_1457563276_56E0A68C_29641_2783_1_8B970F90C584EA4E97D5BAAC9172DBB8158472E0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <29641_1457563276_56E0A68C_29641_2783_1_8B970F90C584EA4E97D5BAAC9172DBB8158472E0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.77] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00CD_01D17A36.A64530B0" MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 00:05:38 -0000 ------=_NextPart_000_00CD_01D17A36.A64530B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00CE_01D17A36.A64530B0" ------=_NextPart_001_00CE_01D17A36.A64530B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Nigel, =20 You are treading on a variety of current SIP headers for: - Tracking redirections - Presentation of the source of the call - Billing for the call. =20 Could you address the 3GPP P-header for billing indication? =20 I mention STIR because there are issues around how to properly attribute = the source of a call. Which is precisely what you are attempting to do. That affects not only billing but fighting robo-calls which are a = concern even in the UK. =20 Having suffered through the mapping issues in IETF and in ITU-T SG11 = some years ago,=20 I would caution you to proceed carefully, as every new header adds a new = complicating factor. =20 And if you are just doing purely transit operations between SS7 systems, = I could even suggest you look into Q.1980.1. :) =20 I raised a red flag here only because this seemed like d=C3=A9j=C3=A0 vu = all over again. And am looking for more thorough investigation. I will have to refresh my memory to provide more complete response to = your requirements. But, in the meantime explicitly detailing all those requirements will = help with this process.. =20 ________________________________ Michael Hammer michael.hammer@yaanatech.com =20 +1 408 202 9291 =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email = confidentiality notice. This message is private and confidential. If you = have received this message in error, please notify us and remove it from = your system. =20 From: marianne.mohali@orange.com [mailto:marianne.mohali@orange.com]=20 Sent: Wednesday, March 09, 2016 5:41 PM To: nweinronk@btinternet.com; Michael Hammer = ; keith.drage@nokia.com; dispatch@ietf.org Subject: RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 Dear Nigel, =20 After a reading of the draft, I have the following comments : - First, I wonder about having a standard, even informational, = to solve a country-specific need to convey an ISUP National = parameter=E2=80=A6hum - Second, I do think we can find a solution to solve your issue = by using the History-Info header. I don=E2=80=99t know yet how. :) =20 IIUC, you need to convey the asserted identity of the diverting user = into the forwarded leg even when he has been called to his declarative = identity. I see several mechanisms in History-Info header that could be used for = this purpose: - first you should know that it can be added additional entries = in the History-Info header even when the Request URI does not change. In = this case, the index should be increased (1->2) and not extended (1 -> = 1.1) as when forking is executed - to be able to distinguish this identity from the normal = diverting identity, you could use the "rc" hi-target-param to refer to = the normal History-Info entry for the diversion and link both. With this = mechanism, at the interworking you could find the last diverting = identity as described in 29.163 and then search for the entry having a = "rc" parameter having a value equals to the current (last diverting = address) hi-entry index value.=20 - finally, you could imagine a dedicated cause URI parameter = (different from those defined in RFC4458 for call diversion service) =20 =20 Best regards, Marianne =20 De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de N = WEINRONK Envoy=C3=A9 : mercredi 9 mars 2016 23:08 =C3=80 : michael.hammer@yaanatech.com = ; keith.drage@nokia.com = ; dispatch@ietf.org = =20 Objet : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 =20 Not sure I agree with the non-sequitur statement but lets move on. Let us explore the statement that History-Info "should" work a little = more: =20 Can you explain how 1 entry can have a 'presentation' and a 'network = asserted' identity that can be different - were you thinking of the = hi-extension ? Just to add to this in the UK (I can only really comment on this) the = specification of ETSI ISDN diversion services mandates that both the = 'network asserted' and the 'presentation' identities of the Diverting = Party are passed between operator networks on Diverted calls. This allows 'transit' operators handling Carrier Pre-select Diverted = calls to verify and bill the user.=20 All the documents I have seen be it 3GPP/IETF maps History-Info into = Redirecting Number - Redirecting Number does not have a screening = indicator and is used directly for display in ETSI ISDN.=20 In cases where the 'network asserted' identify is different from the = 'presentation' identity it is not clear to me how the information in the = History-Info header can be 'network asserted'. =20 I do not think it is 'this diversion' that is different it is the = ability to consistently pass 'network asserted' and 'presentation' = identities for Diversion information.=20 =20 Not sure how STIR is related ?=20 =20 Thanks, Nigel =20 =20 =20 ----Original message---- >From : michael.hammer@yaanatech.com = =20 Date : 09/03/2016 - 20:13 (GMTST) To : nweinronk@btinternet.com , = keith.drage@nokia.com , dispatch@ietf.org = =20 Subject : RE: RE: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id Nigel, =20 Your logic was a non-sequitor. Like saying cats like milk, therefore don=E2=80=99t give chocolate to a = dog. =20 The conclusion has nothing to do with cats and milk. =20 So, while such logic is not conclusive for or against a separate header, = the burden of proof for a separate header should lie on the one = proposing a new header,=20 when face with the existing of a header that =E2=80=9Cshould=E2=80=9D = work. (the question at hand) =20 A separate header is warranted when an existing header has the wrong = semantics=20 and the existing syntax just won=E2=80=99t work. However, that = doesn=E2=80=99t seem to be the case. =20 If another implementation judges that the H-I header is a perfect fit, = then you won=E2=80=99t be looking there. Some existing implementations just might be doing this already. So, just want to be careful about willy nilly adding new headers. =20 I would note that both the Route header and the H-I header can be = =E2=80=9Cnetwork asserted=E2=80=9D. So, what makes this particular diversion different from H-I envisaged? =20 You make it sound like it should be part of the STIR discussion, when = you compare to P-Asserted-ID. Have you looked into that WG? =20 ________________________________ Michael Hammer michael.hammer@yaanatech.com =20 +1 408 202 9291 =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email = confidentiality notice. This message is private and confidential. If you = have received this message in error, please notify us and remove it from = your system. =20 From: N WEINRONK [mailto:nweinronk@btinternet.com]=20 Sent: Wednesday, March 09, 2016 2:00 PM To: Michael Hammer >; keith.drage@nokia.com = ; dispatch@ietf.org = =20 Subject: Re: RE: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id =20 =20 Thanks for your time. =20 Please explain the negative consequences of a separate header ? =20 The only place I saw that this could have been placed in History-Info = was as an hi-extension because it is really a 'network asserted id' of = the hi-targeted-to-uri and this would place requirements on lots of = functions to search History-Info entries to remove this 'network = asserted' identity when required.=20 To me this is the same as From / P-Asserted-Identity - the = P-Asserted_Identity was not place in the From header as a parameter - I = guess it could have been. I think the same argument applies here in keeping the 'network asserted = identity' and the 'presentation identity' for the same user apart in the = signalling. Note: This also matches the ISUP implementation - a separate distinct = parameter. I see nothing illogical in a separate header. Thanks, Nigel =20 ----Original message---- >From : michael.hammer@yaanatech.com = =20 Date : 09/03/2016 - 17:20 (GMTST) To : nweinronk@btinternet.com , = keith.drage@nokia.com , dispatch@ietf.org = =20 Subject : RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id There is a danger here that this purpose could be supported by two = different headers=20 (a new header or an old header) with potential negative consequences. =20 Please show what prevents you from supporting this purpose with = History-Info? =20 The argument that because A is supported by B, therefore C is not = supported by B, is illogical. =20 ________________________________ Michael Hammer michael.hammer@yaanatech.com =20 +1 408 202 9291 =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email = confidentiality notice. This message is private and confidential. If you = have received this message in error, please notify us and remove it from = your system. =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of N = WEINRONK Sent: Wednesday, March 09, 2016 6:05 AM To: keith.drage@nokia.com ; = dispatch@ietf.org =20 Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 =20 Thank you for your comments on this Internet Draft =E2=80=93 I will try = and answer your points. Do you believe it is legacy from the early ISDN definitions or do you = believe it is new?=20 Neither it a consequence of the way ETSI ISDN was implemented in the UK = in the 1990s that is still in use today =E2=80=93 see below. Note: I assume by early ISDN definitions you mean where ETSI ISDN was = mapped to DASS and I am not talking about this. Can you explain where a proposed UK requirement comes from that is not = contained within the ETSI and ITU-T service definitions for the ISDN?=20 This comes from current implementations in the UK based on NICC ND1007. In UK ISUP there is a parameter optional in the IAM =E2=80=93 Last = Diverted Line Identity in additional to the ITU/ETSI parameter = Redirecting Number. There are times when these parameters are both present and can hold = different information. You could see this as being analogous to FROM and P-Asserted-Id headers = in SIP with the Last Diverted Line Identity parameter being the = =E2=80=98network asserted identity=E2=80=99 used by networks other that = the network diverting the call to verify service and the Redirecting = Number parameter being the =E2=80=98presentation number=E2=80=99. The cases I am aware of where these parameters can hold different = information come from ETSI ISDN diversion scenarios =E2=80=93 Call = Forwarding Unconditional / Call Forwarding Busy / Call Forwarding No = Reply / Call Deflection / Partial Rerouting. For Partial Rerouting the Last Diverted Line Identity parameter is based = on the =E2=80=98administration number=E2=80=99 as understood by the = network doing the diversion and the network doing the verification and = billing for these calls. The Redirecting Number parameter is set from = the lastReroutingNr from the ASN.1 the private network sets in the Q.931 = SETUP message =E2=80=93 these can/will be different. For Call Forwarding Unconditional / Call Forwarding Busy / Call = Forwarding No Reply / Call Deflection the Last Diverted Line Identity = parameter is based on the =E2=80=98administration number=E2=80=99 as = understood by the network doing the diversion and the network doing the = verification and billing for these calls. The Redirecting Number = parameter is set to the Called Party Number used to reach the diverting = party =E2=80=93 these are not necessarily the same. I=E2=80=99d also note that I believe if this is required then an = addition to the History-Info header field would be more appropriate.=20 We (myself and the UK NICC SIP Task Group) did consider using the = History-Info header for this but as the mappings are already defined = from Redirecting Number parameter to History-Info by the IETF / ETSI / = ITU it was felt this would be confusing and make the mappings = complicated. Also I would expect this header to (like the Last Diverted Line Identity = parameter in UK ISUP) be limited in where it can be sent ie. between = network operators and not to end users again making use of History-Info = more complicated. Nigel Weinronk =20 ----Original message---- >From : keith.drage@nokia.com =20 Date : 09/03/2016 - 02:47 (GMTST) To : Phil.Hutchison@virginmedia.co.uk = , dispatch@ietf.org = =20 Subject : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Can you explain where a proposed UK requirement comes from that is not = contained within the ETSI and ITU-T service definitions for the ISDN? =20 Do you believe it is legacy from the early ISDN definitions or do you = believe it is new? =20 I=E2=80=99d also note that I believe if this is required then an = addition to the History-Info header field would be more appropriate. =20 Regards =20 Keith Drage =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of EXT = Hutchison, Phil Sent: 04 March 2016 08:20 To: 'dispatch@ietf.org' Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 Hi, =20 I believe that this is required in the UK, and therefore would like to = see the draft accepted. =20 Regards =20 Phil=20 ~~~~~~~~~~~~~~~~~=20 Phil Hutchison=20 Liberty Global CAO - Communications Architecture=20 Mobile +447775 938827 | Soft Client +44(0)3703 900464 | Email = = phil.hutchison@virginmedia.co.uk=20 Meet Me Conference: 0808 1074444 [+44 1723204444] PIN 1256450# Visit www.virginmedia.co.uk for more = information, and more fun=20 Save paper - do you really need to print this email? =20 -------------------------------------------------------------------- Save Paper - Do you really need to print this e-mail? Visit www.virginmedia.com for more = information, and more fun. This email and any attachments are or may be confidential and legally = privileged and are sent solely for the attention of the addressee(s). If you have = received this email in error, please delete it from your system: its use, disclosure = or copying is unauthorised. Statements and opinions expressed in this email may not = represent those of Virgin Media. Any representations or commitments in this email = are subject to contract.=20 Registered office: Media House, Bartley Wood Business Park, Hook, = Hampshire, RG27 9UP Registered in England and Wales with number 2591237 =20 =20 =20 =20 =20 =20 _________________________________________________________________________= ________________________________________________ =20 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. =20 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. ------=_NextPart_001_00CE_01D17A36.A64530B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Nigel,

 

You are treading on a = variety of current SIP headers for:

-          = Tracking = redirections

-          = Presentation of the source of the = call

-          = Billing for = the call.

 

Could you address the = 3GPP P-header for billing indication?

 

I mention STIR because = there are issues around how to properly attribute the source of a = call.

Which is precisely what you are attempting to = do.

That affects not only billing but fighting = robo-calls which are a concern even in the UK.

 

Having suffered through = the mapping issues in IETF and in ITU-T SG11 some years ago, =

I would caution you to proceed carefully, as = every new header adds a new complicating factor.

 

And if you are just = doing purely transit operations between SS7 systems, =

I could even suggest you look into = Q.1980.1.=C2=A0 J

 

I raised a red flag here = only because this seemed like d=C3=A9j=C3=A0 vu all over = again.

And am looking for more thorough = investigation.

I will have to refresh my memory to provide more = complete response to your requirements.

But, in the meantime = explicitly detailing all those requirements will help with this = process..

 

________________________________=

Michael Hammer

michael.hammer@yaanatech.com=

+1 408 202 9291


=C2=A9 = 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality = notice. This message is private and confidential. If you have received = this message in error, please notify us and remove it from your = system.

 

From: marianne.mohali@orange.com = [mailto:marianne.mohali@orange.com]
Sent: Wednesday, March = 09, 2016 5:41 PM
To: nweinronk@btinternet.com; Michael Hammer = <michael.hammer@yaanatech.com>; keith.drage@nokia.com; = dispatch@ietf.org
Subject: RE: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id

=

 

Dear Nigel,

 

After a reading of the = draft, I have the following comments :

-          = First, I = wonder about having a standard, even informational, to solve a = country-specific need to convey an ISUP National = parameter=E2=80=A6hum

-          = Second, I = do think we can find a solution to solve your issue by using the = History-Info header. I don=E2=80=99t know yet how. J

 

IIUC, you need to convey = the asserted identity of the diverting user into the forwarded leg even = when he has been called to his declarative = identity.

I see several mechanisms in History-Info header = that could be used for this purpose:

-          = first you = should know that it can be added additional entries in the History-Info = header even when the Request URI does not change. In this case, the = index should be increased (1->2) and not extended (1 -> 1.1) as = when forking is executed

-          = to be able = to distinguish this identity from the normal diverting identity, you = could use the "rc" hi-target-param to refer to the normal = History-Info entry for the diversion and link both. With this mechanism, = at the interworking you could find the last diverting identity as = described in 29.163 and then search for the entry having a = "rc" parameter having a value equals to the current (last = diverting address) hi-entry index value.

-          = finally, = you could imagine a dedicated cause URI parameter (different from those = defined in RFC4458 for call diversion service)

 

 

Best = regards,

Marianne

 

De : = dispatch [mailto:dispatch-bounces@ietf.or= g] De la part de N WEINRONK
Envoy=C3=A9 : = mercredi 9 mars 2016 = 23:08
=C3=80 : michael.hammer@yaanatech.com= ; keith.drage@nokia.com; dispatch@ietf.org
Objet = : Re: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id

 

 

Not sure I = agree with the non-sequitur statement but lets move = on.

Let us explore the statement = that History-Info "should" work a little = more:

 

Can you explain = how 1 entry can have a 'presentation' and a 'network asserted' identity = that can be different - were you thinking of the hi-extension = ?

Just to add to this in the UK = (I can only really comment on this) the specification of ETSI ISDN = diversion services mandates that both the 'network asserted' = and the 'presentation' identities of the Diverting Party are passed = between operator networks on Diverted = calls.

This allows 'transit' = operators handling Carrier Pre-select Diverted calls to verify and bill = the user. 

All = the documents I have seen be it 3GPP/IETF maps History-Info into = Redirecting Number - Redirecting Number does not have a screening = indicator and is used directly for display in ETSI ISDN. =

In cases where the 'network = asserted' identify is different from the 'presentation' identity it = is not clear to me how the information in the History-Info header can be = 'network asserted'.

 

I do not think = it is 'this diversion' that is different it is the ability to = consistently pass 'network asserted' and 'presentation' = identities for Diversion = information. 

 

Not sure how = STIR is related ? 

 

Thanks,

Nigel

 

 

 

----Original message----
>From : michael.hammer@yaanatech.com=
Date : 09/03/2016 - 20:13 (GMTST)
To : nweinronk@btinternet.com, = keith.drage@nokia.com, dispatch@ietf.org
Subject : RE: = RE: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id

Nigel,

 

Your logic was a non-sequitor.

Like saying cats like milk, therefore = don=E2=80=99t give chocolate to a dog. 

The conclusion has nothing to do with cats and = milk.

 

So, while such logic is not conclusive for or = against a separate header,

the burden of proof for a separate header should = lie on the one proposing a new header,

when face with the existing of a header that = =E2=80=9Cshould=E2=80=9D work.  (the question at hand)

 

A separate header is warranted when an existing = header has the wrong semantics

and the existing syntax just won=E2=80=99t work. =  However, that doesn=E2=80=99t seem to be the case.

 

If another implementation judges that the H-I = header is a perfect fit, then you won=E2=80=99t be looking = there.

Some existing = implementations just might be doing this already.

So, just want to be careful about willy nilly = adding new headers.

 

I would note that both the Route header and the = H-I header can be =E2=80=9Cnetwork asserted=E2=80=9D.

So, what makes this particular diversion = different from H-I envisaged?

 

You make it sound like it should be part of the = STIR discussion, when you compare to P-Asserted-ID.

Have you looked into that WG?

 

________________________________=

Michael Hammer

michael.hammer@yaanatech.com=

+1 408 202 9291


=C2=A9 2016 Yaana = Technologies, LLC. All Rights Reserved. Email confidentiality notice. = This message is private and confidential. If you have received this = message in error, please notify us and remove it from your = system.

 

From: N WEINRONK [mailto:nweinronk@btinternet.com<= /a>]
Sent: Wednesday, March 09, 2016 2:00 PM
To: = Michael Hammer <michael.hammer@yaanatech.com= >; keith.drage@nokia.com; dispatch@ietf.org
Subject: Re: RE: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id

 

 

Thanks for your = time.

 

Please explain = the negative consequences of a separate header = ?

 

The only place = I saw that this could have been placed in History-Info was as an = hi-extension because it is really a 'network asserted id' of the = hi-targeted-to-uri and this would place requirements on lots of = functions to search History-Info entries to remove this 'network = asserted' identity when required. 

To me this is the same as From / P-Asserted-Identity - the = P-Asserted_Identity was not place in the From header as a parameter - I = guess it could have been.

I = think the same argument applies here in keeping the 'network asserted = identity' and the 'presentation identity' for the same user apart in the = signalling.

Note: This also = matches the ISUP implementation - a separate distinct = parameter.

I see nothing = illogical in a separate header.

Thanks,

Nigel

 

----Original message----
From : michael.hammer@yaanatech.com=
Date : 09/03/2016 - 17:20 (GMTST)
To : nweinronk@btinternet.com, = keith.drage@nokia.com, dispatch@ietf.org
Subject : RE: = [dispatch] = draft-weinronk-dispatch-last-diverting-line-id

There is a = danger here that this purpose could be supported by two different = headers

(a new header = or an old header) with potential negative consequences.

 

Please show what prevents you from supporting = this purpose with History-Info?

 

The argument that because A is supported by B, = therefore C is not supported by B, is illogical.

 

________________________________=

Michael Hammer

michael.hammer@yaanatech.com=

+1 408 202 9291


=C2=A9 2016 Yaana = Technologies, LLC. All Rights Reserved. Email confidentiality notice. = This message is private and confidential. If you have received this = message in error, please notify us and remove it from your = system.

 

From: dispatch [mailto:dispatch-bounces@ietf.or= g] On Behalf Of N WEINRONK
Sent: Wednesday, March = 09, 2016 6:05 AM
To: keith.drage@nokia.com; dispatch@ietf.org
Subject: Re: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id

 

 

Thank you for your comments = on this Internet Draft =E2=80=93 I will try and answer your = points.

Do you believe it is = legacy from the early ISDN definitions or do you believe it is new? =

Neither it a consequence of = the way ETSI ISDN was implemented in the UK in the 1990s that is still = in use today =E2=80=93 see below.

Note: I assume by early ISDN = definitions you mean where ETSI ISDN was mapped to DASS and I am not = talking about this.

Can you = explain where a proposed UK requirement comes from that is not contained = within the ETSI and ITU-T service definitions for the ISDN?

This comes from current = implementations in the UK based on NICC ND1007.

In UK ISUP there is a = parameter optional in the IAM =E2=80=93 Last Diverted Line Identity in = additional to the ITU/ETSI parameter Redirecting Number.

There are times when these = parameters are both present and can hold different = information.

You could see this as being = analogous to FROM and P-Asserted-Id headers in SIP with the Last = Diverted Line Identity parameter being the =E2=80=98network asserted = identity=E2=80=99 used by networks other that the network diverting the = call to verify service and the Redirecting Number parameter being the = =E2=80=98presentation number=E2=80=99.

The cases I am aware of where = these parameters can hold different information come from ETSI ISDN = diversion scenarios =E2=80=93 Call Forwarding Unconditional / Call = Forwarding Busy / Call Forwarding No Reply / Call Deflection / Partial = Rerouting.

For Partial Rerouting the = Last Diverted Line Identity parameter is based on the = =E2=80=98administration number=E2=80=99 as understood by the network = doing the diversion and the network doing the verification and billing = for these calls. The Redirecting Number parameter is set from the = lastReroutingNr from the ASN.1 the private network sets in the Q.931 = SETUP message =E2=80=93 these can/will be different.

For Call Forwarding = Unconditional / Call Forwarding Busy / Call Forwarding No Reply / Call = Deflection the Last Diverted Line Identity parameter is based on the = =E2=80=98administration number=E2=80=99 as understood by the network = doing the diversion and the network doing the verification and billing = for these calls. The Redirecting Number parameter is set to the Called = Party Number used to reach the diverting party =E2=80=93 these are not = necessarily the same.

I=E2=80=99d also note = that I believe if this is required then an addition to the History-Info = header field would be more appropriate.

We (myself and the UK NICC = SIP Task Group) did consider using the History-Info header for this but = as the mappings are already defined from Redirecting Number parameter to = History-Info by the IETF / ETSI / ITU it was felt this would be = confusing and make the mappings complicated.

Also I would expect this = header to (like the Last Diverted Line Identity parameter in UK ISUP) be = limited in where it can be sent ie. between network operators and not to = end users again making use of History-Info more complicated.

Nigel Weinronk

 

----Original message----
From : keith.drage@nokia.com
Date = : 09/03/2016 - 02:47 (GMTST)
To : Phil.Hutchison@virginmed= ia.co.uk, dispatch@ietf.org
Subject : Re: = [dispatch] = draft-weinronk-dispatch-last-diverting-line-id

Can you = explain where a proposed UK requirement comes from that is not contained = within the ETSI and ITU-T service definitions for the ISDN?

 

Do you believe it is legacy from the early ISDN = definitions or do you believe it is new?

 

I=E2=80=99d also note that I believe if this is = required then an addition to the History-Info header field would be more = appropriate.

 

Regards

 

Keith Drage

 

From: dispatch [mailto:dispatch-bounces@ietf.or= g] On Behalf Of EXT Hutchison, Phil
Sent: 04 March = 2016 08:20
To: 'dispatch@ietf.org'
Subject: = [dispatch] draft-weinronk-dispatch-last-diverting-line-id

 

Hi,

 

I believe that this is required = in the UK, and therefore would like to see the draft = accepted.

 

Regards

 

Phil=

~~~~= ~~~~~~~~~~~~~

Phil= Hutchison

Libe= rty Global CAO - Comm= unications Architecture

Mobi= le +447775 938827 | Soft Client +44(0)3703 900464 | Email phil.hutchison@virginmedia.co.uk=

Meet= Me Conference: 0808= 1074444  [+44 1723204444] PIN = 1256450#

Visi= t www.virginmedia.co.uk= = for more information, and more fun

Save= paper - do you really need to print this email?

 


--------------------------------------------------------= ------------
Save Paper - Do you really need to print this = e-mail?

Visit www.virginmedia.com for more = information, and more fun.

This email and any = attachments are or may be confidential and legally privileged
and are = sent solely for the attention of the addressee(s). If you have received = this
email in error, please delete it from your system: its use, = disclosure or copying is
unauthorised. Statements and opinions = expressed in this email may not represent
those of Virgin Media. Any = representations or commitments in this email are
subject to contract. =

Registered office: Media House, Bartley Wood Business Park, = Hook, Hampshire, RG27 9UP
Registered in England and Wales with number = 2591237

 

 

 

 

 

 

_______________________________________________________________=
__________________________________________________________
 
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.
------=_NextPart_001_00CE_01D17A36.A64530B0-- ------=_NextPart_000_00CD_01D17A36.A64530B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8DCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBmAwggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJ KoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAw MDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFu dGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2Fm TDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNN RNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0aNomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZ BP+gfz+j25FFdmaja/OFI15O2YVddaegFffBAHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6kl QrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gz AgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJLTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9v YIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMp IDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcC ARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5z eW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEFBQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVn Mc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGiSNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlU zd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5sZ8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs 1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAq WDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7eDROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gu d1wnwTkwggdrMIIGU6ADAgECAhBMAzfzqk7mKu8vbItErxUIMA0GCSqGSIb3DQEBBQUAMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1l ZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDIyOTAwMDAwMFoXDTE4MDIyODIzNTk1 OVoweTEXMBUGA1UEAwwOTWljaGFlbCBIYW1tZXIxDzANBgNVBAsMBlMvTUlNRTEgMB4GA1UECgwX WWFhbmEgVGVjaG5vbG9naWVzLCBMTEMxKzApBgkqhkiG9w0BCQEWHG1pY2hhZWwuaGFtbWVyQHlh YW5hdGVjaC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWEk4s5ORfNfQ/oXDD k4mHDQDDpO3s2oEy7055JdLoleNQXEJGsv8EsqPagYul55uVZ57tmx2H1LjM6QfD7N821joisKa4 +l92JImsffrTnll8gxJ9VV9/WmGpPWwFg4ipw3qRdDhQJnQiNKzlqPMSIDE76uhrKv3hYE30tVIO R8U9erAprCBoHd2Ch1+pIGlFjl91//BR1sehnJR9Z1gZHMEqjto/jYPR1uEapueR6W+YuL9O9HmW RLA925xiZmzwKqB8HS0wG+PjLnMRnohdIh4e+/FKWksC82rP7vmP3SHOzQKdgdapaavCTx/1ZYiR N6cMT95ZCgB1aHXR1lCfAgMBAAGjggOcMIIDmDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF oDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFFaFSmgtcRDwfRFi qt3Vq8LJCLn5MCcGA1UdEQQgMB6BHG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20wHwYDVR0j BBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFxBggrBgEFBQcBAQSCAWMwggFfMCcGCCsGAQUF BzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5jb20wggEyBggrBgEFBQcwAoaCASRsZGFwOi8v ZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUzRCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIw U2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUz RCUyMENsYXNzJTIwMiUyME1hbmFnZWQlMjBQS0klMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUy MENBJTJDT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBT eW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5 MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0 NzdjZjRmNmJlOTZhZjFiMzZjYWJkMzE2L0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgB hvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEF BQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqG SIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUB EAMEHjAcBhJghkgBhvhFARABAgIBAYabp24WBjE4NzIwOTA5BgpghkgBhvhFARAFBCswKQIBABYk YUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQBX iSRv04vVx/Y5lWWITUJhWXUTnhM70UUqIEinNF+cV9+zY0lomYqoB8ovCfWrvx232tzX86NtreSn 9UjhBRj61oqSyK9v6P14dunX1MjRZmOVeKws3+XDS3NPsopui5YOPjSy02qhyVN4tIDCokj71db1 wO7uZ/DehNWkwFUgMKdVKM5LAGIDHgWn2dvzGi+ipdDNjMD2SxMnCSOiZ3z9gh/Yy+flNaXn5vLL O0AJEW5xCl2tbuPh/DghqlaiVeCLaCar3cj2Ka6ew5wRhNpvmno47b0C5w6JDxx++ijXjGPzYr57 J8QvCDs9f3Cn5doEF3bTQmcab+s3VEgIhAt1MYIE4zCCBN8CAQEwgd4wgckxCzAJBgNVBAYTAlVT MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkCEEwDN/OqTuYq7y9si0SvFQgwCQYFKw4DAhoFAKCCAtkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMzEwMDAwNTMwWjAjBgkqhkiG 9w0BCQQxFgQUUjstyfKmkv4IP25uXAS4BuSdvvMwgZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgB ZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglg hkgBZQMEAgEwge8GCSsGAQQBgjcQBDGB4TCB3jCByTELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UE AxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRlIEF1dGhv cml0eQIQTAM386pO5irvL2yLRK8VCDCB8QYLKoZIhvcNAQkQAgsxgeGggd4wgckxCzAJBgNVBAYT AlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1 c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEEwDN/OqTuYq7y9si0SvFQgwDQYJKoZIhvcNAQEBBQAEggEA Sa4QglQ8U7XnG6JW8x8+JiKzPdasPUBPClFHau3J/e2iAjtDySEF1TWVcvpEi8QwI18aDrjVvZG2 BpdS26/s1cBTZrxQ4CMZYORJ8JNide+LBAcF7B61LdJ/bvr9YpZOmvVaW36q1FDEZSq8luIc7eoL AMMMra6VjjFaa9rixN3YSpXLuIKTKLp/EB5DjD0F3b4HRhNWmkLlsJVMa6aFrQxVemd5ja7O13Dk c0rEFleC6PbLMT+RjDTm36pZuaPaEXbObub5BOJup/s2Apy5v1pSBoJvNHxGzgPC+bZ8o+qqJu2I OVznVaeBAOwZvMGyqpBloMwwiyTfqXyfFzVyEQAAAAAAAA== ------=_NextPart_000_00CD_01D17A36.A64530B0-- From nobody Wed Mar 9 17:30:01 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6358A12D6B0; Wed, 9 Mar 2016 17:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 jGvVWRFCYER5; Wed, 9 Mar 2016 17:29:57 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 481AF12D6AA; Wed, 9 Mar 2016 17:29:57 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E30D9509B8; Wed, 9 Mar 2016 20:29:55 -0500 (EST) To: Darrel Miller , media-types@ietf.org References: <56DE624C.6020700@seantek.com> <56E0C35B.9@seantek.com> From: Sean Leonard Message-ID: <56E0CDBA.3050301@seantek.com> Date: Wed, 9 Mar 2016 17:28:26 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dispatch@ietf.org, "apps-discuss@ietf.org" Subject: [dispatch] text/yaml Re: [media-types] OpenApi media type registration questions X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 01:29:59 -0000 [adding apps-discuss and dispatch] On 3/9/2016 5:20 PM, Darrel Miller wrote: > Sean, > >> -----Original Message----- >> From: media-types [mailto:media-types-bounces@ietf.org] On Behalf Of >> Sean Leonard >> RFC 6838 Section 6 >> https://tools.ietf.org/html/rfc6838#section-6 >> >> RFC 6839 has examples of the template actually instantiated in the tex= t. >> > Thanks. So this is where I find myself in a catch-22 situation. In ord= er to > register the +yaml suffix, it needs to there a reference to a specifica= tion > for YAML. However, there is no such specification that is managed by a= SDO. > I searched in the YAML Core mailing list and back in 2003 they discusse= d > their plan to use text/yaml as the media type. There has been no furth= er > discussion of registering a media type since then on the list. > > So it seems that, without a spec under an SDO, it would not be possible= to > register text/yaml or register the suffix. > > It seems that the only option available would be for someone to convinc= e the > YAML team to allow a variant of their spec (it has images in it) to be > created as an IETF spec. > > Does that reasoning appear sound? Not exactly. First of all, it's the same situation as Markdown (see the text/markdown = discussion over time on the apps-discuss mailing list). The most important hurdle has been passed: some people actually *want*=20 text/yaml. The second hurdle has also (likely) been passed: people are actually=20 using text/yaml for YAML stuff. This turns out to be more useful than=20 the registration itself. Deploy first, register later. ;-) The next hurdle is overcoming developer laziness, since it requires some = modicum of effort to do the registration. Sounds like we have a willing=20 victim...er...volunteer. ;-) Getting text/yaml just requires an Informational independent-stream or=20 IETF stream RFC. First write an Internet-Draft. The Internet-Draft can=20 reference the yaml.org specification, without changing control over the=20 specification to the IETF. Then submit the draft to the dispatch mailing = list. (Maybe also a couple of other mailing lists, for places in IETF=20 that use YAML.) Depending on the outcome of the discussion, either the IETF will take it = up, or not. If they do, then the media type registration will be=20 published with IETF Consensus (see text/markdown). If not, then it can=20 still be published an the independent stream by submitting it to the=20 Independent Submissions Editor (see image/bmp, aka=20 draft-seantek-windows-image)=20 . I have not tried to register a structured syntax suffix before.=20 Superficially, the process appears to be simpler, as it only needs=20 Expert Review. For that, just follow what RFC 6838 Section 6 says. Best of luck! Sean From nobody Thu Mar 10 01:19:32 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFDD12D614 for ; Thu, 10 Mar 2016 01:19:31 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ebA6ri862T4N for ; Thu, 10 Mar 2016 01:19:24 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 D155312D5CB for ; Thu, 10 Mar 2016 01:19:19 -0800 (PST) Received: from [10.10.6.123] ([93.94.210.21]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Mgc0l-1aSAmw3gRz-00O0SN for ; Thu, 10 Mar 2016 10:19:18 +0100 To: DISPATCH References: <6303_1457539621_56E04A25_6303_1866_1_8B970F90C584EA4E97D5BAAC9172DBB815846652@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Georg Mayer Message-ID: <56E13C15.1040804@gmx.com> Date: Thu, 10 Mar 2016 10:19:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <6303_1457539621_56E04A25_6303_1866_1_8B970F90C584EA4E97D5BAAC9172DBB815846652@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:VCI9wecXztbSuFGIeCNYffxb+8W9FgyDCZey7PMcYmT4mqa3Eyw 2W5NsJNq/ADyaDZOrWA4J+21IhgLDeMTYABxXXld+6/6kjDhbr7aDyx1qFciUgepcqFlQ0Q w9LCCrkriSO68P5E2FmkfTUIPaiTB1Qs8FlkgmptykdZ8RmYkUHefbYSg0aneyCX7eQwGFw NWKPVVxqzFKGeKfgr9a7g== X-UI-Out-Filterresults: notjunk:1;V01:K0:JAmrxUQ7tyI=:n9FImyo8kzbY5VDjAkCfbU 53TmC03+OHvg5EFas+9W9NtGcwlEA5AjEmFJ7k93tP5xy4x0BZ8OOimLUU6/whzFhuDtwqyYK SPWw0g5FhW4/2tD7tCBvFCYfM8G7PERC9b6E/xascC0EtGo2PNr5YIcQAASLnwcuYnweN2NB/ heFLkZfi5yu57AqO3vbpkmzJ5wwjDLtqgOR6A9rR/7WFEeT7jRpEBns+zxRakTv9jHBYOGda+ YImm7Ldpyz8n8xfAueuFe/r73Y0n9Q3GLMS92ntkZgrLAdoQs+Ir7S/+JQ3O5SnRzyUyRYBQb YVleqF+BhlIU+j+Pz6l+JwLOf9A3wIkYSwiOofOQqLYa2BRRh9MgvVobKa5Zul5T9VzvCBp2T RoG3I6+sjfh8xpguVf/7uSdQMp7ZUHNHepb9uEBml+bf5NtoMu7ZT7U0IJ3huWUoP547Nq/++ yeORQrK755SGTexbR4h2kyWfcbyzn4hTpnbxBhPbTJPZN3FFdiWhuDeecanGFSWjfI2RS1HA4 gmpevqCYJvS0Pqr/c20jJbsGtAPTzH6lcr0WakMRll3B3j6GCeGMHwmeFoaQyr5KbvysCEuXq y590GHnFcyj7hVhJ+qL/dV4f78Fc2JCCzOqm+0sszOBCU1oE7MkjIODKb+a1jITEwGzAJVU5z v8CBnPHWKRC1g6+0zbF8l6Rio0dHRMyU/jlYO1f3m4+L5SaoGzcjrW/K9bFuoogyYH65z0tb7 SA7hgYve5vVZsE6vQEVb6R0gw0Kodojz9jlsTTWX7bTcawaV7tSpJf5wN1Y7n/E1urZgyi8O4 EaTmJd+ Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 09:19:31 -0000 Hello hello, +1 for progressing this ad AD sponsored. Cheers, Georg On 03/09/2016 05:07 PM, marianne.mohali@orange.com wrote: > Hi, > > > > I do support this draft to be progressed as AD sponsored. > > > > However, I have the following comment: In section 4. I think it would be > useful to add a table after the “new text” paragraph that summarize > where the different header fields can appear as it was done in section > 5.7 of RFC 3455. > > > > Best Regards, > > Marianne Mohali > > > > *De :*dispatch [mailto:dispatch-bounces@ietf.org] *De la part de* Mary > Barnes > *Envoyé :* lundi 7 mars 2016 16:34 > *À :* DISPATCH > *Objet :* [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates > as AD sponsored > > > > Hi folks, > > > > This document has been proposed to be progressed as AD sponsored: > > https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updates/ > > The document has been carefully reviewed and it is now ready to move > forward - Jean Mahoney is the shepherd. > > > > I don't anticipate anyone would have concerns about this decision, given > that's how RFC 7315 was progressed and this update has actually been > much more carefully reviewed. However, f anyone has any final comments, > please post no later than Friday, March 11th, 2016. Note, that you will > also still have IETF LC to provide any comments. > > > > Regards, > > Mary. > > _________________________________________________________________________________________________________________________ > > 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. > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Georg Mayer 3GPP CT Chairman HUAWEI Technologies Mobile: +43 699 1900 5758 From nobody Thu Mar 10 01:25:02 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FF912D5E9 for ; Thu, 10 Mar 2016 01:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, THIS_AD=1.991] autolearn=no autolearn_force=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 zVYoMa2gHjSb for ; Thu, 10 Mar 2016 01:24:58 -0800 (PST) Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 34CC512D612 for ; Thu, 10 Mar 2016 01:24:53 -0800 (PST) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id u2A9JjHG044361; Thu, 10 Mar 2016 04:24:46 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 21fv654nse-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Mar 2016 04:24:45 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u2A9OjNI022990; Thu, 10 Mar 2016 04:24:45 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u2A9OYwV022916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 Mar 2016 04:24:38 -0500 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 10 Mar 2016 09:24:20 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.15]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0248.002; Thu, 10 Mar 2016 04:24:20 -0500 From: "DOLLY, MARTIN C" To: Georg Mayer Thread-Topic: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored Thread-Index: AQHReq4R1O0ROKTUqkujsZyvkHQLN59SZ+OQ Date: Thu, 10 Mar 2016 09:24:19 +0000 Message-ID: References: <6303_1457539621_56E04A25_6303_1866_1_8B970F90C584EA4E97D5BAAC9172DBB815846652@OPEXCLILMA4.corporate.adroot.infra.ftgroup>, <56E13C15.1040804@gmx.com> In-Reply-To: <56E13C15.1040804@gmx.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-10_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603100158 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 09:25:01 -0000 I support Martin C Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards=20 AT&T Cell: 609-903-3360 Email: md3135@att.com > On Mar 10, 2016, at 4:20 AM, Georg Mayer wro= te: >=20 > Hello hello, >=20 > +1 for progressing this ad AD sponsored. >=20 > Cheers, > Georg >=20 >> On 03/09/2016 05:07 PM, marianne.mohali@orange.com wrote: >> Hi, >>=20 >>=20 >>=20 >> I do support this draft to be progressed as AD sponsored. >>=20 >>=20 >>=20 >> However, I have the following comment: In section 4. I think it would be >> useful to add a table after the =93new text=94 paragraph that summarize >> where the different header fields can appear as it was done in section >> 5.7 of RFC 3455. >>=20 >>=20 >>=20 >> Best Regards, >>=20 >> Marianne Mohali >>=20 >>=20 >>=20 >> *De :*dispatch [mailto:dispatch-bounces@ietf.org] *De la part de* Mary >> Barnes >> *Envoy=E9 :* lundi 7 mars 2016 16:34 >> *=C0 :* DISPATCH >> *Objet :* [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates >> as AD sponsored >>=20 >>=20 >>=20 >> Hi folks, >>=20 >>=20 >>=20 >> This document has been proposed to be progressed as AD sponsored: >>=20 >> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updates= / >>=20 >> The document has been carefully reviewed and it is now ready to move >> forward - Jean Mahoney is the shepherd. =20 >>=20 >>=20 >>=20 >> I don't anticipate anyone would have concerns about this decision, given >> that's how RFC 7315 was progressed and this update has actually been >> much more carefully reviewed. However, f anyone has any final comments, >> please post no later than Friday, March 11th, 2016. Note, that you will >> also still have IETF LC to provide any comments.=20 >>=20 >>=20 >>=20 >> Regards, >>=20 >> Mary.=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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. >>=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > --=20 > Georg Mayer > 3GPP CT Chairman > HUAWEI Technologies > Mobile: +43 699 1900 5758 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Mar 10 02:08:39 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEAC12D648 for ; Thu, 10 Mar 2016 02:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, THIS_AD=1.991] autolearn=no autolearn_force=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 uTjsejqBYOiK for ; Thu, 10 Mar 2016 02:08:37 -0800 (PST) Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 1927712D64C for ; Thu, 10 Mar 2016 02:08:37 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id u2AA5GQP002533; Thu, 10 Mar 2016 05:08:30 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 21fvqfv3p2-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Mar 2016 05:08:29 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u2AA8TnV026313; Thu, 10 Mar 2016 05:08:29 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u2AA8JDL026251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 Mar 2016 05:08:24 -0500 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 10 Mar 2016 10:08:02 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.15]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0248.002; Thu, 10 Mar 2016 05:08:02 -0500 From: "DOLLY, MARTIN C" To: Georg Mayer Thread-Topic: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored Thread-Index: AQHReq4R1O0ROKTUqkujsZyvkHQLN59SdBny Date: Thu, 10 Mar 2016 10:08:01 +0000 Message-ID: <5E6ED2CA-FF38-4BFA-90EC-F622ABE2A343@att.com> References: <6303_1457539621_56E04A25_6303_1866_1_8B970F90C584EA4E97D5BAAC9172DBB815846652@OPEXCLILMA4.corporate.adroot.infra.ftgroup>, <56E13C15.1040804@gmx.com> In-Reply-To: <56E13C15.1040804@gmx.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-10_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603100166 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 10:08:39 -0000 +1 Martin C Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards=20 AT&T Cell: 609-903-3360 Email: md3135@att.com > On Mar 10, 2016, at 4:20 AM, Georg Mayer wro= te: >=20 > Hello hello, >=20 > +1 for progressing this ad AD sponsored. >=20 > Cheers, > Georg >=20 >> On 03/09/2016 05:07 PM, marianne.mohali@orange.com wrote: >> Hi, >>=20 >>=20 >>=20 >> I do support this draft to be progressed as AD sponsored. >>=20 >>=20 >>=20 >> However, I have the following comment: In section 4. I think it would be >> useful to add a table after the =93new text=94 paragraph that summarize >> where the different header fields can appear as it was done in section >> 5.7 of RFC 3455. >>=20 >>=20 >>=20 >> Best Regards, >>=20 >> Marianne Mohali >>=20 >>=20 >>=20 >> *De :*dispatch [mailto:dispatch-bounces@ietf.org] *De la part de* Mary >> Barnes >> *Envoy=E9 :* lundi 7 mars 2016 16:34 >> *=C0 :* DISPATCH >> *Objet :* [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates >> as AD sponsored >>=20 >>=20 >>=20 >> Hi folks, >>=20 >>=20 >>=20 >> This document has been proposed to be progressed as AD sponsored: >>=20 >> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updates= / >>=20 >> The document has been carefully reviewed and it is now ready to move >> forward - Jean Mahoney is the shepherd. =20 >>=20 >>=20 >>=20 >> I don't anticipate anyone would have concerns about this decision, given >> that's how RFC 7315 was progressed and this update has actually been >> much more carefully reviewed. However, f anyone has any final comments, >> please post no later than Friday, March 11th, 2016. Note, that you will >> also still have IETF LC to provide any comments.=20 >>=20 >>=20 >>=20 >> Regards, >>=20 >> Mary.=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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. >>=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > --=20 > Georg Mayer > 3GPP CT Chairman > HUAWEI Technologies > Mobile: +43 699 1900 5758 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Mar 10 08:20:00 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6C812D733 for ; Thu, 10 Mar 2016 08:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 5Uzo5Zk5sk2e for ; Thu, 10 Mar 2016 08:19:57 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 375C212D555 for ; Thu, 10 Mar 2016 08:19:57 -0800 (PST) Received: from mutabilis-2.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2AGJupO009113 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Mar 2016 10:19:56 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be mutabilis-2.local To: marianne.mohali@orange.com, DISPATCH References: <6303_1457539621_56E04A25_6303_1866_1_8B970F90C584EA4E97D5BAAC9172DBB815846652@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: "A. Jean Mahoney" Message-ID: <56E19EAB.6020300@nostrum.com> Date: Thu, 10 Mar 2016 10:19:55 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <6303_1457539621_56E04A25_6303_1866_1_8B970F90C584EA4E97D5BAAC9172DBB815846652@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 16:19:59 -0000 Hi Marianne, On 3/9/16 10:07 AM, marianne.mohali@orange.com wrote: > Hi, > > I do support this draft to be progressed as AD sponsored. > > However, I have the following comment: In section 4. I think it would be > useful to add a table after the “new text” paragraph that summarize > where the different header fields can appear as it was done in section > 5.7 of RFC 3455. The table in 5.7 of RFC 3455 was an extension of Table 2 in RFC 3261, and for a while all SIP drafts that specified new header fields built on Table 2. After discussion at IETF 77, there was consensus that it would be better to describe the use of header fields in prose rather than in table format: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#SIP%20Table%202%20/%203 RFC 7315 removed the table. Now, its prose didn't capture everything that was in the table, which is what this draft is fixing. However, prose is still a better way to define the use of header fields than extending Table 2. Thanks, Jean > > Best Regards, > > Marianne Mohali > > *De :*dispatch [mailto:dispatch-bounces@ietf.org] *De la part de* Mary > Barnes > *Envoyé :* lundi 7 mars 2016 16:34 > *À :* DISPATCH > *Objet :* [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates > as AD sponsored > > Hi folks, > > This document has been proposed to be progressed as AD sponsored: > > https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updates/ > > The document has been carefully reviewed and it is now ready to move > forward - Jean Mahoney is the shepherd. > > I don't anticipate anyone would have concerns about this decision, given > that's how RFC 7315 was progressed and this update has actually been > much more carefully reviewed. However, f anyone has any final comments, > please post no later than Friday, March 11th, 2016. Note, that you will > also still have IETF LC to provide any comments. > > Regards, > > Mary. > > _________________________________________________________________________________________________________________________ > > 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. > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Thu Mar 10 11:27:04 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF7C12D76A for ; Thu, 10 Mar 2016 11:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wxTvqjgiprPK for ; Thu, 10 Mar 2016 11:27:01 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id E89A012DBB3 for ; Thu, 10 Mar 2016 11:27:00 -0800 (PST) Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs213cnc.rim.net with ESMTP/TLS/AES256-SHA; 10 Mar 2016 15:41:35 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.03.0210.002; Thu, 10 Mar 2016 14:26:57 -0500 From: Andrew Allen To: Georg Mayer , DISPATCH Thread-Topic: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored Thread-Index: AQHReq32dgGRnLTms0W3sgxl664amJ9TEEIu Date: Thu, 10 Mar 2016 19:26:56 +0000 Message-ID: <20160310192651.6234200.62881.5874@blackberry.com> References: <6303_1457539621_56E04A25_6303_1866_1_8B970F90C584EA4E97D5BAAC9172DBB815846652@OPEXCLILMA4.corporate.adroot.infra.ftgroup>, <56E13C15.1040804@gmx.com> In-Reply-To: <56E13C15.1040804@gmx.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 19:27:03 -0000 +1 from me too Sent from my BlackBerry 10 smartphone. Original Message From: Georg Mayer Sent: Thursday, March 10, 2016 10:19 To: DISPATCH Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates= as AD sponsored Hello hello, +1 for progressing this ad AD sponsored. Cheers, Georg On 03/09/2016 05:07 PM, marianne.mohali@orange.com wrote: > Hi, > > > > I do support this draft to be progressed as AD sponsored. > > > > However, I have the following comment: In section 4. I think it would be > useful to add a table after the =93new text=94 paragraph that summarize > where the different header fields can appear as it was done in section > 5.7 of RFC 3455. > > > > Best Regards, > > Marianne Mohali > > > > *De :*dispatch [mailto:dispatch-bounces@ietf.org] *De la part de* Mary > Barnes > *Envoy=E9 :* lundi 7 mars 2016 16:34 > *=C0 :* DISPATCH > *Objet :* [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates > as AD sponsored > > > > Hi folks, > > > > This document has been proposed to be progressed as AD sponsored: > > https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updates/ > > The document has been carefully reviewed and it is now ready to move > forward - Jean Mahoney is the shepherd. > > > > I don't anticipate anyone would have concerns about this decision, given > that's how RFC 7315 was progressed and this update has actually been > much more carefully reviewed. However, f anyone has any final comments, > please post no later than Friday, March 11th, 2016. Note, that you will > also still have IETF LC to provide any comments. > > > > Regards, > > Mary. > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Georg Mayer 3GPP CT Chairman HUAWEI Technologies Mobile: +43 699 1900 5758 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Mar 10 17:56:08 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC3F12DF9D for ; Thu, 10 Mar 2016 17:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2zE6q8sAXpuJ for ; Thu, 10 Mar 2016 17:56:04 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 65F7B12D978 for ; Thu, 10 Mar 2016 17:56:04 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 525EAA1613E3C; Fri, 11 Mar 2016 01:56:01 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2B1u1hn015537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Mar 2016 01:56:01 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u2B1u0Mx013994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Mar 2016 02:56:01 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 11 Mar 2016 02:56:00 +0100 From: "Drage, Keith (Nokia - GB)" To: "EXT A. Jean Mahoney" , "marianne.mohali@orange.com" , DISPATCH Thread-Topic: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored Thread-Index: AQHRezko30iPaHjLNE+Lt0cGMrHnuA== Date: Fri, 11 Mar 2016 01:55:59 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEA56B9@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <6303_1457539621_56E04A25_6303_1866_1_8B970F90C584EA4E97D5BAAC9172DBB815846652@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <56E19EAB.6020300@nostrum.com> In-Reply-To: <56E19EAB.6020300@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 01:56:07 -0000 Agree strongly. One of the issues (and there were others) is that the table mechanism requi= red some form of extension every time a new method was identified. Text all= ows a much more broad brush categorization of methods (e.g. "any request th= at creates a dialog", "a request or response within a dialog" etc.) such th= at this does not need to happen. I'd note that we were heading in this direction considerably earlier than I= ETF 77. Keith -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of EXT A. Jean = Mahoney Sent: 10 March 2016 16:20 To: marianne.mohali@orange.com; DISPATCH Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates= as AD sponsored Hi Marianne, On 3/9/16 10:07 AM, marianne.mohali@orange.com wrote: > Hi, > > I do support this draft to be progressed as AD sponsored. > > However, I have the following comment: In section 4. I think it would=20 > be useful to add a table after the "new text" paragraph that summarize=20 > where the different header fields can appear as it was done in section > 5.7 of RFC 3455. The table in 5.7 of RFC 3455 was an extension of Table 2 in RFC 3261, and f= or a while all SIP drafts that specified new header fields built on Table 2= . After discussion at IETF 77, there was consensus that it would be better = to describe the use of header fields in prose rather than in table format: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#SIP%20Table%202%= 20/%203 RFC 7315 removed the table. Now, its prose didn't capture everything that w= as in the table, which is what this draft is fixing. However, prose is stil= l a better way to define the use of header fields than extending Table 2. Thanks, Jean > > Best Regards, > > Marianne Mohali > > *De :*dispatch [mailto:dispatch-bounces@ietf.org] *De la part de* Mary=20 > Barnes *Envoy=E9 :* lundi 7 mars 2016 16:34 *=C0 :* DISPATCH *Objet :*=20 > [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates > as AD sponsored > > Hi folks, > > This document has been proposed to be progressed as AD sponsored: > > https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updat > es/ > > The document has been carefully reviewed and it is now ready to move=20 > forward - Jean Mahoney is the shepherd. > > I don't anticipate anyone would have concerns about this decision,=20 > given that's how RFC 7315 was progressed and this update has actually=20 > been much more carefully reviewed. However, f anyone has any final=20 > comments, please post no later than Friday, March 11th, 2016. Note,=20 > that you will also still have IETF LC to provide any comments. > > Regards, > > Mary. > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri Mar 11 01:24:51 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0B612D88A for ; Fri, 11 Mar 2016 01:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 Rtp7AQDMnqEk for ; Fri, 11 Mar 2016 01:24:47 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D771412D5C0 for ; Fri, 11 Mar 2016 01:24:46 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 2599F3246C6; Fri, 11 Mar 2016 10:24:45 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 0724D4C06B; Fri, 11 Mar 2016 10:24:45 +0100 (CET) Received: from OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0279.002; Fri, 11 Mar 2016 10:24:44 +0100 From: To: "A. Jean Mahoney" , DISPATCH Thread-Topic: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored Thread-Index: AQHRewdQGzu4LtC7O0mfj5I4tsfLcZ9T9whw Date: Fri, 11 Mar 2016 09:24:44 +0000 Message-ID: <1700_1457688285_56E28EDD_1700_40_1_8B970F90C584EA4E97D5BAAC9172DBB81A957230@OPEXCLILMA2.corporate.adroot.infra.ftgroup> References: <6303_1457539621_56E04A25_6303_1866_1_8B970F90C584EA4E97D5BAAC9172DBB815846652@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <56E19EAB.6020300@nostrum.com> In-Reply-To: <56E19EAB.6020300@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.8.144518 Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 09:24:49 -0000 Hi Jean, Thank you for your answer.=20 I thought that there was a discussion about that... It is not easy to have a quick view of the headers usage but indeed, prose = is more accurate. Best Regards, Marianne -----Message d'origine----- De=A0: A. Jean Mahoney [mailto:mahoney@nostrum.com]=20 Envoy=E9=A0: jeudi 10 mars 2016 17:20 =C0=A0: MOHALI Marianne IMT/OLN; DISPATCH Objet=A0: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-update= s as AD sponsored Hi Marianne, On 3/9/16 10:07 AM, marianne.mohali@orange.com wrote: > Hi, > > I do support this draft to be progressed as AD sponsored. > > However, I have the following comment: In section 4. I think it would=20 > be useful to add a table after the "new text" paragraph that summarize=20 > where the different header fields can appear as it was done in section > 5.7 of RFC 3455. The table in 5.7 of RFC 3455 was an extension of Table 2 in RFC 3261, and f= or a while all SIP drafts that specified new header fields built on Table 2= . After discussion at IETF 77, there was consensus that it would be better = to describe the use of header fields in prose rather than in table format: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#SIP%20Table%202%= 20/%203 RFC 7315 removed the table. Now, its prose didn't capture everything that w= as in the table, which is what this draft is fixing. However, prose is stil= l a better way to define the use of header fields than extending Table 2. Thanks, Jean > > Best Regards, > > Marianne Mohali > > *De :*dispatch [mailto:dispatch-bounces@ietf.org] *De la part de* Mary=20 > Barnes *Envoy=E9 :* lundi 7 mars 2016 16:34 *=C0 :* DISPATCH *Objet :*=20 > [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates > as AD sponsored > > Hi folks, > > This document has been proposed to be progressed as AD sponsored: > > https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updat > es/ > > The document has been carefully reviewed and it is now ready to move=20 > forward - Jean Mahoney is the shepherd. > > I don't anticipate anyone would have concerns about this decision,=20 > given that's how RFC 7315 was progressed and this update has actually=20 > been much more carefully reviewed. However, f anyone has any final=20 > comments, please post no later than Friday, March 11th, 2016. Note,=20 > that you will also still have IETF LC to provide any comments. > > Regards, > > Mary. > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > ___________________________________________________________________________= ______________________________________________ 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. From nobody Fri Mar 11 01:50:27 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB1F12D5D4 for ; Fri, 11 Mar 2016 01:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 q3L3lCYbYt_t for ; Fri, 11 Mar 2016 01:50:23 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 CC8A512D5C7 for ; Fri, 11 Mar 2016 01:50:20 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id p65so10221875wmp.0 for ; Fri, 11 Mar 2016 01:50:20 -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 :cc:content-transfer-encoding; bh=636n/TO1mudtdT+HGpSnWV6hXqS6m/CW28ih44Z9MsY=; b=fWteR8Ph29Q6X16fp75ReiVpJMlaDcj9wip0Vj7Kqh8AHfgun7+pDlmtileIN1ZWIZ j1eCUxZJ2gollmDyAm+zUlRNoiUf7bbXXuCmCLPAJr8D4CdDP6fk4M8A+njANv/86LJZ rCqNwJYVFSxiK9IOiM1taD3My1gdTRQ8ZErlpb4I1PU3PQZ0EfGjYUCl273QjTO2m8WW Y2Sv7mTMB0PS/htTdMsNFTSZm4ukuI3gX97HOG5naZdFCoAxBF7Evg9dFLY0NwE591B4 zCbVEroC4QHxAUVJkZ/LT0fTZdZ/0J4jgHmcAbNpwqQrtzI3RlldTR5gmlpzgJ2LgoKM Og1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=636n/TO1mudtdT+HGpSnWV6hXqS6m/CW28ih44Z9MsY=; b=Ep94mTLGGcJV3JfJ+c0rxPccRq/oMFEgaFryZDGEENlChroB6l+NsLGPl8+M4tPdCe HfY2Z8Z9qjP3a8c+DOQac4rVN/LCe2RpxljULSK5kITaHUqKcovypAmYVgT3WqwSub8H Cy7SbsTlHPMqnYhXGBly5JvUolcjdoNUC3ZNdF0xrwCrSp7D9VZyJuPpF0RFK7zfV0p/ QbDAYvkw5HCTN6DS5BlDgJ2w5tdtL87/GOP+KTpKh7sDqXKJXYdi5I0NHidjz+0VJV8l Fis6eQ6mnJ4MMiyp0MnCFrsKSk8i72sTq0PLYuPpZNbz4yfZxgfUnyu6hdiKxRbQSxtQ X47Q== X-Gm-Message-State: AD7BkJJ+woIUYr1G6LzeK0RPSsfJO7LgII8jVo2f6a+JBX1RWNikbkVA5RnTZ0XUzqST+WR/RZqHmTOBOGTl1g== MIME-Version: 1.0 X-Received: by 10.194.5.194 with SMTP id u2mr8754734wju.139.1457689819207; Fri, 11 Mar 2016 01:50:19 -0800 (PST) Received: by 10.28.16.67 with HTTP; Fri, 11 Mar 2016 01:50:19 -0800 (PST) In-Reply-To: References: Date: Fri, 11 Mar 2016 10:50:19 +0100 Message-ID: From: Victor Pascual Avila To: Mary Barnes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Reminder: Deadlines for IETF-95 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 09:50:25 -0000 Where could I find the dispatched topics for IETF95? Thank you in advance, -Victor On Wed, Feb 10, 2016 at 2:54 PM, Mary Barnes w= rote: > Hi all, > > Just a reminder of the DISPATCH WG deadlines for IETF-95: > https://trac.tools.ietf.org/wg/dispatch/trac/wiki > > February 22, 2016. Cutoff date to notify the chairs/DISPATCH WG of plans = to > submit a proposal. > > February 29, 2016. Cutoff for charter proposals for topics. > > March 7, 2016. Announcement of topics that have been dispatched for IETF-= 95. > > March 21, 2016. Draft deadline. > > > Regards, > Mary > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 Victor Pascual =C3=81vila From nobody Sat Mar 12 00:58:12 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB1712D57A for ; Sat, 12 Mar 2016 00:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btinternet.com 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 P6cGCzCE_jIj for ; Sat, 12 Mar 2016 00:58:06 -0800 (PST) Received: from rgout0201.bt.lon5.cpcloud.co.uk (rgout0201.bt.lon5.cpcloud.co.uk [65.20.0.200]) by ietfa.amsl.com (Postfix) with ESMTP id AF23012D51F for ; Sat, 12 Mar 2016 00:58:05 -0800 (PST) X-OWM-Source-IP: 10.110.12.1 () X-OWM-Env-Sender: nweinronk@btinternet.com X-CTCH-RefID: str=0001.0A090201.56E3DA18.006C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-Junkmail-Premium-Raw: score=11/50, refid=2.7.2:2016.3.12.74519:17:11.743, ip=, rules=__HAS_FROM, __PHISH_FROM2, __FRAUD_WEBMAIL_FROM, FROM_NAME_ALLCAPS, __HAS_REPLYTO, __FRAUD_WEBMAIL_REPLYTO, __TO_MALFORMED_2, __TO_NO_NAME, __HAS_MSGID, __SANE_MSGID, INVALID_MSGID_NO_FQDN, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_PRIORITY, __REPLYTO_SAMEAS_FROM_ADDY, __REPLYTO_SAMEAS_FROM_ACC, __REPLYTO_SAMEAS_FROM_DOMAIN, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __FRAUD_CONTACT_NAME, __CANPHARM_COPYRIGHT, __C230066_P5, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __FORWARDED_MSG, BODY_SIZE_10000_PLUS, BODYTEXTH_SIZE_3000_MORE, __MIME_HTML, __URI_NS, HTML_00_01, HTML_00_10, __PHISH_FROM, __PHISH_SPEAR_STRUCTURE_1, PRIORITY_NO_NAME, __FRAUD_WEBMAIL, NO_URI_HTTPS X-CTCH-Spam: Unknown Received: from webmail30.bt.ext.cpcloud.co.uk (10.110.12.1) by rgout02.bt.lon5.cpcloud.co.uk (8.6.122.06) (authenticated as nweinronk@btinternet.com) id 56DDD31600896E7E; Sat, 12 Mar 2016 08:57:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1457773074; bh=/8XNrtnFoNjGVR7P3QCieYCPNuDI4RSHrA99WG9mE8A=; h=Date:From:Reply-To:To:Message-ID:Subject:MIME-Version; b=nR1Z60lZq/airl33KcXFbflyu0nrlRVdO6j3Nro+0pnoJ+cfOjwUwDEHLs8jt5W6PTnMmG3TSfBYr6fgNynmTbeNlfAYIO8iN+y+m7ao0AGGCqrqORE7S+RFwz4nVP2EIlINTPhufK0XzTTiXHQmD50YTKK5T+pAuSJx6sdFw0Y= Date: Sat, 12 Mar 2016 08:58:00 +0000 (GMT) From: N WEINRONK To: marianne.mohali@orange.com, michael.hammer@yaanatech.com, keith.drage@nokia.com, dispatch@ietf.org Message-ID: <13829706.3548.1457773080244.JavaMail.defaultUser@defaultHost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3547_2845389.1457773080222" X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-UID: 25421 X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: X-CP-REPLY-ALL-PATH: Importance: 3 (Normal) X-Priority: 3 (Normal) X-Client-IP: IPv4[86.145.180.157] Epoch[1457773080224] Archived-At: Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nweinronk@btinternet.com List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 08:58:10 -0000 ------=_Part_3547_2845389.1457773080222 Content-Type: multipart/alternative; boundary="----=_Part_3546_24822103.1457773080222" ------=_Part_3546_24822103.1457773080222 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your comments. I was trying to make this parameter usable by any other country that has th= e same issue - I am sure the UK cannot be the only country that allows Carr= ier Pre-Select type services on diverted calls and requires a "network asse= rted" identity of the last Diverting Party so that the operator providing t= his service on the diverting call can bill and verify the calls. I did look at History-Info and I could not see a way to use this. I also had in mind that this information will need to be remove at some ope= rator / user boundaries by operators not interested in it - therefore using= History-Info even if it did work (which I am not sure of) looked very mess= y. Your understanding is correct - I would add 1 thing in the ETIS ISDN 'parti= al rerouting' case they may have called a completely different unrelated nu= mber because the 'last Rerouting Nr' (number for presentation) may have no = relation to the node doing the diversion for which billing/verification nee= ds to be done. On your History-info mechanisms - specifically the first point - I understa= nd that the index can be increased however my understanding was that this s= ignified a new branch - which is not what we require here - here we need 2 = entries at the same level - if we used a separate hi-targeted-to-uri - read= the RFCs I was not convinced this was allowed - though it is unclear. Having not been able find a way to use History-Info (and my concern as abov= e even if we could) pushed me down the route of a new header. Thanks, Nigel ----Original message---- >From : marianne.mohali@orange.com Date : 09/03/2016 - 22:41 (GMTST) To : nweinronk@btinternet.com, michael.hammer@yaanatech.com, keith.drage@no= kia.com, dispatch@ietf.org Subject : RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Dear Nigel, =20 After a reading of the draft, I have the following comments : - =20 First, I wonder about having a standard, even informational, to solve a cou= ntry-specific need to convey an ISUP National parameter=E2=80=A6hum - =20 Second, I do think we can find a solution to solve your issue by using the = History-Info header. I don=E2=80=99t know yet how. J =20 IIUC, you need to convey the asserted identity of the diverting user into t= he forwarded leg even when he has been called to his declarative identity. I see several mechanisms in History-Info header that could be used for this= purpose: - =20 first you should know that it can be added additional entries in the Histor= y-Info header even when the Request URI does not change. In this case, the = index should be increased (1->2) and not extended (1 -> 1.1) as when forking is executed - =20 to be able to distinguish this identity from the normal diverting identity,= you could use the "rc" hi-target-param to refer to the normal History-Info= entry for the diversion and link both. With this mechanism, at the interworking you could find the last diverting= identity as described in 29.163 and then search for the entry having a "rc= " parameter having a value equals to the current (last diverting address) h= i-entry index value. - =20 finally, you could imagine a dedicated cause URI parameter (different from = those defined in RFC4458 for call diversion service) =20 =20 Best regards, Marianne =20 De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de N WEINRONK Envoy=C3=A9 : mercredi 9 mars 2016 23:08 =C3=80 : michael.hammer@yaanatech.com; keith.drage@nokia.com; dispatch@ietf= .org Objet : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 =20 Not sure I agree with the non-sequitur statement but lets move on. Let us explore the statement that History-Info "should" work a little more: =20 Can you explain how 1 entry can have a 'presentation' and a 'network assert= ed' identity that can be different - were you thinking of the hi-extension = ? Just to add to this in the UK (I can only really comment on this) the speci= fication of ETSI ISDN diversion services mandates that both the 'network as= serted' and the 'presentation' identities of the Diverting Party are passed= between operator networks on Diverted calls. This allows 'transit' operators handling Carrier Pre-select Diverted calls = to verify and bill the user.=20 All the documents I have seen be it 3GPP/IETF maps History-Info into Redire= cting Number - Redirecting Number does not have a screening indicator and i= s used directly for display in ETSI ISDN. In cases where the 'network asserted' identify is different from the 'prese= ntation' identity it is not clear to me how the information in the History-= Info header can be 'network asserted'. =20 I do not think it is 'this diversion' that is different it is the ability t= o consistently pass 'network asserted' and 'presentation' identities for Di= version information.=20 =20 Not sure how STIR is related ?=20 =20 Thanks, Nigel =20 =20 =20 ----Original message---- >From : michael.hammer@yaanatech.com Date : 09/03/2016 - 20:13 (GMTST) To : nweinronk@btinternet.com,=20 keith.drage@nokia.com, dispatch@ietf.org Subject : RE: RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Nigel, =20 Your logic was a non-sequitor. Like saying cats like milk, therefore don=E2=80=99t give chocolate to a dog= .=20 The conclusion has nothing to do with cats and milk. =20 So, while such logic is not conclusive for or against a separate header, the burden of proof for a separate header should lie on the one proposing a= new header, when face with the existing of a header that =E2=80=9Cshould=E2=80=9D work.= (the question at hand) =20 A separate header is warranted when an existing header has the wrong semant= ics and the existing syntax just won=E2=80=99t work. However, that doesn=E2=80= =99t seem to be the case. =20 If another implementation judges that the H-I header is a perfect fit, then= you won=E2=80=99t be looking there. Some existing implementations just might be doing this already. So, just want to be careful about willy nilly adding new headers. =20 I would note that both the Route header and the H-I header can be =E2=80=9C= network asserted=E2=80=9D. So, what makes this particular diversion different from H-I envisaged? =20 You make it sound like it should be part of the STIR discussion, when you c= ompare to P-Asserted-ID. Have you looked into that WG? =20 ________________________________ Michael Hammer michael.hammer@yaanatech.com +1 408 202 9291 =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentia= lity notice. This message is private and confidential. If you have received= this message in error, please notify us and remove it from your system. =20 From: N WEINRONK [mailto:nweinronk@btinternet.com] Sent: Wednesday, March 09, 2016 2:00 PM To: Michael Hammer ; keith.drage@nokia.com;=20 dispatch@ietf.org Subject: Re: RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 =20 Thanks for your time. =20 Please explain the negative consequences of a separate header ? =20 The only place I saw that this could have been placed in History-Info was a= s an hi-extension because it is really a 'network asserted id' of the hi-ta= rgeted-to-uri and this would place requirements on lots of functions to sea= rch History-Info entries to remove this 'network asserted' identity when required.=20 To me this is the same as From / P-Asserted-Identity - the P-Asserted_Ident= ity was not place in the From header as a parameter - I guess it could have= been. I think the same argument applies here in keeping the 'network asserted ide= ntity' and the 'presentation identity' for the same user apart in the signa= lling. Note: This also matches the ISUP implementation - a separate distinct param= eter. I see nothing illogical in a separate header. Thanks, Nigel =20 ----Original message---- >From : michael.hammer@yaanatech.com Date : 09/03/2016 - 17:20 (GMTST) To : nweinronk@btinternet.com,=20 keith.drage@nokia.com, dispatch@ietf.org Subject : RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id There is a danger here that this purpose could be supported by two differen= t headers (a new header or an old header) with potential negative consequences. =20 Please show what prevents you from supporting this purpose with History-Inf= o? =20 The argument that because A is supported by B, therefore C is not supported= by B, is illogical. =20 ________________________________ Michael Hammer michael.hammer@yaanatech.com +1 408 202 9291 =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentia= lity notice. This message is private and confidential. If you have received= this message in error, please notify us and remove it from your system. =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of N WEINRONK Sent: Wednesday, March 09, 2016 6:05 AM To: keith.drage@nokia.com;=20 dispatch@ietf.org Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 =20 Thank you for your comments on this Internet Draft =E2=80=93 I will try and= answer your points. Do you believe it is legacy from the early ISDN definitions or do you belie= ve it is new? Neither it a consequence of the way ETSI ISDN was implemented in the UK in = the 1990s that is still in use today =E2=80=93 see below. Note: I assume by early ISDN definitions you mean where ETSI ISDN was mappe= d to DASS and I am not talking about this. Can you explain where a proposed UK requirement comes from that is not cont= ained within the ETSI and ITU-T service definitions for the ISDN? This comes from current implementations in the UK based on NICC ND1007. In UK ISUP there is a parameter optional in the IAM =E2=80=93 Last Diverted= Line Identity in additional to the ITU/ETSI parameter Redirecting Number. There are times when these parameters are both present and can hold differe= nt information. You could see this as being analogous to FROM and P-Asserted-Id headers in = SIP with the Last Diverted Line Identity parameter being the =E2=80=98netwo= rk asserted identity=E2=80=99 used by networks other that the network diver= ting the call to verify service and the Redirecting Number parameter being the = =E2=80=98presentation number=E2=80=99. The cases I am aware of where these parameters can hold different informati= on come from ETSI ISDN diversion scenarios =E2=80=93 Call Forwarding Uncond= itional / Call Forwarding Busy / Call Forwarding No Reply / Call Deflection / Partial Rerouting. For Partial Rerouting the Last Diverted Line Identity parameter is based on= the =E2=80=98administration number=E2=80=99 as understood by the network d= oing the diversion and the network doing the verification and billing for these calls. The Redirecting Number parameter is set from the lastReroutin= gNr from the ASN.1 the private network sets in the Q.931 SETUP message =E2= =80=93 these can/will be different. For Call Forwarding Unconditional / Call Forwarding Busy / Call Forwarding = No Reply / Call Deflection the Last Diverted Line Identity parameter is bas= ed on the =E2=80=98administration number=E2=80=99 as understood by the netw= ork doing the diversion and the network doing the verification and billing for= these calls. The Redirecting Number parameter is set to the Called Party N= umber used to reach the diverting party =E2=80=93 these are not necessarily= the same. I=E2=80=99d also note that I believe if this is required then an addition t= o the History-Info header field would be more appropriate. We (myself and the UK NICC SIP Task Group) did consider using the History-I= nfo header for this but as the mappings are already defined from Redirectin= g Number parameter to History-Info by the IETF / ETSI / ITU it was felt this would be confusing and make the mappings complicated. Also I would expect this header to (like the Last Diverted Line Identity pa= rameter in UK ISUP) be limited in where it can be sent ie. between network = operators and not to end users again making use of History-Info more complicated. Nigel Weinronk =20 ----Original message---- >From : keith.drage@nokia.com Date : 09/03/2016 - 02:47 (GMTST) To : Phil.Hutchison@virginmedia.co.uk, dispatch@ietf.org Subject : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Can you explain where a proposed UK requirement comes from that is not cont= ained within the ETSI and ITU-T service definitions for the ISDN? =20 Do you believe it is legacy from the early ISDN definitions or do you belie= ve it is new? =20 I=E2=80=99d also note that I believe if this is required then an addition t= o the History-Info header field would be more appropriate. =20 Regards =20 Keith Drage =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of EXT Hutchison, Phil Sent: 04 March 2016 08:20 To: 'dispatch@ietf.org' Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 Hi, =20 I believe that this is required in the UK, and therefore would like to see = the draft accepted. =20 Regards =20 Phil ~~~~~~~~~~~~~~~~~ Phil Hutchison Liberty Global CAO - Communications Architecture Mobile +447775 938827 | Soft Client +44(0)3703 900464 | Email phil.hutchison@virginmedia.co.uk Meet Me Conference: 0808 1074444 [+44 1723204444] PIN 1256450# Visit www.virginmedia.co.uk for more information, and more fun Save paper - do you really need to print this email? =20 -------------------------------------------------------------------- Save Paper - Do you really need to print this e-mail? Visit www.virginmedia.com for more information, and more fun. This email and any attachments are or may be confidential and legally privi= leged and are sent solely for the attention of the addressee(s). If you have rece= ived this email in error, please delete it from your system: its use, disclosure or c= opying is unauthorised. Statements and opinions expressed in this email may not repre= sent those of Virgin Media. Any representations or commitments in this email are subject to contract.=20 Registered office: Media House, Bartley Wood Business Park, Hook, Hampshire= , RG27 9UP Registered in England and Wales with number 2591237 =20 =20 =20 =20 =20 =20 ___________________________________________________________________________= ______________________________________________ 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. ------=_Part_3546_24822103.1457773080222 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks for your comments.

I was trying to make this parameter usab= le by any other country that has the same issue - I am sure the UK can= not be the only country that allows Carrier Pre-Select type services on div= erted calls and requires a "network asserted" identity of the last Div= erting Party so that the operator providing this service on the diverting c= all can bill and verify the calls.

I did look at History-Info and I c= ould not see a way to use this.

I also had in mind that thi= s information will need to be remove at some operator / user boundaries by = operators not interested in it - therefore using History-Info even if it&nb= sp;did work (which I am not sure of) looked very messy.

Your understa= nding is correct - I would add 1 thing in the ETIS ISDN 'partial rerouting'= case they may have called a completely different unrelated number because = the 'last Rerouting Nr' (number for presentation) may have no relation= to the node doing the diversion for which billing/verification needs to be= done.

On your History-info mechanisms - specifically the first point= - I understand that the index can be increased however my understanding wa= s that this signified a new branch - which is not what we require here - he= re we need 2 entries at the same level - if we used a separate hi-targeted-= to-uri - read the RFCs I was not convinced this was allowed - though it is = unclear.

Having not been able find a way to use History-Info (and my = concern as above even if we could) pushed me down the route of a new h= eader.

Thanks,

Nigel

----Original message----
From : marianne.mohali= @orange.com
Date : 09/03/2016 - 22:41 (GMTST)
To : nweinronk@btintern= et.com, michael.hammer@yaanatech.com, keith.drage@nokia.com, dispatch@ietf.= org
Subject : RE: [dispatch] draft-weinronk-dispatch-last-diverting-line= -id

Dear Nigel,

 

After a reading of the draft, I have the following comments :=

-=           First, I wonder about having a standard, even informational= , to solve a country-specific need to convey an ISUP National parameter=E2= =80=A6hum

-=           Second, I do think we can find a solution to solve your iss= ue by using the History-Info header. I don=E2=80=99t know yet how. J

 

IIUC, you need to convey the asserted identity of the diverting user in= to the forwarded leg even when he has been called to his declarative identi= ty.

I see several mechanisms in History-Info header that could be used for = this purpose:

-=           first you should know that it can be added additional entri= es in the History-Info header even when the Request URI does not change. In= this case, the index should be increased (1->2) and not extended (1 -> 1.1) as when forking is executed

-=           to be able to distinguish this identity from the normal div= erting identity, you could use the "rc" hi-target-param to refer to the nor= mal History-Info entry for the diversion and link both. With this mechanism, at the interworking you could find the last diverting= identity as described in 29.163 and then search for the entry having a "rc= " parameter having a value equals to the current (last diverting address) h= i-entry index value.

-=           finally, you could imagine a dedicated cause URI parameter = (different from those defined in RFC4458 for call diversion service)

 

 

Best regards,

Marianne

 

De : dispatch [= mailto:dispatch-bounces@ietf.org] De la part de N WEINRONK
Envoy=C3=A9 : mercredi 9 mars 2016 23:08
=C3=80 : michael.hammer@yaanatech.com; keith.drage@nokia.com; d= ispatch@ietf.org
Objet : Re: [dispatch] draft-weinronk-dispatch-last-diverting-l= ine-id

 

 

Not sure I agree with the non-sequitur statement but lets move on.<= /o:p>

Let us explore the statement that History-Info "should" work a little mo= re:

 

Can you explain how 1 entry can have a 'presentation' and a 'network ass= erted' identity that can be different - were you thinking of the hi-extensi= on ?

Just to add to this in the UK (I can only really comment on this) the sp= ecification of ETSI ISDN diversion services mandates that both th= e 'network asserted' and the 'presentation' identities of the Diverting Par= ty are passed between operator networks on Diverted calls.

This allows 'transit' operators handling Carrier Pre-select Diverted cal= ls to verify and bill the user. 

All the documents I have seen be it 3GPP/IETF maps History-Info int= o Redirecting Number - Redirecting Number does not have a screening indicat= or and is used directly for display in ETSI ISDN.

In cases where the 'network asserted' identify is different from the 'pr= esentation' identity it is not clear to me how the information in the = History-Info header can be 'network asserted'.

 

I do not think it is 'this diversion' that is different it is the abilit= y to consistently pass 'network asserted' and 'presentation' identitie= s for Diversion information. 

 

Not sure how STIR is related ? 

 

Thanks,

Nigel

 

 

 

----Original message-= ---
>From : michael.hammer@y= aanatech.com
Date : 09/03/2016 - 20:13 (GMTST)
To : nweinronk@btinternet.com, keith.drage@nokia.com, dispatch@ie= tf.org
Subject : RE: RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id=

Nigel,

 

Your logic = was a non-sequitor.

Like saying= cats like milk, therefore don=E2=80=99t give chocolate to a dog. 

The conclus= ion has nothing to do with cats and milk.

 

So, while s= uch logic is not conclusive for or against a separate header,

the burden = of proof for a separate header should lie on the one proposing a new header= ,

when face w= ith the existing of a header that =E2=80=9Cshould=E2=80=9D work.  (the= question at hand)

 

A separate = header is warranted when an existing header has the wrong semantics

and the exi= sting syntax just won=E2=80=99t work.  However, that doesn=E2=80=99t s= eem to be the case.

 

If another = implementation judges that the H-I header is a perfect fit, then you won=E2= =80=99t be looking there.

Some existi= ng implementations just might be doing this already.

So, just wa= nt to be careful about willy nilly adding new headers.

 

I would not= e that both the Route header and the H-I header can be =E2=80=9Cnetwork ass= erted=E2=80=9D.

So, what ma= kes this particular diversion different from H-I envisaged?

 

You make it= sound like it should be part of the STIR discussion, when you compare to P= -Asserted-ID.

Have you lo= oked into that WG?

 

<= span style=3D'color: rgb(168, 20, 0); font-family: "Arial Narrow","sans-ser= if"; font-size: 10.5pt;'>________________________________

<= span style=3D'color: rgb(168, 20, 0); font-family: "Arial Narrow","sans-ser= if"; font-size: 10.5pt;'>Michael Hammer

michael.hammer@ya= anatech.com

+1 408 202 9291


=C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentia= lity notice. This message is private and confidential. If you have received= this message in error, please notify us and remove it from your system.

 

From: N WEINRONK [mailto:nweinronk@btinternet.com]
Sent: Wednesday, March 09, 2016 2:00 PM
To: Michael Hammer <michael.hammer@yaanatech.com>; keith.drage@nokia.com; dispatch@ietf.org
Subject: Re: RE: [dispatch] draft-weinronk-dispatch-last-diverting-l= ine-id

 

 

Thanks for your time.

 

Please explain the negative consequences of a separate header ?

 

The only place I saw that this could have been placed in History-Info wa= s as an hi-extension because it is really a 'network asserted id' of t= he hi-targeted-to-uri and this would place requirements on lots of fun= ctions to search History-Info entries to remove this 'network asserted' identity when required. 

To me this is the same as From / P-Asserted-Identity - the P-Asserted_Id= entity was not place in the From header as a parameter - I guess it could h= ave been.

I think the same argument applies here in keeping the 'network asserted = identity' and the 'presentation identity' for the same user apart in the si= gnalling.

Note: This also matches the ISUP implementation - a separate distinct pa= rameter.

I see nothing illogical in a separate header.

Thanks,

Nigel

 

----Original message-= ---
>From : michael.hammer@yaana= tech.com
Date : 09/03/2016 - 17:20 (GMTST)
To : nweinronk@btinternet.com, keith.drage@nokia.com, dispatch@ie= tf.org
Subject : RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id

There is a = danger here that this purpose could be supported by two different headers

(a new head= er or an old header) with potential negative consequences.

 

Please show= what prevents you from supporting this purpose with History-Info?

 

The argumen= t that because A is supported by B, therefore C is not supported by B, is i= llogical.

 

<= span style=3D'color: rgb(168, 20, 0); font-family: "Arial Narrow","sans-ser= if"; font-size: 10.5pt;'>________________________________

<= span style=3D'color: rgb(168, 20, 0); font-family: "Arial Narrow","sans-ser= if"; font-size: 10.5pt;'>Michael Hammer

michael.hammer@ya= anatech.com

+1 408 202 9291


=C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentia= lity notice. This message is private and confidential. If you have received= this message in error, please notify us and remove it from your system.

 

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of N WEINRONK
Sent: Wednesday, March 09, 2016 6:05 AM
To: keith.drage@nokia.com; dispatch@ietf.org
Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-= id

 

 

Thank you for your com= ments on this Internet Draft =E2=80=93 I will try and answer your points.

Do= you believe it is legacy from the early ISDN definitions or do you believe= it is new?

Neither it a consequen= ce of the way ETSI ISDN was implemented in the UK in the 1990s that is stil= l in use today =E2=80=93 see below.

Note: I assume by earl= y ISDN definitions you mean where ETSI ISDN was mapped to DASS and I am not= talking about this.

Ca= n you explain where a proposed UK requirement comes from that is not contai= ned within the ETSI and ITU-T service definitions for the ISDN?

This comes from curren= t implementations in the UK based on NICC ND1007.

In UK ISUP there is a = parameter optional in the IAM =E2=80=93 Last Diverted Line Identity in addi= tional to the ITU/ETSI parameter Redirecting Number.

There are times when t= hese parameters are both present and can hold different information.=

You could see this as = being analogous to FROM and P-Asserted-Id headers in SIP with the Last Dive= rted Line Identity parameter being the =E2=80=98network asserted identity= =E2=80=99 used by networks other that the network diverting the call to verify service and the Redirecting Number parameter being the = =E2=80=98presentation number=E2=80=99.

The cases I am aware o= f where these parameters can hold different information come from ETSI ISDN= diversion scenarios =E2=80=93 Call Forwarding Unconditional / Call Forward= ing Busy / Call Forwarding No Reply / Call Deflection / Partial Rerouting.

For Partial Rerouting = the Last Diverted Line Identity parameter is based on the =E2=80=98administ= ration number=E2=80=99 as understood by the network doing the diversion and= the network doing the verification and billing for these calls. The Redirecting Number parameter is set from the lastReroutin= gNr from the ASN.1 the private network sets in the Q.931 SETUP message =E2= =80=93 these can/will be different.

For Call Forwarding Un= conditional / Call Forwarding Busy / Call Forwarding No Reply / Call Deflec= tion the Last Diverted Line Identity parameter is based on the =E2=80=98adm= inistration number=E2=80=99 as understood by the network doing the diversion and the network doing the verification and billing for= these calls. The Redirecting Number parameter is set to the Called Party N= umber used to reach the diverting party =E2=80=93 these are not necessarily= the same.

I= =E2=80=99d also note that I believe if this is required then an addition to= the History-Info header field would be more appropriate.

We (myself and the UK = NICC SIP Task Group) did consider using the History-Info header for this bu= t as the mappings are already defined from Redirecting Number parameter to = History-Info by the IETF / ETSI / ITU it was felt this would be confusing and make the mappings complicated.

Also I would expect th= is header to (like the Last Diverted Line Identity parameter in UK ISUP) be= limited in where it can be sent ie. between network operators and not to e= nd users again making use of History-Info more complicated.

Nigel Weinronk<= o:p>

 

----Original message-= ---
>From : keith.drage@nokia.com Date : 09/03/2016 - 02:47 (GMTST)
To : Phil.Hutchison@vir= ginmedia.co.uk, dispatch@ietf.org
Subject : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id

Can you exp= lain where a proposed UK requirement comes from that is not contained withi= n the ETSI and ITU-T service definitions for the ISDN?

 

Do you beli= eve it is legacy from the early ISDN definitions or do you believe it is ne= w?

 

I=E2=80=99d= also note that I believe if this is required then an addition to the Histo= ry-Info header field would be more appropriate.

 

Regards

 

Keith Drage=

 

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of EXT Hutchison, Phil
Sent: 04 March 2016 08:20
To: 'dispatch@ietf.org'
Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id

 

Hi,

 

I believe that this is required in the UK, and therefo= re would like to see the draft accepted.

 

Regards

 

Phil

~~~~~~~~~~~~~~~~~

Phil Hutchison

Liberty Global CAO - Communications Architecture

Mobile +447775 938827 | Soft Client +44(0= )3703 900464 | Email phil.hutchison@virginmedia.co.uk

Meet Me Conference: 0808 1074444  [+44 1723204444] PIN 1256450#

Visit www.virginmedia.co.uk for more information, and more fun

Save paper - do you really need= to print this email?

 


--------------------------------------------------------------------
Save Paper - Do you really need to print this e-mail?

Visit www.vi= rginmedia.com for more information, and more fun.

This email and any attachments are or may be confid= ential and legally privileged
and are sent solely for the attention of the addressee(s). If you have rece= ived this
email in error, please delete it from your system: its use, disclosure or c= opying is
unauthorised. Statements and opinions expressed in this email may not repre= sent
those of Virgin Media. Any representations or commitments in this email are=
subject to contract.

Registered office: Media House, Bartley Wood Busine= ss Park, Hook, Hampshire, RG27 9UP
Registered in England and Wales with number 2591237

Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nweinronk@btinternet.com List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 08:58:31 -0000 ------=_Part_3554_18163901.1457773091234 Content-Type: multipart/alternative; boundary="----=_Part_3553_24729181.1457773091234" ------=_Part_3553_24729181.1457773091234 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I realise I have to tread carefully - however to me I am trying to have a h= eader for diverted calls like P-Asserted-Identity for basic calls. I have had a look at 3GPP P-headers and could not find a good fit. I agree that the information I want in the new header will have to be used = by STIR for diverted calls. For mappings to SS7 - at least in the UK - we already have a parameter to c= onvey this information - therefore the mapping is 'easy'. This is not about pure transit operators but about operators who provide se= rvice to subscribers hosted on another network - via Carrier Pre-Selection = or Indirect Access for example. I hope I have detailed the requirements for this work in the ID. I believe I have investigated the use of History-Info and as far as can see= I cannot fit this into its structure and even if I could I am not sure it = would be a good thing to do as explain in previous answers. Thanks, Nigel ----Original message---- >From : michael.hammer@yaanatech.com Date : 10/03/2016 - 00:05 (GMTST) To : marianne.mohali@orange.com, nweinronk@btinternet.com, keith.drage@noki= a.com, dispatch@ietf.org Subject : RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Nigel, =20 You are treading on a variety of current SIP headers for: - Tracking redirections - Presentation of the source of the call - Billing for the call. =20 Could you address the 3GPP P-header for billing indication? =20 I mention STIR because there are issues around how to properly attribute th= e source of a call. Which is precisely what you are attempting to do. That affects not only billing but fighting robo-calls which are a concern e= ven in the UK. =20 Having suffered through the mapping issues in IETF and in ITU-T SG11 some y= ears ago,=20 I would caution you to proceed carefully, as every new header adds a new co= mplicating factor. =20 And if you are just doing purely transit operations between SS7 systems,=20 I could even suggest you look into Q.1980.1. J =20 I raised a red flag here only because this seemed like d=C3=A9j=C3=A0 vu al= l over again. And am looking for more thorough investigation. I will have to refresh my memory to provide more complete response to your = requirements. But, in the meantime explicitly detailing all those requirements will help = with this process.. =20 ________________________________ Michael Hammer michael.hammer@yaanatech.com +1 408 202 9291 =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentia= lity notice. This message is private and confidential. If you have received= this message in error, please notify us and remove it from your system. =20 From: marianne.mohali@orange.com [mailto:marianne.mohali@orange.com]=20 Sent: Wednesday, March 09, 2016 5:41 PM To: nweinronk@btinternet.com; Michael Hammer = ; keith.drage@nokia.com; dispatch@ietf.org Subject: RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 Dear Nigel, =20 After a reading of the draft, I have the following comments : - First, I wonder about having a standard, even informational, to = solve a country-specific need to convey an ISUP National parameter=E2=80=A6= hum - Second, I do think we can find a solution to solve your issue by= using the History-Info header. I don=E2=80=99t know yet how. J =20 IIUC, you need to convey the asserted identity of the diverting user into t= he forwarded leg even when he has been called to his declarative identity. I see several mechanisms in History-Info header that could be used for this= purpose: - first you should know that it can be added additional entries in= the History-Info header even when the Request URI does not change. In this= case, the index should be increased (1->2) and not extended (1 -> 1.1) as = when forking is executed - to be able to distinguish this identity from the normal divertin= g identity, you could use the "rc" hi-target-param to refer to the normal H= istory-Info entry for the diversion and link both. With this mechanism, at = the interworking you could find the last diverting identity as described in= 29.163 and then search for the entry having a "rc" parameter having a valu= e equals to the current (last diverting address) hi-entry index value.=20 - finally, you could imagine a dedicated cause URI parameter (diff= erent from those defined in RFC4458 for call diversion service) =20 =20 Best regards, Marianne =20 De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de N WEINRONK Envoy=C3=A9 : mercredi 9 mars 2016 23:08 =C3=80 : michael.hammer@yaanatech.com; keith.drage@nokia.com; dispatch@ietf= .org Objet : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 =20 Not sure I agree with the non-sequitur statement but lets move on. Let us explore the statement that History-Info "should" work a little more: =20 Can you explain how 1 entry can have a 'presentation' and a 'network assert= ed' identity that can be different - were you thinking of the hi-extension = ? Just to add to this in the UK (I can only really comment on this) the speci= fication of ETSI ISDN diversion services mandates that both the 'network as= serted' and the 'presentation' identities of the Diverting Party are passed= between operator networks on Diverted calls. This allows 'transit' operators handling Carrier Pre-select Diverted calls = to verify and bill the user.=20 All the documents I have seen be it 3GPP/IETF maps History-Info into Redire= cting Number - Redirecting Number does not have a screening indicator and i= s used directly for display in ETSI ISDN.=20 In cases where the 'network asserted' identify is different from the 'prese= ntation' identity it is not clear to me how the information in the History-= Info header can be 'network asserted'. =20 I do not think it is 'this diversion' that is different it is the ability t= o consistently pass 'network asserted' and 'presentation' identities for Di= version information.=20 =20 Not sure how STIR is related ?=20 =20 Thanks, Nigel =20 =20 =20 ----Original message---- >From : michael.hammer@yaanatech.com Date : 09/03/2016 - 20:13 (GMTST) To : nweinronk@btinternet.com, keith.drage@nokia.com, dispatch@ietf.org Subject : RE: RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Nigel, =20 Your logic was a non-sequitor. Like saying cats like milk, therefore don=E2=80=99t give chocolate to a dog= . =20 The conclusion has nothing to do with cats and milk. =20 So, while such logic is not conclusive for or against a separate header,=20 the burden of proof for a separate header should lie on the one proposing a= new header,=20 when face with the existing of a header that =E2=80=9Cshould=E2=80=9D work.= (the question at hand) =20 A separate header is warranted when an existing header has the wrong semant= ics=20 and the existing syntax just won=E2=80=99t work. However, that doesn=E2=80= =99t seem to be the case. =20 If another implementation judges that the H-I header is a perfect fit, then= you won=E2=80=99t be looking there. Some existing implementations just might be doing this already. So, just want to be careful about willy nilly adding new headers. =20 I would note that both the Route header and the H-I header can be =E2=80=9C= network asserted=E2=80=9D. So, what makes this particular diversion different from H-I envisaged? =20 You make it sound like it should be part of the STIR discussion, when you c= ompare to P-Asserted-ID. Have you looked into that WG? =20 ________________________________ Michael Hammer michael.hammer@yaanatech.com +1 408 202 9291 =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentia= lity notice. This message is private and confidential. If you have received= this message in error, please notify us and remove it from your system. =20 From: N WEINRONK [mailto:nweinronk@btinternet.com]=20 Sent: Wednesday, March 09, 2016 2:00 PM To: Michael Hammer ; keith.drage@nokia.com; d= ispatch@ietf.org Subject: Re: RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 =20 Thanks for your time. =20 Please explain the negative consequences of a separate header ? =20 The only place I saw that this could have been placed in History-Info was a= s an hi-extension because it is really a 'network asserted id' of the hi-ta= rgeted-to-uri and this would place requirements on lots of functions to sea= rch History-Info entries to remove this 'network asserted' identity when re= quired.=20 To me this is the same as From / P-Asserted-Identity - the P-Asserted_Ident= ity was not place in the From header as a parameter - I guess it could have= been. I think the same argument applies here in keeping the 'network asserted ide= ntity' and the 'presentation identity' for the same user apart in the signa= lling. Note: This also matches the ISUP implementation - a separate distinct param= eter. I see nothing illogical in a separate header. Thanks, Nigel =20 ----Original message---- >From : michael.hammer@yaanatech.com Date : 09/03/2016 - 17:20 (GMTST) To : nweinronk@btinternet.com, keith.drage@nokia.com, dispatch@ietf.org Subject : RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id There is a danger here that this purpose could be supported by two differen= t headers=20 (a new header or an old header) with potential negative consequences. =20 Please show what prevents you from supporting this purpose with History-Inf= o? =20 The argument that because A is supported by B, therefore C is not supported= by B, is illogical. =20 ________________________________ Michael Hammer michael.hammer@yaanatech.com +1 408 202 9291 =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentia= lity notice. This message is private and confidential. If you have received= this message in error, please notify us and remove it from your system. =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of N WEINRONK Sent: Wednesday, March 09, 2016 6:05 AM To: keith.drage@nokia.com; dispatch@ietf.org Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 =20 Thank you for your comments on this Internet Draft =E2=80=93 I will try and= answer your points. Do you believe it is legacy from the early ISDN definitions or do you belie= ve it is new?=20 Neither it a consequence of the way ETSI ISDN was implemented in the UK in = the 1990s that is still in use today =E2=80=93 see below. Note: I assume by early ISDN definitions you mean where ETSI ISDN was mappe= d to DASS and I am not talking about this. Can you explain where a proposed UK requirement comes from that is not cont= ained within the ETSI and ITU-T service definitions for the ISDN?=20 This comes from current implementations in the UK based on NICC ND1007. In UK ISUP there is a parameter optional in the IAM =E2=80=93 Last Diverted= Line Identity in additional to the ITU/ETSI parameter Redirecting Number. There are times when these parameters are both present and can hold differe= nt information. You could see this as being analogous to FROM and P-Asserted-Id headers in = SIP with the Last Diverted Line Identity parameter being the =E2=80=98netwo= rk asserted identity=E2=80=99 used by networks other that the network diver= ting the call to verify service and the Redirecting Number parameter being = the =E2=80=98presentation number=E2=80=99. The cases I am aware of where these parameters can hold different informati= on come from ETSI ISDN diversion scenarios =E2=80=93 Call Forwarding Uncond= itional / Call Forwarding Busy / Call Forwarding No Reply / Call Deflection= / Partial Rerouting. For Partial Rerouting the Last Diverted Line Identity parameter is based on= the =E2=80=98administration number=E2=80=99 as understood by the network d= oing the diversion and the network doing the verification and billing for t= hese calls. The Redirecting Number parameter is set from the lastReroutingN= r from the ASN.1 the private network sets in the Q.931 SETUP message =E2=80= =93 these can/will be different. For Call Forwarding Unconditional / Call Forwarding Busy / Call Forwarding = No Reply / Call Deflection the Last Diverted Line Identity parameter is bas= ed on the =E2=80=98administration number=E2=80=99 as understood by the netw= ork doing the diversion and the network doing the verification and billing = for these calls. The Redirecting Number parameter is set to the Called Part= y Number used to reach the diverting party =E2=80=93 these are not necessar= ily the same. I=E2=80=99d also note that I believe if this is required then an addition t= o the History-Info header field would be more appropriate.=20 We (myself and the UK NICC SIP Task Group) did consider using the History-I= nfo header for this but as the mappings are already defined from Redirectin= g Number parameter to History-Info by the IETF / ETSI / ITU it was felt thi= s would be confusing and make the mappings complicated. Also I would expect this header to (like the Last Diverted Line Identity pa= rameter in UK ISUP) be limited in where it can be sent ie. between network = operators and not to end users again making use of History-Info more compli= cated. Nigel Weinronk =20 ----Original message---- >From : keith.drage@nokia.com Date : 09/03/2016 - 02:47 (GMTST) To : Phil.Hutchison@virginmedia.co.uk, dispatch@ietf.org Subject : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Can you explain where a proposed UK requirement comes from that is not cont= ained within the ETSI and ITU-T service definitions for the ISDN? =20 Do you believe it is legacy from the early ISDN definitions or do you belie= ve it is new? =20 I=E2=80=99d also note that I believe if this is required then an addition t= o the History-Info header field would be more appropriate. =20 Regards =20 Keith Drage =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of EXT Hutchiso= n, Phil Sent: 04 March 2016 08:20 To: 'dispatch@ietf.org' Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 Hi, =20 I believe that this is required in the UK, and therefore would like to see = the draft accepted. =20 Regards =20 Phil=20 ~~~~~~~~~~~~~~~~~=20 Phil Hutchison=20 Liberty Global CAO - Communications Architecture=20 Mobile +447775 938827 | Soft Client +44(0)3703 900464 | Email phil.hutchiso= n@virginmedia.co.uk=20 Meet Me Conference: 0808 1074444 [+44 1723204444] PIN 1256450# Visit www.virginmedia.co.uk for more information, and more fun=20 Save paper - do you really need to print this email? =20 -------------------------------------------------------------------- Save Paper - Do you really need to print this e-mail? Visit www.virginmedia.com for more information, and more fun. This email and any attachments are or may be confidential and legally privi= leged and are sent solely for the attention of the addressee(s). If you have rece= ived this email in error, please delete it from your system: its use, disclosure or c= opying is unauthorised. Statements and opinions expressed in this email may not repre= sent those of Virgin Media. Any representations or commitments in this email are subject to contract.=20 Registered office: Media House, Bartley Wood Business Park, Hook, Hampshire= , RG27 9UP Registered in England and Wales with number 2591237 =20 =20 =20 =20 =20 =20 ___________________________________________________________________________= ______________________________________________ =20 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. =20 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. ------=_Part_3553_24729181.1457773091234 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


I realise I have to tread carefully - however to me I am tryi= ng to have a header for diverted calls like P-Asserted-Identity for basic c= alls.

I have had a look at 3GPP P-headers and could not find a good f= it.

I agree that the information I want in the new header will have t= o be used by STIR for diverted calls.

For mappings to SS7 - at least = in the UK - we already have a parameter to convey this information - theref= ore the mapping is 'easy'.

This is not about pure transit operators b= ut about operators who provide service to subscribers hosted on another net= work - via Carrier Pre-Selection or Indirect Access for example.

I ho= pe I have detailed the requirements for this work in the ID.

I believ= e I have investigated the use of History-Info and as far as can see I canno= t fit this into its structure and even if I could I am not sure it would be= a good thing to do as explain in previous answers.

Thanks,

Nig= el


Nigel,=

&n= bsp;

You are treading on a variety of current SIP headers for:

-          Tracking redirecti= ons

-          = Presen= tation of the source of the call

-     &nbs= p;    Billing for the call.

 

Co= uld you address the 3GPP P-header for billing indication?=

&n= bsp;

I mention STIR because there are issues around how to properly at= tribute the source of a call.

<= span style=3D"color: rgb(31, 73, 125);">Which is precisely what you are att= empting to do.

That affects not only billing but fighting robo-ca= lls which are a concern even in the UK.

 <= /p>

Having s= uffered through the mapping issues in IETF and in ITU-T SG11 some years ago= ,

I would caution you to proceed carefully, as every new header = adds a new complicating factor.

 

And if you are j= ust doing purely transit operations between SS7 systems, =

I could= even suggest you look into Q.1980.1.  J

 

I raised a red flag here only be= cause this seemed like d=C3=A9j=C3=A0 vu all over again.<= /p>

And am l= ooking for more thorough investigation.

I will have to refresh my= memory to provide more complete response to your requirements.<= /span>

B= ut, in the meantime explicitly detailing all those requirements will help w= ith this process..

 

________________________________

= Michael Hammer<= o:p>

michael.hammer@yaanatech.com

+1<= b> 408 202 9291


=C2=A9 2016 Yaana Technologies, LLC. All Rights Re= served. Email confidentiality notice. This message is private and confident= ial. If you have received this message in error, please notify us and remov= e it from your system.

 

From: marianne.mohali@orange.com [ma= ilto:marianne.mohali@orange.com]
Sent: Wednesday, March 09, 2016= 5:41 PM
To: nweinronk@btinternet.com; Michael Hammer <michael= .hammer@yaanatech.com>; keith.drage@nokia.com; dispatch@ietf.org
S= ubject: RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id

 

Dear Nigel,<= /o:p>

 

After a reading of the draft, I have the following co= mments :

-<= span style=3D'font: 7pt/normal "Times New Roman"; font-size-adjust: none; f= ont-stretch: normal;'>         = ; First, I wonder about having a standard, even informational, to solve a = country-specific need to convey an ISUP National parameter=E2=80=A6hum=

-          Second, I do th= ink we can find a solution to solve your issue by using the History-Info he= ader. I don=E2=80=99t know yet how. J

 

IIUC, you need to convey the asserted id= entity of the diverting user into the forwarded leg even when he has been c= alled to his declarative identity.

I see several mechanisms in Hi= story-Info header that could be used for this purpose:

-  =         first you should know that it c= an be added additional entries in the History-Info header even when the Req= uest URI does not change. In this case, the index should be increased (1-&g= t;2) and not extended (1 -> 1.1) as when forking is executed<= /span>

-&nb= sp;         to be able to distingu= ish this identity from the normal diverting identity, you could use the "rc= " hi-target-param to refer to the normal History-Info entry for the diversi= on and link both. With this mechanism, at the interworking you could find t= he last diverting identity as described in 29.163 and then search for the e= ntry having a "rc" parameter having a value equals to the current (last div= erting address) hi-entry index value.

-    &nbs= p;     finally, you could imagine a dedicated cause = URI parameter (different from those defined in RFC4458 for call diversion s= ervice)

 

 

Best regards,

Marianne

 

<= span style=3D'font-family: "Tahoma",sans-serif; font-size: 10pt;'>De := dispatch [mailto:dispatch-= bounces@ietf.org] De la part de N WEINRONK
Envoy=C3=A9&nbs= p;: mercredi 9 mars 2016 23:08
=C3=80 : michael.hammer@yaanatech.com= ; keith.drage@nokia.com; dispatch@ietf.org
Objet : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id<= /span>

 =

 

N= ot sure I agree with the non-sequitur statement but lets move on.

Let us explore the statement that History-= Info "should" work a little more:

 

Can you explain how 1 ent= ry can have a 'presentation' and a 'network asserted' identity that can be = different - were you thinking of the hi-extension ?

Just to add to this in the UK (I can only really comment= on this) the specification of ETSI ISDN diversion services mandates t= hat both the 'network asserted' and the 'presentation' identities of t= he Diverting Party are passed between operator networks on Diverted calls.<= o:p>

This allows 'transit' operators h= andling Carrier Pre-select Diverted calls to verify and bill the user. = ;

All the documents I have s= een be it 3GPP/IETF maps History-Info into Redirecting Number - Redirecting= Number does not have a screening indicator and is used directly for displa= y in ETSI ISDN.

In cases wh= ere the 'network asserted' identify is different from the 'presentation' id= entity it is not clear to me how the information in the History-Info h= eader can be 'network asserted'.

=  

I do not think it is 'this= diversion' that is different it is the ability to consistently pass '= network asserted' and 'presentation' identities for Diversion informat= ion. 

 

Not sure how STIR is related ? <= /span>

 

Thanks,

Nigel

 

 

 =

----Original message---= -
>From : michael.ham= mer@yaanatech.com
Date : 09/03/2016 - 20:13 (GMTST)
To : nweinronk@btinternet.com, keith.drage@nokia.com, dispatch@ietf.org
Subject : RE: RE: [dispatch= ] draft-weinronk-dispatch-last-diverting-line-id<= /span>

Nigel,

 

Your logic was a non-sequitor.<= /span>

Like saying cats like milk, = therefore don=E2=80=99t give chocolate to a dog. 

The conclusion has nothing to do with cats an= d milk.

 

So, while such logic is not conclusive fo= r or against a separate header, =

the burden of proof for a separate header should lie on the one propos= ing a new header,

when fa= ce with the existing of a header that =E2=80=9Cshould=E2=80=9D work.  = (the question at hand)

 = ;

A separate header is warra= nted when an existing header has the wrong semantics

and the existing syntax just won=E2=80=99t work. =  However, that doesn=E2=80=99t seem to be the case.

 

If another implementation judges that the H-I header is a perfect= fit, then you won=E2=80=99t be looking there.

Some existing implementations just might be doing this a= lready.

So, just want to be = careful about willy nilly adding new headers.=

 

I w= ould note that both the Route header and the H-I header can be =E2=80=9Cnet= work asserted=E2=80=9D.

So, = what makes this particular diversion different from H-I envisaged?

 =

You make it sound like it should be part of the STIR disc= ussion, when you compare to P-Asserted-ID.

Have you looked into that WG?<= /o:p>

 

________________________________

Mi= chael Hammer

michael.hammer@yaan= atech.com


=C2=A9 2016 Yaana Technologies, LL= C. All Rights Reserved. Email confidentiality notice. This message is priva= te and confidential. If you have received this message in error, please not= ify us and remove it from your system.<= /span>

 

From: N WEINR= ONK [mailto:nweinronk@btinterne= t.com]
Sent: Wednesday, March 09, 2016 2:00 PM
To:= Michael Hammer <michael= .hammer@yaanatech.com>; kei= th.drage@nokia.com; dispatch@ietf.= org
Subject: Re: RE: [dispatch] draft-weinronk-dispatch-last-= diverting-line-id

 

 

Thanks for your time.

<= span lang=3D"FR"> 

Please ex= plain the negative consequences of a separate header ?

 

The = only place I saw that this could have been placed in History-Info was as an= hi-extension because it is really a 'network asserted id' of the hi-t= argeted-to-uri and this would place requirements on lots of functions = to search History-Info entries to remove this 'network asserted' identity w= hen required. 

To me this is= the same as From / P-Asserted-Identity - the P-Asserted_Identity was not p= lace in the From header as a parameter - I guess it could have been.

I think the same argument applies here = in keeping the 'network asserted identity' and the 'presentation identity' = for the same user apart in the signalling.

Note: This also matches the ISUP implementation - a separate dist= inct parameter.

I see nothing ill= ogical in a separate header.

Than= ks,

Nigel

 

----Original message----
From : michael.hammer@yaanatech.com
Date : 09/0= 3/2016 - 17:20 (GMTST)
To : = nweinronk@btinternet.com, keit= h.drage@nokia.com, dispatch@ietf.o= rg
Subject : RE: [dispatch] draft-weinronk-dispatch-last-diverting-l= ine-id

There is a danger here that this purpose coul= d be supported by two different headers

(a new header or an old header) with potential negative conseq= uences.

 

Please show what prevents you from suppor= ting this purpose with History-Info?

 

The argument= that because A is supported by B, therefore C is not supported by B, is il= logical.

 

______= __________________________

Michael Hammer

michael.hammer@yaanatech.com

+1 408 202 9291


=C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email confid= entiality notice. This message is private and confidential. If you have rec= eived this message in error, please notify us and remove it from your syste= m.

 

F= rom: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of N W= EINRONK
Sent: Wednesday, March 09, 2016 6:05 AM
To: keith.drage@nokia.com; dispatch@ietf.org
Subject: Re: [di= spatch] draft-weinronk-dispatch-last-diverting-line-id

 

 

Thank = you for your comments on this Internet Draft =E2=80=93 I will try and answe= r your points.

Do = you believe it is legacy from the early ISDN definitions or do you believe = it is new?

Neither i= t a consequence of the way ETSI ISDN was implemented in the UK in the 1990s= that is still in use today =E2=80=93 see below.

Note: I assume by early ISDN definitions y= ou mean where ETSI ISDN was mapped to DASS and I am not talking about this.=

Can you explain = where a proposed UK requirement comes from that is not contained within the= ETSI and ITU-T service definitions for the ISDN? =

This comes from current implementations in th= e UK based on NICC ND1007.

In UK ISUP there is a parameter optional in the IAM =E2=80=93 Last Di= verted Line Identity in additional to the ITU/ETSI parameter Redirecting Nu= mber.

There are times= when these parameters are both present and can hold different information.=

You could see this a= s being analogous to FROM and P-Asserted-Id headers in SIP with the Last Di= verted Line Identity parameter being the =E2=80=98network asserted identity= =E2=80=99 used by networks other that the network diverting the call to ver= ify service and the Redirecting Number parameter being the =E2=80=98present= ation number=E2=80=99.

For Partial Rerouting the Last Diverted Line Identity parameter is based= on the =E2=80=98administration number=E2=80=99 as understood by the networ= k doing the diversion and the network doing the verification and billing fo= r these calls. The Redirecting Number parameter is set from the lastRerouti= ngNr from the ASN.1 the private network sets in the Q.931 SETUP message =E2= =80=93 these can/will be different.

=

I=E2=80=99d also note that I believe if this is required then an = addition to the History-Info header field would be more appropriate.

We (myself and the UK NICC= SIP Task Group) did consider using the History-Info header for this but as= the mappings are already defined from Redirecting Number parameter to Hist= ory-Info by the IETF / ETSI / ITU it was felt this would be confusing and m= ake the mappings complicated.

Also I would expect this header to (like the Last Diverted Line Id= entity parameter in UK ISUP) be limited in where it can be sent ie. between= network operators and not to end users again making use of History-Info mo= re complicated.

Nigel= Weinronk

 

----Original message----
From : keith.drage@nokia.com
Date : 09/03/2016 - 02:47= (GMTST)
To : Phil.H= utchison@virginmedia.co.uk, dispat= ch@ietf.org
Subject : Re: [dispatch] draft-weinronk-dispatch-last-di= verting-line-id

Can you explain where a proposed UK r= equirement comes from that is not contained within the ETSI and ITU-T servi= ce definitions for the ISDN?

=

 

Do you believe it is= legacy from the early ISDN definitions or do you believe it is new?=

 <= o:p>

I=E2=80=99d also note that I believe if this is requi= red then an addition to the History-Info header field would be more appropr= iate.

=  

Regards=

 

Keith D= rage

<= span lang=3D"FR" style=3D"color: rgb(31, 73, 125);"> 

From: dispatch [mailto:dis= patch-bounces@ietf.org] On Behalf Of EXT Hutchison, Phil
S= ent: 04 March 2016 08:20
To: 'dispatch@ietf.org'
Subjec= t: [dispatch] draft-weinronk-dispatch-last-diverting-line-id

 

Hi,

 

I believe that th= is is required in the UK, and therefore would like to see the draft accepte= d.

 = ;

Regard= s

 =

Phil

~~~~~~~~~~~~~~~~= ~ <= o:p>

Phil Hutchison

Liberty Global CAO= - Communications Architecture

Mobile +447775 938827 | Soft Client +44(0)3703 900464 | Email phil.hutch= ison@virginmedia.co.uk

Meet Me Conference: 0808 1074444  [+4= 4 1723204444] PIN 1256450#

Visit <= a href=3D"http://www.virginmedia.co.uk/"> f= or more information, and more fun

Save paper - do you really need to print this email?=

 


----------------------------------------------------------= ----------
Save Paper - Do you really need to print this e-mail?<= span lang=3D"FR">

Visit www.virginmedia.com for more informati= on, and more fun.

This email and any attachments are or may be confidential and = legally privileged
and are sent solely for the attention of the addresse= e(s). If you have received this
email in error, please delete it from yo= ur system: its use, disclosure or copying is
unauthorised. Statements an= d opinions expressed in this email may not represent
those of Virgin Med= ia. Any representations or commitments in this email are
subject to cont= ract.

Registered office: Media House, Bartley Wood Business Park, Hook, Hampshi= re, RG27 9UP
Registered in England and Wales with number 2591237<= span lang=3D"FR">

 = ;

 

 =

 

 <= /span>

 

_____________________________________________=
___________________________________________________________________________=
_
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou cop=
ies sans autorisation. Si vous avez recu ce message par erreur, veuillez le=
 signaler
a l'expediteur et l=
e detruire ainsi que les pieces jointes. Les messages electroniques etant s=
usceptibles d'alteration,
Ora=
nge decline toute responsabilite si ce message a ete altere, deforme ou fal=
sifie. Merci.
 
This message and its attachments may =
contain confidential or privileged information that may be protected by law=
;
they should not be distribu=
ted, used or copied without authorisation.
If you have received this email in error, please notify the s=
ender and delete this message and its attachments.
<=
pre>As emails may be altered, Orange is not liable for me=
ssages that have been modified, changed or falsified.
Thank you.


------=_Part_3553_24729181.1457773091234-- ------=_Part_3554_18163901.1457773091234-- From nobody Sun Mar 13 15:43:46 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD62612D838 for ; Sun, 13 Mar 2016 15:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, THIS_AD=1.991] autolearn=no autolearn_force=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 pi9lYrSjRsCH for ; Sun, 13 Mar 2016 15:43:42 -0700 (PDT) Received: from gateway20.websitewelcome.com (gateway20.websitewelcome.com [192.185.69.18]) (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 1E9CE12D551 for ; Sun, 13 Mar 2016 15:43:41 -0700 (PDT) Received: from cm4.websitewelcome.com (unknown [108.167.139.16]) by gateway20.websitewelcome.com (Postfix) with ESMTP id 884842030063 for ; Sun, 13 Mar 2016 17:43:40 -0500 (CDT) Received: from gator4135.hostgator.com ([192.185.4.147]) by cm4.websitewelcome.com with id Vajc1s00e3AKFgo01ajdug; Sun, 13 Mar 2016 17:43:37 -0500 Received: from c-76-103-25-115.hsd1.ca.comcast.net ([76.103.25.115]:41834 helo=[10.0.96.12]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1afEjY-000AUq-CR; Sun, 13 Mar 2016 17:43:36 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Shida Schubert In-Reply-To: <20160310192651.6234200.62881.5874@blackberry.com> Date: Sun, 13 Mar 2016 15:43:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6303_1457539621_56E04A25_6303_1866_1_8B970F90C584EA4E97D5BAAC9172DBB815846652@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <56E13C15.1040804@gmx.com> <20160310192651.6234200.62881.5874@blackberry.com> To: Andrew Allen X-Mailer: Apple Mail (2.2104) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 76.103.25.115 X-Exim-ID: 1afEjY-000AUq-CR X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-76-103-25-115.hsd1.ca.comcast.net ([10.0.96.12]) [76.103.25.115]:41834 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 22:43:45 -0000 +1 from me to progress this as AD sponsored as well. Shida > On Mar 10, 2016, at 11:26 AM, Andrew Allen = wrote: >=20 > +1 from me too >=20 > Sent from my BlackBerry 10 smartphone. > Original Message > From: Georg Mayer > Sent: Thursday, March 10, 2016 10:19 > To: DISPATCH > Subject: Re: [dispatch] Progressing = draft-holmberg-dispatch-rfc7315-updates as AD sponsored >=20 >=20 > Hello hello, >=20 > +1 for progressing this ad AD sponsored. >=20 > Cheers, > Georg >=20 > On 03/09/2016 05:07 PM, marianne.mohali@orange.com wrote: >> Hi, >>=20 >>=20 >>=20 >> I do support this draft to be progressed as AD sponsored. >>=20 >>=20 >>=20 >> However, I have the following comment: In section 4. I think it would = be >> useful to add a table after the =93new text=94 paragraph that = summarize >> where the different header fields can appear as it was done in = section >> 5.7 of RFC 3455. >>=20 >>=20 >>=20 >> Best Regards, >>=20 >> Marianne Mohali >>=20 >>=20 >>=20 >> *De :*dispatch [mailto:dispatch-bounces@ietf.org] *De la part de* = Mary >> Barnes >> *Envoy=E9 :* lundi 7 mars 2016 16:34 >> *=C0 :* DISPATCH >> *Objet :* [dispatch] Progressing = draft-holmberg-dispatch-rfc7315-updates >> as AD sponsored >>=20 >>=20 >>=20 >> Hi folks, >>=20 >>=20 >>=20 >> This document has been proposed to be progressed as AD sponsored: >>=20 >> = https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updates/ >>=20 >> The document has been carefully reviewed and it is now ready to move >> forward - Jean Mahoney is the shepherd. >>=20 >>=20 >>=20 >> I don't anticipate anyone would have concerns about this decision, = given >> that's how RFC 7315 was progressed and this update has actually been >> much more carefully reviewed. However, f anyone has any final = comments, >> please post no later than Friday, March 11th, 2016. Note, that you = will >> also still have IETF LC to provide any comments. >>=20 >>=20 >>=20 >> Regards, >>=20 >> Mary. >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >=20 > -- > Georg Mayer > 3GPP CT Chairman > HUAWEI Technologies > Mobile: +43 699 1900 5758 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Sun Mar 13 15:56:27 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3CE12D890 for ; Sun, 13 Mar 2016 15:56:26 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 zshbBfMPQOLr for ; Sun, 13 Mar 2016 15:56:22 -0700 (PDT) Received: from gateway30.websitewelcome.com (gateway30.websitewelcome.com [192.185.149.4]) (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 8342012D6F3 for ; Sun, 13 Mar 2016 15:56:22 -0700 (PDT) Received: from cm4.websitewelcome.com (unknown [108.167.139.16]) by gateway30.websitewelcome.com (Postfix) with ESMTP id 28B368E7C033E for ; Sun, 13 Mar 2016 17:56:21 -0500 (CDT) Received: from gator4135.hostgator.com ([192.185.4.147]) by cm4.websitewelcome.com with id VawK1s00Q3AKFgo01awMrK; Sun, 13 Mar 2016 17:56:21 -0500 Received: from c-76-103-25-115.hsd1.ca.comcast.net ([76.103.25.115]:43669 helo=[10.0.96.12]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1afEvr-000NUR-7K; Sun, 13 Mar 2016 17:56:19 -0500 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_4292830C-2E96-4817-8EAF-BC880262FD8C" From: Shida Schubert X-Priority: 3 (Normal) In-Reply-To: <13829706.3548.1457773080244.JavaMail.defaultUser@defaultHost> Date: Sun, 13 Mar 2016 15:56:17 -0700 Message-Id: <25C1837E-EDE8-48B6-BFF7-149339A1432E@ntt-at.com> References: <13829706.3548.1457773080244.JavaMail.defaultUser@defaultHost> To: nweinronk@btinternet.com X-Mailer: Apple Mail (2.2104) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 76.103.25.115 X-Exim-ID: 1afEvr-000NUR-7K X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-76-103-25-115.hsd1.ca.comcast.net ([10.0.96.12]) [76.103.25.115]:43669 X-Source-Auth: shida@agnada.com X-Email-Count: 4 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 22:56:26 -0000 --Apple-Mail=_4292830C-2E96-4817-8EAF-BC880262FD8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Nigel; Regarding the removal of the information, you can either use the Privacy = header as described in section 3.2 and 3.3 of RFC7131 when using = History-Info. Shida > On Mar 12, 2016, at 12:58 AM, N WEINRONK = wrote: >=20 > Thanks for your comments. >=20 > I was trying to make this parameter usable by any other country that = has the same issue - I am sure the UK cannot be the only country that = allows Carrier Pre-Select type services on diverted calls and requires a = "network asserted" identity of the last Diverting Party so that the = operator providing this service on the diverting call can bill and = verify the calls. >=20 > I did look at History-Info and I could not see a way to use this. >=20 > I also had in mind that this information will need to be remove at = some operator / user boundaries by operators not interested in it - = therefore using History-Info even if it did work (which I am not sure = of) looked very messy. >=20 > Your understanding is correct - I would add 1 thing in the ETIS ISDN = 'partial rerouting' case they may have called a completely different = unrelated number because the 'last Rerouting Nr' (number for = presentation) may have no relation to the node doing the diversion for = which billing/verification needs to be done. >=20 > On your History-info mechanisms - specifically the first point - I = understand that the index can be increased however my understanding was = that this signified a new branch - which is not what we require here - = here we need 2 entries at the same level - if we used a separate = hi-targeted-to-uri - read the RFCs I was not convinced this was allowed = - though it is unclear. >=20 > Having not been able find a way to use History-Info (and my concern as = above even if we could) pushed me down the route of a new header. >=20 > Thanks, >=20 > Nigel >=20 > ----Original message---- > =46rom : marianne.mohali@orange.com = > Date : 09/03/2016 - 22:41 (GMTST) > To : nweinronk@btinternet.com , = michael.hammer@yaanatech.com , = keith.drage@nokia.com , dispatch@ietf.org = > Subject : RE: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id >=20 > Dear Nigel, > =20 > After a reading of the draft, I have the following comments : > - First, I wonder about having a standard, even = informational, to solve a country-specific need to convey an ISUP = National parameter=E2=80=A6hum > - Second, I do think we can find a solution to solve your = issue by using the History-Info header. I don=E2=80=99t know yet how. J > =20 > IIUC, you need to convey the asserted identity of the diverting user = into the forwarded leg even when he has been called to his declarative = identity. > I see several mechanisms in History-Info header that could be used for = this purpose: > - first you should know that it can be added additional = entries in the History-Info header even when the Request URI does not = change. In this case, the index should be increased (1->2) and not = extended (1 -> 1.1) as when forking is executed > - to be able to distinguish this identity from the normal = diverting identity, you could use the "rc" hi-target-param to refer to = the normal History-Info entry for the diversion and link both. With this = mechanism, at the interworking you could find the last diverting = identity as described in 29.163 and then search for the entry having a = "rc" parameter having a value equals to the current (last diverting = address) hi-entry index value. > - finally, you could imagine a dedicated cause URI parameter = (different from those defined in RFC4458 for call diversion service) > =20 > =20 > Best regards, > Marianne > =20 > De : dispatch [mailto:dispatch-bounces@ietf.org = ] De la part de N WEINRONK > Envoy=C3=A9 : mercredi 9 mars 2016 23:08 > =C3=80 : michael.hammer@yaanatech.com = ; keith.drage@nokia.com = ; dispatch@ietf.org = > Objet : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id > =20 > =20 >=20 > Not sure I agree with the non-sequitur statement but lets move on. >=20 > Let us explore the statement that History-Info "should" work a little = more: >=20 > =20 >=20 > Can you explain how 1 entry can have a 'presentation' and a 'network = asserted' identity that can be different - were you thinking of the = hi-extension ? >=20 > Just to add to this in the UK (I can only really comment on this) the = specification of ETSI ISDN diversion services mandates that both the = 'network asserted' and the 'presentation' identities of the Diverting = Party are passed between operator networks on Diverted calls. >=20 > This allows 'transit' operators handling Carrier Pre-select Diverted = calls to verify and bill the user.=20 >=20 > All the documents I have seen be it 3GPP/IETF maps History-Info into = Redirecting Number - Redirecting Number does not have a screening = indicator and is used directly for display in ETSI ISDN. >=20 > In cases where the 'network asserted' identify is different from the = 'presentation' identity it is not clear to me how the information in the = History-Info header can be 'network asserted'. >=20 > =20 >=20 > I do not think it is 'this diversion' that is different it is the = ability to consistently pass 'network asserted' and 'presentation' = identities for Diversion information.=20 >=20 > =20 >=20 > Not sure how STIR is related ?=20 >=20 > =20 >=20 > Thanks, >=20 > Nigel >=20 > =20 >=20 > =20 >=20 > =20 >=20 > ----Original message---- > >=46rom : michael.hammer@yaanatech.com = > Date : 09/03/2016 - 20:13 (GMTST) > To : nweinronk@btinternet.com , = keith.drage@nokia.com , dispatch@ietf.org = > Subject : RE: RE: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id >=20 > Nigel, > =20 > Your logic was a non-sequitor. > Like saying cats like milk, therefore don=E2=80=99t give chocolate to = a dog.=20 > The conclusion has nothing to do with cats and milk. > =20 > So, while such logic is not conclusive for or against a separate = header, > the burden of proof for a separate header should lie on the one = proposing a new header, > when face with the existing of a header that =E2=80=9Cshould=E2=80=9D = work. (the question at hand) > =20 > A separate header is warranted when an existing header has the wrong = semantics > and the existing syntax just won=E2=80=99t work. However, that = doesn=E2=80=99t seem to be the case. > =20 > If another implementation judges that the H-I header is a perfect fit, = then you won=E2=80=99t be looking there. > Some existing implementations just might be doing this already. > So, just want to be careful about willy nilly adding new headers. > =20 > I would note that both the Route header and the H-I header can be = =E2=80=9Cnetwork asserted=E2=80=9D. > So, what makes this particular diversion different from H-I envisaged? > =20 > You make it sound like it should be part of the STIR discussion, when = you compare to P-Asserted-ID. > Have you looked into that WG? > =20 > ________________________________ > Michael Hammer > michael.hammer@yaanatech.com > +1 408 202 9291 >=20 > =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email = confidentiality notice. This message is private and confidential. If you = have received this message in error, please notify us and remove it from = your system. > =20 > From: N WEINRONK [mailto:nweinronk@btinternet.com = ]=20 > Sent: Wednesday, March 09, 2016 2:00 PM > To: Michael Hammer >; keith.drage@nokia.com = ; dispatch@ietf.org = > Subject: Re: RE: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id > =20 > =20 >=20 > Thanks for your time. >=20 > =20 >=20 > Please explain the negative consequences of a separate header ? >=20 > =20 >=20 > The only place I saw that this could have been placed in History-Info = was as an hi-extension because it is really a 'network asserted id' of = the hi-targeted-to-uri and this would place requirements on lots of = functions to search History-Info entries to remove this 'network = asserted' identity when required.=20 >=20 > To me this is the same as =46rom / P-Asserted-Identity - the = P-Asserted_Identity was not place in the =46rom header as a parameter - = I guess it could have been. >=20 > I think the same argument applies here in keeping the 'network = asserted identity' and the 'presentation identity' for the same user = apart in the signalling. >=20 > Note: This also matches the ISUP implementation - a separate distinct = parameter. >=20 > I see nothing illogical in a separate header. >=20 > Thanks, >=20 > Nigel >=20 > =20 >=20 > ----Original message---- > >=46rom : michael.hammer@yaanatech.com = > Date : 09/03/2016 - 17:20 (GMTST) > To : nweinronk@btinternet.com , = keith.drage@nokia.com , dispatch@ietf.org = > Subject : RE: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id >=20 > There is a danger here that this purpose could be supported by two = different headers > (a new header or an old header) with potential negative consequences. > =20 > Please show what prevents you from supporting this purpose with = History-Info? > =20 > The argument that because A is supported by B, therefore C is not = supported by B, is illogical. > =20 > ________________________________ > Michael Hammer > michael.hammer@yaanatech.com > +1 408 202 9291 >=20 > =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email = confidentiality notice. This message is private and confidential. If you = have received this message in error, please notify us and remove it from = your system. > =20 > From: dispatch [mailto:dispatch-bounces@ietf.org = ] On Behalf Of N WEINRONK > Sent: Wednesday, March 09, 2016 6:05 AM > To: keith.drage@nokia.com ; = dispatch@ietf.org > Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id > =20 > =20 >=20 > Thank you for your comments on this Internet Draft =E2=80=93 I will = try and answer your points. >=20 > Do you believe it is legacy from the early ISDN definitions or do you = believe it is new? >=20 > Neither it a consequence of the way ETSI ISDN was implemented in the = UK in the 1990s that is still in use today =E2=80=93 see below. >=20 > Note: I assume by early ISDN definitions you mean where ETSI ISDN was = mapped to DASS and I am not talking about this. >=20 > Can you explain where a proposed UK requirement comes from that is not = contained within the ETSI and ITU-T service definitions for the ISDN? >=20 > This comes from current implementations in the UK based on NICC = ND1007. >=20 > In UK ISUP there is a parameter optional in the IAM =E2=80=93 Last = Diverted Line Identity in additional to the ITU/ETSI parameter = Redirecting Number. >=20 > There are times when these parameters are both present and can hold = different information. >=20 > You could see this as being analogous to FROM and P-Asserted-Id = headers in SIP with the Last Diverted Line Identity parameter being the = =E2=80=98network asserted identity=E2=80=99 used by networks other that = the network diverting the call to verify service and the Redirecting = Number parameter being the =E2=80=98presentation number=E2=80=99. >=20 > The cases I am aware of where these parameters can hold different = information come from ETSI ISDN diversion scenarios =E2=80=93 Call = Forwarding Unconditional / Call Forwarding Busy / Call Forwarding No = Reply / Call Deflection / Partial Rerouting. >=20 > For Partial Rerouting the Last Diverted Line Identity parameter is = based on the =E2=80=98administration number=E2=80=99 as understood by = the network doing the diversion and the network doing the verification = and billing for these calls. The Redirecting Number parameter is set = from the lastReroutingNr from the ASN.1 the private network sets in the = Q.931 SETUP message =E2=80=93 these can/will be different. >=20 > For Call Forwarding Unconditional / Call Forwarding Busy / Call = Forwarding No Reply / Call Deflection the Last Diverted Line Identity = parameter is based on the =E2=80=98administration number=E2=80=99 as = understood by the network doing the diversion and the network doing the = verification and billing for these calls. The Redirecting Number = parameter is set to the Called Party Number used to reach the diverting = party =E2=80=93 these are not necessarily the same. >=20 > I=E2=80=99d also note that I believe if this is required then an = addition to the History-Info header field would be more appropriate. >=20 > We (myself and the UK NICC SIP Task Group) did consider using the = History-Info header for this but as the mappings are already defined = from Redirecting Number parameter to History-Info by the IETF / ETSI / = ITU it was felt this would be confusing and make the mappings = complicated. >=20 > Also I would expect this header to (like the Last Diverted Line = Identity parameter in UK ISUP) be limited in where it can be sent ie. = between network operators and not to end users again making use of = History-Info more complicated. >=20 > Nigel Weinronk >=20 > =20 >=20 > ----Original message---- > >=46rom : keith.drage@nokia.com > Date : 09/03/2016 - 02:47 (GMTST) > To : Phil.Hutchison@virginmedia.co.uk = , dispatch@ietf.org = > Subject : Re: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id >=20 > Can you explain where a proposed UK requirement comes from that is not = contained within the ETSI and ITU-T service definitions for the ISDN? > =20 > Do you believe it is legacy from the early ISDN definitions or do you = believe it is new? > =20 > I=E2=80=99d also note that I believe if this is required then an = addition to the History-Info header field would be more appropriate. > =20 > Regards > =20 > Keith Drage > =20 > From: dispatch [mailto:dispatch-bounces@ietf.org = ] On Behalf Of EXT Hutchison, Phil > Sent: 04 March 2016 08:20 > To: 'dispatch@ietf.org ' > Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id > =20 > Hi, > =20 > I believe that this is required in the UK, and therefore would like to = see the draft accepted. > =20 > Regards > =20 > Phil > ~~~~~~~~~~~~~~~~~ > Phil Hutchison > Liberty Global CAO - Communications Architecture > Mobile +447775 938827 | Soft Client +44(0)3703 900464 | Email = phil.hutchison@virginmedia.co.uk = > Meet Me Conference: 0808 1074444 [+44 1723204444] PIN 1256450# > Visit www.virginmedia.co.uk for more = information, and more fun > Save paper - do you really need to print this email? > =20 >=20 > -------------------------------------------------------------------- > Save Paper - Do you really need to print this e-mail? >=20 > Visit www.virginmedia.com for more = information, and more fun. >=20 > This email and any attachments are or may be confidential and legally = privileged > and are sent solely for the attention of the addressee(s). If you have = received this > email in error, please delete it from your system: its use, disclosure = or copying is > unauthorised. Statements and opinions expressed in this email may not = represent > those of Virgin Media. Any representations or commitments in this = email are > subject to contract.=20 >=20 > Registered office: Media House, Bartley Wood Business Park, Hook, = Hampshire, RG27 9UP > Registered in England and Wales with number 2591237 >=20 > =20 > =20 > =20 > =20 > =20 > =20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = --Apple-Mail=_4292830C-2E96-4817-8EAF-BC880262FD8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Nigel;

Regarding the removal of the information, you can either use = the Privacy header as described in section 3.2 and 3.3 of RFC7131 when = using History-Info.

Shida

On = Mar 12, 2016, at 12:58 AM, N WEINRONK <nweinronk@btinternet.com> wrote:

Thanks for your = comments.

I was trying to make = this parameter usable by any other country that has the same issue = - I am sure the UK cannot be the only country that allows Carrier = Pre-Select type services on diverted calls and requires a "network = asserted" identity of the last Diverting Party so that the operator = providing this service on the diverting call can bill and verify the = calls.

I did look at = History-Info and I could not see a way to use this.

I also had in mind that = this information will need to be remove at some operator / user = boundaries by operators not interested in it - therefore using = History-Info even if it did work (which I am not sure of) looked = very messy.

Your = understanding is correct - I would add 1 thing in the ETIS ISDN 'partial = rerouting' case they may have called a completely different unrelated = number because the 'last Rerouting Nr' (number for = presentation) may have no relation to the node doing the diversion = for which billing/verification needs to be done.

On your History-info = mechanisms - specifically the first point - I understand that the index = can be increased however my understanding was that this signified a new = branch - which is not what we require here - here we need 2 entries at = the same level - if we used a separate hi-targeted-to-uri - read the = RFCs I was not convinced this was allowed - though it is unclear.

Having not been able = find a way to use History-Info (and my concern as above even if we = could) pushed me down the route of a new header.

Thanks,

Nigel

----Original = message----
=46rom : marianne.mohali@orange.com
Date : 09/03/2016 - 22:41 (GMTST)
To : nweinronk@btinternet.com, michael.hammer@yaanatech.com, keith.drage@nokia.com, dispatch@ietf.org
Subject : RE: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id

Dear Nigel,
 
After a = reading of the draft, I have the following comments :
-          First, I = wonder about having a standard, even informational, to solve a = country-specific need to convey an ISUP National parameter=E2=80=A6hum
-          Second, I = do think we can find a solution to solve your issue by using the = History-Info header. I don=E2=80=99t know yet how. J
 
IIUC, you = need to convey the asserted identity of the diverting user into the = forwarded leg even when he has been called to his declarative = identity.
I see several mechanisms in History-Info header that could be = used for this purpose:
-          first you = should know that it can be added additional entries in the History-Info = header even when the Request URI does not change. In this case, the = index should be increased (1->2) and not extended (1 -> 1.1) as = when forking is executed
-          to be able = to distinguish this identity from the normal diverting identity, you = could use the "rc" hi-target-param to refer to the normal History-Info = entry for the diversion and link both. With this mechanism, at the = interworking you could find the last diverting identity as described in = 29.163 and then search for the entry having a "rc" parameter having a = value equals to the current (last diverting address) hi-entry index = value.
-          finally, = you could imagine a dedicated cause URI parameter (different from those = defined in RFC4458 for call diversion service)
 
 
Best = regards,
Marianne
 
De : dispatch [mailto:dispatch-bounces@ietf.org] De la part = de N WEINRONK
Envoy=C3=A9 : mercredi 9 mars = 2016 23:08
=C3=80 :<= span class=3D"Apple-converted-space"> michael.hammer@yaanatech.com; keith.drage@nokia.com; dispatch@ietf.org
Objet : Re: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id
 

 

Not sure I agree with the non-sequitur statement but = lets move on.

Let us explore the statement that History-Info = "should" work a little more:

 

Can you explain how 1 entry can have a 'presentation' and a = 'network asserted' identity that can be different - were you thinking of = the hi-extension ?

Just to add to this in the UK (I can only really = comment on this) the specification of ETSI ISDN diversion = services mandates that both the 'network asserted' and the = 'presentation' identities of the Diverting Party are passed between = operator networks on Diverted calls.

This allows 'transit' = operators handling Carrier Pre-select Diverted calls to verify and bill = the user. 

All the documents I have seen be it 3GPP/IETF = maps History-Info into Redirecting Number - Redirecting Number does not = have a screening indicator and is used directly for display in ETSI = ISDN.

In cases where the 'network asserted' identify is = different from the 'presentation' identity it is not clear to me = how the information in the History-Info header can be 'network = asserted'.

 

I do not think it is = 'this diversion' that is different it is the ability to consistently = pass 'network asserted' and 'presentation' identities for = Diversion information. 

 

Not sure how STIR is related ? 

 

Thanks,

Nigel

 

 

 

----Original message----
>=46rom : michael.hammer@yaanatech.com
Date : = 09/03/2016 - 20:13 (GMTST)
To : nweinronk@btinternet.com, keith.drage@nokia.com, dispatch@ietf.org
Subject : RE: RE: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id

Nigel,
 
Your logic was a = non-sequitor.
Like = saying cats like milk, therefore don=E2=80=99t give chocolate to a = dog. 
The = conclusion has nothing to do with cats and milk.
 
So, while such logic is = not conclusive for or against a separate header,
the burden of proof for a = separate header should lie on the one proposing a new header,
when face with the = existing of a header that =E2=80=9Cshould=E2=80=9D work.  (the = question at hand)
 
A = separate header is warranted when an existing header has the wrong = semantics
and the = existing syntax just won=E2=80=99t work.  However, that doesn=E2=80=99= t seem to be the case.
 
If another implementation judges that the H-I header = is a perfect fit, then you won=E2=80=99t be looking there.
Some existing = implementations just might be doing this already.
So, just want to be = careful about willy nilly adding new headers.
 
I would note that both the = Route header and the H-I header can be =E2=80=9Cnetwork = asserted=E2=80=9D.
So, what = makes this particular diversion different from H-I envisaged?
 
You make it sound like it = should be part of the STIR discussion, when you compare to = P-Asserted-ID.
Have you = looked into that WG?
 
________________________________
Michael Hammer
michael.hammer@yaanatech.com
+1 408 202 9291

=C2=A9 2016 Yaana = Technologies, LLC. All Rights Reserved. Email confidentiality notice. = This message is private and confidential. If you have received this = message in error, please notify us and remove it from your = system.
 
From: N WEINRONK [mailto:nweinronk@btinternet.com] 
Sent: Wednesday, March 09, 2016 = 2:00 PM
To: Michael Hammer <michael.hammer@yaanatech.com>; keith.drage@nokia.com; dispatch@ietf.org
Subject: Re: RE: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id
 

 

Thanks for your time.

 

Please= explain the negative consequences of a separate header ?

 

The only place I saw that this could have been placed = in History-Info was as an hi-extension because it is really a = 'network asserted id' of the hi-targeted-to-uri and this would = place requirements on lots of functions to search History-Info entries = to remove this 'network asserted' identity when required. 

To = me this is the same as =46rom / P-Asserted-Identity - the = P-Asserted_Identity was not place in the =46rom header as a parameter - = I guess it could have been.

I think the same = argument applies here in keeping the 'network asserted identity' and the = 'presentation identity' for the same user apart in the signalling.

Note: = This also matches the ISUP implementation - a separate distinct = parameter.

I see nothing illogical in a separate header.

Thanks,

Nigel

 

----Original = message----
>=46rom : michael.hammer@yaanatech.com
Date : = 09/03/2016 - 17:20 (GMTST)
To : nweinronk@btinternet.com, keith.drage@nokia.com, dispatch@ietf.org
Subject : RE: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id

There is a danger here that this purpose = could be supported by two different headers
(a new header or an old = header) with potential negative consequences.
 
Please show what prevents = you from supporting this purpose with History-Info?
 
The argument that because = A is supported by B, therefore C is not supported by B, is = illogical.
 
________________________________
Michael Hammer
michael.hammer@yaanatech.com
+1 408 202 9291

=C2=A9 2016 Yaana = Technologies, LLC. All Rights Reserved. Email confidentiality notice. = This message is private and confidential. If you have received this = message in error, please notify us and remove it from your = system.
 
From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf = Of N WEINRONK
Sent: Wednesday, March 09, 2016 = 6:05 AM
To: keith.drage@nokia.com; dispatch@ietf.org
Subject: Re: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id
 

 

Thank you for your comments on this = Internet Draft =E2=80=93 I will try and answer your points.

Do you believe it is = legacy from the early ISDN definitions or do you believe it is = new?

Neither it a consequence of the way = ETSI ISDN was implemented in the UK in the 1990s that is still = in use today =E2=80=93 see below.

Note: I assume by early ISDN definitions you mean where ETSI = ISDN was mapped to DASS and I am not talking about this.

Can you explain where a = proposed UK requirement comes from that is not contained within the ETSI = and ITU-T service definitions for the ISDN?

This comes from current implementations in the UK based on = NICC ND1007.

In UK ISUP there is a parameter = optional in the IAM =E2=80=93 Last Diverted Line Identity in additional = to the ITU/ETSI parameter Redirecting Number.

There are times when these parameters are both present and = can hold different information.

You could see this as being analogous to FROM and = P-Asserted-Id headers in SIP with the Last Diverted Line Identity = parameter being the =E2=80=98network asserted identity=E2=80=99 used by = networks other that the network diverting the call to verify service and = the Redirecting Number parameter being the =E2=80=98presentation = number=E2=80=99.

The cases I am aware of where these = parameters can hold different information come from ETSI ISDN diversion = scenarios =E2=80=93 Call Forwarding Unconditional / Call Forwarding Busy = / Call Forwarding No Reply / Call Deflection / Partial = Rerouting.

For Partial Rerouting the Last Diverted = Line Identity parameter is based on the =E2=80=98administration = number=E2=80=99 as understood by the network doing the diversion and the = network doing the verification and billing for these calls. The = Redirecting Number parameter is set from the lastReroutingNr from the = ASN.1 the private network sets in the Q.931 SETUP message =E2=80=93 = these can/will be different.

For Call Forwarding Unconditional / Call Forwarding Busy / = Call Forwarding No Reply / Call Deflection the Last Diverted Line = Identity parameter is based on the =E2=80=98administration number=E2=80=99= as understood by the network doing the diversion and the network doing = the verification and billing for these calls. The Redirecting Number = parameter is set to the Called Party Number used to reach the diverting = party =E2=80=93 these are not necessarily the same.

I=E2=80=99d also note that = I believe if this is required then an addition to the History-Info = header field would be more appropriate.

We= (myself and the UK NICC SIP Task Group) did consider using the = History-Info header for this but as the mappings are already defined = from Redirecting Number parameter to History-Info by the IETF / ETSI / = ITU it was felt this would be confusing and make the mappings = complicated.

Also I would expect this header to = (like the Last Diverted Line Identity parameter in UK ISUP) be limited = in where it can be sent ie. between network operators and not to end = users again making use of History-Info more complicated.

Nigel Weinronk

 

----Original message----
>=46rom : keith.drage@nokia.com
Date : 09/03/2016 - 02:47 (GMTST)
To : Phil.Hutchison@virginmedia.co.uk, dispatch@ietf.org
Subject : Re: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id

Can you explain where a proposed UK = requirement comes from that is not contained within the ETSI and ITU-T = service definitions for the ISDN?
 
Do you believe it is legacy from the early ISDN = definitions or do you believe it is new?
 
I=E2=80=99d also note that = I believe if this is required then an addition to the History-Info = header field would be more appropriate.
 
Regards
 
Keith Drage
 
From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf = Of EXT Hutchison, = Phil
Sent: 04 March 2016 08:20
To: 'dispatch@ietf.org'
Subject: [dispatch] = draft-weinronk-dispatch-last-diverting-line-id
 
Hi,
 
I believe that this is required in the UK, and therefore = would like to see the draft accepted.
 
Regards
 
Phil
~~~~~~~~~~~~~~~~~
Phil Hutchison
Liberty = Global CAO - Communications = Architecture
Mobile +447775 938827 | = Soft Client +44(0)3703 900464 | Email phil.hutchison@virginmedia.co.uk
Meet Me Conference: 0808 1074444  [+44 = 1723204444] PIN = 1256450#
Visit www.virginmedia.co.uk for more = information, and more fun
Save paper - do you = really need to print this email?
 


---------------------------------------------------------------= -----
Save Paper - Do you really need to print this = e-mail?

Visit www.virginmedia.com for more information, and = more fun.

This email and any = attachments are or may be confidential and legally privileged
and are sent solely for the attention of the addressee(s). If = you have received this
email in error, please delete it = from your system: its use, disclosure or copying is
unauthorised. Statements and opinions expressed in this email = may not represent
those of Virgin Media. Any = representations or commitments in this email are
subject = to contract. 

Registered office: Media House, Bartley Wood = Business Park, Hook, Hampshire, RG27 9UP
Registered in = England and Wales with number 2591237

 
 
 
 
 
 
_______________________________________________________________=
__________________________________________________________

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.



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

= --Apple-Mail=_4292830C-2E96-4817-8EAF-BC880262FD8C-- From nobody Mon Mar 14 01:07:12 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B319112DA4B for ; Mon, 14 Mar 2016 01:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btinternet.com 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 HBjJtNtJVlvN for ; Mon, 14 Mar 2016 01:07:07 -0700 (PDT) Received: from rgout0306.bt.lon5.cpcloud.co.uk (rgout0306.bt.lon5.cpcloud.co.uk [65.20.0.212]) by ietfa.amsl.com (Postfix) with ESMTP id D81AD12DA4D for ; Mon, 14 Mar 2016 01:07:05 -0700 (PDT) X-OWM-Source-IP: 10.110.12.2 () X-OWM-Env-Sender: nweinronk@btinternet.com X-CTCH-RefID: str=0001.0A090202.56E67122.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-Junkmail-Premium-Raw: score=12/50, refid=2.7.2:2016.2.29.2116:17:12.271, ip=, rules=__HAS_FROM, __PHISH_FROM2, __FRAUD_WEBMAIL_FROM, FROM_NAME_ALLCAPS, __HAS_REPLYTO, __FRAUD_WEBMAIL_REPLYTO, __TO_MALFORMED_2, __TO_NO_NAME, __MULTIPLE_RCPTS_CC_X2, __HAS_MSGID, __SANE_MSGID, INVALID_MSGID_NO_FQDN, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_PRIORITY, __REPLYTO_SAMEAS_FROM_ADDY, __REPLYTO_SAMEAS_FROM_ACC, __REPLYTO_SAMEAS_FROM_DOMAIN, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __FRAUD_CONTACT_NAME, __CANPHARM_COPYRIGHT, __C230066_P5, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __FORWARDED_MSG, BODY_SIZE_10000_PLUS, BODYTEXTH_SIZE_3000_MORE, __MIME_HTML, __URI_NS, HTML_00_01, HTML_00_10, __PHISH_FROM, MULTIPLE_RCPTS, __PHISH_SPEAR_STRUCTURE_1, PRIORITY_NO_NAME, __FRAUD_WEBMAIL, NO_URI_HTTPS X-CTCH-Spam: Unknown Received: from webmail45.bt.ext.cpcloud.co.uk (10.110.12.2) by rgout03.bt.lon5.cpcloud.co.uk (8.6.122.06) (authenticated as nweinronk@btinternet.com) id 56D09A2C01D17A62; Mon, 14 Mar 2016 08:06:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1457942825; bh=YpHEu045wpkkYVz2e00LbhSwXefIuqcUf9KXdpauiF4=; h=Date:From:Reply-To:To:Cc:Message-ID:Subject:MIME-Version; b=SOpOl9UZEGqydI8cz6BSKEH1jdcEiDjGTlkkaxMIPUBcvX4roMHL+LJPJd+18trD0HplX5z0JVvtuMP6QkwJNnTlyyEXdeheL8Cz9XrKUcB54l2JfduJjGBcN87TdSPKP7NT9xaopQ1ZnEfFLp+/4MdL+kXT8Fn1xkXTJkm1Vuk= Date: Mon, 14 Mar 2016 08:06:57 +0000 (GMT) From: N WEINRONK To: shida@ntt-at.com Message-ID: <19904236.2450.1457942818013.JavaMail.defaultUser@defaultHost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2449_9394508.1457942817990" X-CP-REPLY-ALL-UID: 25592 X-CP-REPLY-ALL-UID: 25592 X-CP-REPLY-ALL-UID: 25592 X-CP-REPLY-ALL-UID: 25592 X-CP-REPLY-ALL-UID: 25592 X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX Importance: 3 (Normal) X-Priority: 3 (Normal) X-Client-IP: IPv4[86.145.180.157] Epoch[1457942817991] Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nweinronk@btinternet.com List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 08:07:10 -0000 ------=_Part_2449_9394508.1457942817990 Content-Type: multipart/alternative; boundary="----=_Part_2448_29831600.1457942817989" ------=_Part_2448_29831600.1457942817989 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks I did have some understand how privacy 'history' works but again try= ing to put down an analogy with FROM/P-Asserted-Id I need 2 levels of priva= cy history'user' (current value) and history'id' (at the same index) and no= twithstanding I do not see how this is possible with History-Info this woul= d now put requirements of searching all entries and understand which type o= f privacy is required at each entry. I have not yet been convinced History-Info is a good fit for what I require= - I would say I did look at this as a first option. Thanks, Nigel ----Original message---- >From : shida@ntt-at.com Date : 13/03/2016 - 22:56 (GMTST) To : nweinronk@btinternet.com Cc : marianne.mohali@orange.com, michael.hammer@yaanatech.com, keith.drage@= nokia.com, dispatch@ietf.org Subject : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Hi Nigel; Regarding the removal of the information, you can either use the Privacy he= ader as described in section 3.2 and 3.3 of RFC7131 when using History-Info= . Shida On Mar 12, 2016, at 12:58 AM, N WEINRONK wrote: Thanks for your comments. I was trying to make this parameter usable by any other country that has th= e same issue - I am sure the UK cannot be the only country that allows Carr= ier Pre-Select type services on diverted calls and requires a "network asse= rted" identity of the last Diverting Party so that the operator providing t= his service on the diverting call can bill and verify the calls. I did look at History-Info and I could not see a way to use this. I also had in mind that this information will need to be remove at some ope= rator / user boundaries by operators not interested in it - therefore using= History-Info even if it did work (which I am not sure of) looked very mess= y. Your understanding is correct - I would add 1 thing in the ETIS ISDN 'parti= al rerouting' case they may have called a completely different unrelated nu= mber because the 'last Rerouting Nr' (number for presentation) may have no = relation to the node doing the diversion for which billing/verification nee= ds to be done. On your History-info mechanisms - specifically the first point - I understa= nd that the index can be increased however my understanding was that this s= ignified a new branch - which is not what we require here - here we need 2 = entries at the same level - if we used a separate hi-targeted-to-uri - read= the RFCs I was not convinced this was allowed - though it is unclear. Having not been able find a way to use History-Info (and my concern as abov= e even if we could) pushed me down the route of a new header. Thanks, Nigel ----Original message---- >From : marianne.mohali@orange.com Date : 09/03/2016 - 22:41 (GMTST) To : nweinronk@btinternet.com, michael.hammer@yaanatech.com, keith.drage@no= kia.com, dispatch@ietf.org Subject : RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Dear Nigel, =20 After a reading of the draft, I have the following comments : - First, I wonder about having a standard, even informational, to = solve a country-specific need to convey an ISUP National parameter=E2=80=A6= hum - Second, I do think we can find a solution to solve your issue by= using the History-Info header. I don=E2=80=99t know yet how. J =20 IIUC, you need to convey the asserted identity of the diverting user into t= he forwarded leg even when he has been called to his declarative identity. I see several mechanisms in History-Info header that could be used for this= purpose: - first you should know that it can be added additional entries in= the History-Info header even when the Request URI does not change. In this= case, the index should be increased (1->2) and not extended (1 -> 1.1) as = when forking is executed - to be able to distinguish this identity from the normal divertin= g identity, you could use the "rc" hi-target-param to refer to the normal H= istory-Info entry for the diversion and link both. With this mechanism, at = the interworking you could find the last diverting identity as described in= 29.163 and then search for the entry having a "rc" parameter having a valu= e equals to the current (last diverting address) hi-entry index value. - finally, you could imagine a dedicated cause URI parameter (diff= erent from those defined in RFC4458 for call diversion service) =20 =20 Best regards, Marianne =20 De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de N WEINRONK Envoy=C3=A9 : mercredi 9 mars 2016 23:08 =C3=80 : michael.hammer@yaanatech.com; keith.drage@nokia.com; dispatch@ietf= .org Objet : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 =20 Not sure I agree with the non-sequitur statement but lets move on. Let us explore the statement that History-Info "should" work a little more: =20 Can you explain how 1 entry can have a 'presentation' and a 'network assert= ed' identity that can be different - were you thinking of the hi-extension = ? Just to add to this in the UK (I can only really comment on this) the speci= fication of ETSI ISDN diversion services mandates that both the 'network as= serted' and the 'presentation' identities of the Diverting Party are passed= between operator networks on Diverted calls. This allows 'transit' operators handling Carrier Pre-select Diverted calls = to verify and bill the user.=20 All the documents I have seen be it 3GPP/IETF maps History-Info into Redire= cting Number - Redirecting Number does not have a screening indicator and i= s used directly for display in ETSI ISDN. In cases where the 'network asserted' identify is different from the 'prese= ntation' identity it is not clear to me how the information in the History-= Info header can be 'network asserted'. =20 I do not think it is 'this diversion' that is different it is the ability t= o consistently pass 'network asserted' and 'presentation' identities for Di= version information.=20 =20 Not sure how STIR is related ?=20 =20 Thanks, Nigel =20 =20 =20 ----Original message---- >From : michael.hammer@yaanatech.com Date : 09/03/2016 - 20:13 (GMTST) To : nweinronk@btinternet.com, keith.drage@nokia.com, dispatch@ietf.org Subject : RE: RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Nigel, =20 Your logic was a non-sequitor. Like saying cats like milk, therefore don=E2=80=99t give chocolate to a dog= .=20 The conclusion has nothing to do with cats and milk. =20 So, while such logic is not conclusive for or against a separate header, the burden of proof for a separate header should lie on the one proposing a= new header, when face with the existing of a header that =E2=80=9Cshould=E2=80=9D work.= (the question at hand) =20 A separate header is warranted when an existing header has the wrong semant= ics and the existing syntax just won=E2=80=99t work. However, that doesn=E2=80= =99t seem to be the case. =20 If another implementation judges that the H-I header is a perfect fit, then= you won=E2=80=99t be looking there. Some existing implementations just might be doing this already. So, just want to be careful about willy nilly adding new headers. =20 I would note that both the Route header and the H-I header can be =E2=80=9C= network asserted=E2=80=9D. So, what makes this particular diversion different from H-I envisaged? =20 You make it sound like it should be part of the STIR discussion, when you c= ompare to P-Asserted-ID. Have you looked into that WG? =20 ________________________________ Michael Hammer michael.hammer@yaanatech.com +1 408 202 9291 =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentia= lity notice. This message is private and confidential. If you have received= this message in error, please notify us and remove it from your system. =20 From: N WEINRONK [mailto:nweinronk@btinternet.com]=20 Sent: Wednesday, March 09, 2016 2:00 PM To: Michael Hammer ; keith.drage@nokia.com; d= ispatch@ietf.org Subject: Re: RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 =20 Thanks for your time. =20 Please explain the negative consequences of a separate header ? =20 The only place I saw that this could have been placed in History-Info was a= s an hi-extension because it is really a 'network asserted id' of the hi-ta= rgeted-to-uri and this would place requirements on lots of functions to sea= rch History-Info entries to remove this 'network asserted' identity when re= quired.=20 To me this is the same as From / P-Asserted-Identity - the P-Asserted_Ident= ity was not place in the From header as a parameter - I guess it could have= been. I think the same argument applies here in keeping the 'network asserted ide= ntity' and the 'presentation identity' for the same user apart in the signa= lling. Note: This also matches the ISUP implementation - a separate distinct param= eter. I see nothing illogical in a separate header. Thanks, Nigel =20 ----Original message---- >From : michael.hammer@yaanatech.com Date : 09/03/2016 - 17:20 (GMTST) To : nweinronk@btinternet.com, keith.drage@nokia.com, dispatch@ietf.org Subject : RE: [dispatch] draft-weinronk-dispatch-last-diverting-line-id There is a danger here that this purpose could be supported by two differen= t headers (a new header or an old header) with potential negative consequences. =20 Please show what prevents you from supporting this purpose with History-Inf= o? =20 The argument that because A is supported by B, therefore C is not supported= by B, is illogical. =20 ________________________________ Michael Hammer michael.hammer@yaanatech.com +1 408 202 9291 =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentia= lity notice. This message is private and confidential. If you have received= this message in error, please notify us and remove it from your system. =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of N WEINRONK Sent: Wednesday, March 09, 2016 6:05 AM To: keith.drage@nokia.com; dispatch@ietf.org Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 =20 Thank you for your comments on this Internet Draft =E2=80=93 I will try and= answer your points. Do you believe it is legacy from the early ISDN definitions or do you belie= ve it is new? Neither it a consequence of the way ETSI ISDN was implemented in the UK in = the 1990s that is still in use today =E2=80=93 see below. Note: I assume by early ISDN definitions you mean where ETSI ISDN was mappe= d to DASS and I am not talking about this. Can you explain where a proposed UK requirement comes from that is not cont= ained within the ETSI and ITU-T service definitions for the ISDN? This comes from current implementations in the UK based on NICC ND1007. In UK ISUP there is a parameter optional in the IAM =E2=80=93 Last Diverted= Line Identity in additional to the ITU/ETSI parameter Redirecting Number. There are times when these parameters are both present and can hold differe= nt information. You could see this as being analogous to FROM and P-Asserted-Id headers in = SIP with the Last Diverted Line Identity parameter being the =E2=80=98netwo= rk asserted identity=E2=80=99 used by networks other that the network diver= ting the call to verify service and the Redirecting Number parameter being = the =E2=80=98presentation number=E2=80=99. The cases I am aware of where these parameters can hold different informati= on come from ETSI ISDN diversion scenarios =E2=80=93 Call Forwarding Uncond= itional / Call Forwarding Busy / Call Forwarding No Reply / Call Deflection= / Partial Rerouting. For Partial Rerouting the Last Diverted Line Identity parameter is based on= the =E2=80=98administration number=E2=80=99 as understood by the network d= oing the diversion and the network doing the verification and billing for t= hese calls. The Redirecting Number parameter is set from the lastReroutingN= r from the ASN.1 the private network sets in the Q.931 SETUP message =E2=80= =93 these can/will be different. For Call Forwarding Unconditional / Call Forwarding Busy / Call Forwarding = No Reply / Call Deflection the Last Diverted Line Identity parameter is bas= ed on the =E2=80=98administration number=E2=80=99 as understood by the netw= ork doing the diversion and the network doing the verification and billing = for these calls. The Redirecting Number parameter is set to the Called Part= y Number used to reach the diverting party =E2=80=93 these are not necessar= ily the same. I=E2=80=99d also note that I believe if this is required then an addition t= o the History-Info header field would be more appropriate. We (myself and the UK NICC SIP Task Group) did consider using the History-I= nfo header for this but as the mappings are already defined from Redirectin= g Number parameter to History-Info by the IETF / ETSI / ITU it was felt thi= s would be confusing and make the mappings complicated. Also I would expect this header to (like the Last Diverted Line Identity pa= rameter in UK ISUP) be limited in where it can be sent ie. between network = operators and not to end users again making use of History-Info more compli= cated. Nigel Weinronk =20 ----Original message---- >From : keith.drage@nokia.com Date : 09/03/2016 - 02:47 (GMTST) To : Phil.Hutchison@virginmedia.co.uk, dispatch@ietf.org Subject : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id Can you explain where a proposed UK requirement comes from that is not cont= ained within the ETSI and ITU-T service definitions for the ISDN? =20 Do you believe it is legacy from the early ISDN definitions or do you belie= ve it is new? =20 I=E2=80=99d also note that I believe if this is required then an addition t= o the History-Info header field would be more appropriate. =20 Regards =20 Keith Drage =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of EXT Hutchiso= n, Phil Sent: 04 March 2016 08:20 To: 'dispatch@ietf.org' Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id =20 Hi, =20 I believe that this is required in the UK, and therefore would like to see = the draft accepted. =20 Regards =20 Phil ~~~~~~~~~~~~~~~~~ Phil Hutchison Liberty Global CAO - Communications Architecture Mobile +447775 938827 | Soft Client +44(0)3703 900464 | Email phil.hutchiso= n@virginmedia.co.uk Meet Me Conference: 0808 1074444 [+44 1723204444] PIN 1256450# Visit www.virginmedia.co.uk for more information, and more fun Save paper - do you really need to print this email? =20 -------------------------------------------------------------------- Save Paper - Do you really need to print this e-mail? Visit www.virginmedia.com for more information, and more fun. This email and any attachments are or may be confidential and legally privi= leged and are sent solely for the attention of the addressee(s). If you have rece= ived this email in error, please delete it from your system: its use, disclosure or c= opying is unauthorised. Statements and opinions expressed in this email may not repre= sent those of Virgin Media. Any representations or commitments in this email are subject to contract.=20 Registered office: Media House, Bartley Wood Business Park, Hook, Hampshire= , RG27 9UP Registered in England and Wales with number 2591237 =20 =20 =20 =20 =20 =20 ___________________________________________________________________________= ______________________________________________ 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. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_Part_2448_29831600.1457942817989 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks I did have some understand how privacy 'history' works but again = trying to put down an analogy with FROM/P-Asserted-Id I need 2 levels = of privacy history'user' (current value) and history'id' (at the same = index) and notwithstanding I do not see how this is possible with History-I= nfo this would now put requirements of searching all entries and understand= which type of privacy is required at each entry.

I have not yet= been convinced History-Info is a good fit for what I require - I would say= I did look at this as a first option.

Thanks,

Nigel

----Original messa= ge----
From : shida@ntt-at.com
Date : 13/03/2016 - 22:56 (GMTST)
T= o : nweinronk@btinternet.com
Cc : marianne.mohali@orange.com, michael.ha= mmer@yaanatech.com, keith.drage@nokia.com, dispatch@ietf.org
Subject : R= e: [dispatch] draft-weinronk-dispatch-last-diverting-line-id

Hi Nige= l;

Regarding the removal of the information, you can eit= her use the Privacy header as described in section 3.2 and 3.3 of RFC7131 w= hen using History-Info.

Shida

On Mar 12, 2016, at 12:58 AM, N WEINRONK <nweinronk@btinternet.com> = wrote:

Thanks for your comments.

I was trying to make this parameter u= sable by any other country that has the same issue - I am sure the UK = cannot be the only country that allows Carrier Pre-Select type services on = diverted calls and requires a "network asserted" identity of the last = Diverting Party so that the operator providing this service on the divertin= g call can bill and verify the calls.

I did look at History-Info and I could not see a way to&nb= sp;use this.

I a= lso had in mind that this information will need to be remove at some operat= or / user boundaries by operators not interested in it - therefore using Hi= story-Info even if it did work (which I am not sure of) looked very me= ssy.

Your understandi= ng is correct - I would add 1 thing in the ETIS ISDN 'partial rerouting' ca= se they may have called a completely different unrelated number because the= 'last Rerouting Nr' (number for presentation) may have no relation to= the node doing the diversion for which billing/verification needs to be do= ne.

On your History-i= nfo mechanisms - specifically the first point - I understand that the index= can be increased however my understanding was that this signified a new br= anch - which is not what we require here - here we need 2 entries at the sa= me level - if we used a separate hi-targeted-to-uri - read the RFCs I was n= ot convinced this was allowed - though it is unclear.

Having not been able find a way to use His= tory-Info (and my concern as above even if we could) pushed me down th= e route of a new header.

Thanks,

Nigel
=

----Original message----<= br>From : marianne.mohali@orange.com
Date : 09/03/2016 - 22:41 (GMTST= )
To : nweinronk@btinternet.com,&= nbsp;michael.hammer@yaanatech.com, keith.dra= ge@nokia.com, dispatch@ietf.org
Subject : RE: [dispatch] draft-weinronk-di= spatch-last-diverting-line-id

Dear Nigel,
 
After a reading of the= draft, I have the following comments :
-     &nbs= p;    Fi= rst, I wonder about having a standard, even informational, to solve a count= ry-specific need to convey an ISUP National parameter=E2=80=A6hum
-  &= nbsp;       Second, I do think we can find a solution to solve your = issue by using the History-Info header. I don=E2=80=99t know yet how. J
 
= IIUC, you need to convey the asserted identity of the diverting user into t= he forwarded leg even when he has been called to his declarative identity.<= o:p>
I see several mechanisms in History-Info header that could = be used for this purpose:
-<= span style=3D'font: 7pt/normal "Times New Roman"; font-size-adjust: none; f= ont-stretch: normal;'>         = ; first you should know= that it can be added additional entries in the History-Info header even wh= en the Request URI does not change. In this case, the index should be incre= ased (1->2) and not extended (1 -> 1.1) as when forking is executed
- = ;         to be able to distinguish this identity from the= normal diverting identity, you could use the "rc" hi-target-param to refer= to the normal History-Info entry for the diversion and link both. With thi= s mechanism, at the interworking you could find the last diverting identity= as described in 29.163 and then search for the entry having a "rc" paramet= er having a value equals to the current (last diverting address) hi-entry i= ndex value.
-          finally, you could imagine a dedi= cated cause URI parameter (different from those defined in RFC4458 for call= diversion service)
 
 
Best regards,
Marianne
 
<= span lang=3D"EN-US" style=3D"font-family: Tahoma, sans-serif; font-size: 10= pt;">De : = dispatch [mailto:dispatch-bounces@ietf.org] De la part de N WEINRONK
Envoy=C3= =A9 : mercredi 9= mars 2016 23:08
=C3=80 : michael.hammer@yaanatech.com;<= span class=3D"Apple-converted-space"> keith.= drage@nokia.com; dispatch@ietf.org
Objet : Re: [dispatch] draft-weinronk-dispatch-last-= diverting-line-id
 

 

Not sure I agree with the non-sequitur statement but lets move on.=

Let us explore the statement = that History-Info "should" work a little more:

 

Can yo= u explain how 1 entry can have a 'presentation' and a 'network asserted' id= entity that can be different - were you thinking of the hi-extension ?=

Just to add to this in the UK (I c= an only really comment on this) the specification of ETSI ISDN diversion se= rvices mandates that both the 'network asserted' and the 'present= ation' identities of the Diverting Party are passed between operator networ= ks on Diverted calls.

This all= ows 'transit' operators handling Carrier Pre-select Diverted calls to verif= y and bill the user. 

All= the documents I have seen be it 3GPP/IETF maps History-Info into Redi= recting Number - Redirecting Number does not have a screening indicator and= is used directly for display in ETSI ISDN.

In cases where the 'network asserted' identify is differ= ent from the 'presentation' identity it is not clear to me how the inf= ormation in the History-Info header can be 'network asserted'.

 

I do not think it is 'this diversion' that is different it is the= ability to consistently pass 'network asserted' and 'presentation' id= entities for Diversion information. 

 

Not su= re how STIR is related ? 

 

Thanks,

=

Nigel

 

 

 

----Origin= al message----
>From : michael.hammer@yaanatech.com
Date : 09= /03/2016 - 20:13 (GMTST)
To : = ;nweinronk@btinternet.com, keith.drage@nokia.com= , disp= atch@ietf.org
Subject : RE: RE: [dispatch] draft-weinronk-dispatch-l= ast-diverting-line-id

Nigel,
 
Your logic was a non-sequitor.
Like sayi= ng cats like milk, therefore don=E2=80=99t give chocolate to a dog. 
= The conclusion has nothing to do with cats and milk.
 
So, while suc= h logic is not conclusive for or against a separate header,
the burden of = proof for a separate header should lie on the one proposing a new header,
= when face with the existing of a header that =E2=80=9Cshould=E2=80=9D work.=   (the question at hand)
 
A separate header is warranted when = an existing header has the wrong semantics
and the existing syntax just wo= n=E2=80=99t work.  However, that doesn=E2=80=99t seem to be the case.<= /span>
 
If another implementation judges that the H-I header is a perfect = fit, then you won=E2=80=99t be looking there.
Some existing implementation= s just might be doing this already.
So, just want to be careful about will= y nilly adding new headers.
 
I would note that both the Route head= er and the H-I header can be =E2=80=9Cnetwork asserted=E2=80=9D.
So, what = makes this particular diversion different from H-I envisaged?
 
You = make it sound like it should be part of the STIR discussion, when you compa= re to P-Asserted-ID.
Have you looked into that WG?
=
 
________________________________
Michael Hammer
michael.hammer@y= aanatech.com
+1 408 202 9= 291

= =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentia= lity notice. This message is private and confidential. If you have received= this message in error, please notify us and remove it from your system.
&= nbsp;
From: N WEINRONK [mailto:nwein= ronk@btinternet.com] =
Sent: Wednesda= y, March 09, 2016 2:00 PM
To: Michael Hammer <michael.hammer@= yaanatech.com>; keith.drage@nokia.com; dispatch@ietf.org
Subject:<= span class=3D"Apple-converted-space"> Re: RE: [dispatch] draft-= weinronk-dispatch-last-diverting-line-id
 =

 

Thanks for your time.

 

Please= explain the negative consequences of a separate header ?

 

The only place I saw that this could have been placed in History-Info = was as an hi-extension because it is really a 'network asserted id' of= the hi-targeted-to-uri and this would place requirements on lots of f= unctions to search History-Info entries to remove this 'network asserted' i= dentity when required. 

T= o me this is the same as From / P-Asserted-Identity - the P-Asserted_Identi= ty was not place in the From header as a parameter - I guess it could have = been.

I think the same argumen= t applies here in keeping the 'network asserted identity' and the 'presenta= tion identity' for the same user apart in the signalling.

Note: This also matches the ISUP implementation= - a separate distinct parameter.

I see nothing illogical in a separate header.

Thanks,

Ni= gel

 

----Original message----
>From : michael.hammer@yaanatech.com=
Date : 09/03/2016 - 17:20 (GMTST)
To : nweinronk@btinternet.com, keith.dr= age@nokia.com, dispatch@ietf.org
Subject : RE: [dispatch] draft-weinronk-d= ispatch-last-diverting-line-id

There is a danger here that this purpose could be su= pported by two different headers
(a new header or an old header) with pote= ntial negative consequences.
 
Please show what prevents you from su= pporting this purpose with History-Info?
 
The argument that becaus= e A is supported by B, therefore C is not supported by B, is illogical.
&n= bsp;
________________________________
Michael Hammer
michael.hammer@yaanatech.com
+1 408 202 9291

=C2=A9 2016 Yaana Technologies, LLC. All Rights Reserve= d. Email confidentiality notice. This message is private and confidential. = If you have received this message in error, please notify us and remove it = from your system.
 
From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of&n= bsp;N WEINRONK
Sent: Wednesday, March 09, 2016 6:05 AM
To: keith.drage@noki= a.com; dispatch@ietf.org
Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line= -id
 

 

Thank you for your comments on this Internet Draft =E2=80=93 I will try = and answer your points.

Do you believe it is legacy from = the early ISDN definitions or do you believe it is new?

Neither it a consequence of the way ETSI ISDN w= as implemented in the UK in the 1990s that is still in use today =E2= =80=93 see below.

Note: I as= sume by early ISDN definitions you mean where ETSI ISDN was mapped to DASS = and I am not talking about this.

Can you explain where a = proposed UK requirement comes from that is not contained within the ETSI an= d ITU-T service definitions for the ISDN?

This comes from current implementations in the UK based on NI= CC ND1007.

In UK ISUP there = is a parameter optional in the IAM =E2=80=93 Last Diverted Line Identity in= additional to the ITU/ETSI parameter Redirecting Number.=

There are times when these parameters are bot= h present and can hold different information.

You could see this as being analogous to FROM and P-Asser= ted-Id headers in SIP with the Last Diverted Line Identity parameter being = the =E2=80=98network asserted identity=E2=80=99 used by networks other that= the network diverting the call to verify service and the Redirecting Numbe= r parameter being the =E2=80=98presentation number=E2=80=99.

The cases I am aware of where these parame= ters can hold different information come from ETSI ISDN diversion scenarios= =E2=80=93 Call Forwarding Unconditional / Call Forwarding Busy / Call Forw= arding No Reply / Call Deflection / Partial Rerouting.

For Partial Rerouting the Last Diverted Line Ide= ntity parameter is based on the =E2=80=98administration number=E2=80=99 as = understood by the network doing the diversion and the network doing the ver= ification and billing for these calls. The Redirecting Number parameter is = set from the lastReroutingNr from the ASN.1 the private network sets in the= Q.931 SETUP message =E2=80=93 these can/will be different.

For Call Forwarding Unconditional / Call Fo= rwarding Busy / Call Forwarding No Reply / Call Deflection the Last Diverte= d Line Identity parameter is based on the =E2=80=98administration number=E2= =80=99 as understood by the network doing the diversion and the network doi= ng the verification and billing for these calls. The Redirecting Number par= ameter is set to the Called Party Number used to reach the diverting party = =E2=80=93 these are not necessarily the same.

I=E2=80=99d= also note that I believe if this is required then an addition to the Histo= ry-Info header field would be more appropriate.

We (myself and the UK NICC SIP Task Group) did consider= using the History-Info header for this but as the mappings are already def= ined from Redirecting Number parameter to History-Info by the IETF / ETSI /= ITU it was felt this would be confusing and make the mappings complicated.=

Also I would expect this he= ader to (like the Last Diverted Line Identity parameter in UK ISUP) be limi= ted in where it can be sent ie. between network operators and not to end us= ers again making use of History-Info more complicated.

Nigel Weinronk

 

----Orig= inal message----
>From : <= /span>keith.drage@nokia.com
Date : 09/03/2016 - 0= 2:47 (GMTST)
To : Phil.Hutchison@virginmedia.co.uk, dispatch@ietf.org
Subject : Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-i= d

=
From: dispa= tch [mailto:dispatch-bounces@ietf.org] On Behalf Of EXT Hutchison, Phil
Sent: 04 March 2016 08:20
To= : 'dis= patch@ietf.org'
Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id
 
 
I believe that this is required in the UK, and therefore would like to = see the draft accepted.
 =
Regards
 
Phil
~~~~~~~~~~~~~~~~~=
Phil Hutchison=
Liberty Global CAO - Co= mmunications Architecture
Mobile +447775 938827 |= Soft Client +44(0)3703 900464 | Email phil.hutchison= @virginmedia.co.uk
Meet Me Conference:&nbs= p;0808 1074444  [+44 1723204444] PIN 1256450#<= /span>
Visit www.= virginmedia.co.uk for more information, and more fun
Save paper - do you really need to print this email?=
 
=


-------------------= -------------------------------------------------
Save Paper - Do you re= ally need to print this e-mail?

Visit&n= bsp;www.virginmedia.com for more information, and more fun.=

This email an= d any attachments are or may be confidential and legally privileged
and = are sent solely for the attention of the addressee(s). If you have received= this
email in error, please delete it from your system: its use, disclo= sure or copying is
unauthorised. Statements and opinions expressed in th= is email may not represent
those of Virgin Media. Any representations or= commitments in this email are
subject to contract. 

Registered office: Media House, Bartley Wood B= usiness Park, Hook, Hampshire, RG27 9UP
Registered in England and Wales = with number 2591237

 <= /div>
 
 
 
 
 
________________________________________________________________________= _________________________________________________ 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.


_______________________________________________
dispatch mailing list
dispatc= h@ietf.org
https://www.ietf.org/mailman/listinfo/= dispatch


<= p>

------=_Part_2448_29831600.1457942817989-- ------=_Part_2449_9394508.1457942817990-- From nobody Mon Mar 14 11:49:30 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F04512D553 for ; Mon, 14 Mar 2016 11:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VhK54QUvGhv4 for ; Mon, 14 Mar 2016 11:49:27 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 6C92212D6FA for ; Mon, 14 Mar 2016 11:49:27 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id r187so140886127oih.3 for ; Mon, 14 Mar 2016 11:49:27 -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; bh=pROO/Dfo3+OVJD9TG6Su7pX1631FwjMQTHmlYMbS4nI=; b=nFDR/HgnJX6NXYGs7NjHTbyqjXr4G3cvejUXraJ1PoActBSX7YFf9UYHKxG3A8L6wn qDFhnajnR5Ul+4SBamuWbrEVfa/jMZnrl0VXDPJ0NZOQ+LFN/glKbFI72SZk0Dik9dKk eawYHzeI38Bj83SErt8nMEvc+j5pJYZ1Qkn9YhsW743RAPvrZX7kwl0MtwfNFCoM68PM NSn9jRTI/H6NuBm0aosSH6or6c/tXx/y/ac0vUEp7IC3jADFiUs5qfxItb+qiEiD1Akg DdmVCVEg/wDQnza8WCTvdu0OVCylXxGv3favs7dmSDa3UlceRhbJgXZpTXwFuLb6oFem PKoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=pROO/Dfo3+OVJD9TG6Su7pX1631FwjMQTHmlYMbS4nI=; b=WoU34kjqH2XRAdieuJwp5+ecErlDmVV5QWGDL6MpG2GAUaiBNeuvjoxA/OwRQ0PjT+ 4yglFmz8RQG3Xsrxjxgy9eNLDmBdqVcsHxNyLhHvSj9O8a35xmKsDoxS635bRlUPEWz/ uWzlMcqXlih5FxW7C0liA0DghkbAfcWnzQSk3+8sdP2b4FFEdn28mQXJ67Oa/0ZKircH NQN418Ea0gRPUkaQtWpePZyz5nCCS9xqVf6cEV3Udow9ZWyiQHcDM6Nt0UbT9TENjSbc KhNfsC/msnkdhHg0Xh5iVTTlF8XLMb8xAwjN+mEkQXbilMGGUPo6SM389V6FMkjHrLE4 213g== X-Gm-Message-State: AD7BkJJmpqoah4R6q84Gw1NIPJYuPsprSvM52rNU/nO173xr9wTQk4C0H+rsPAx/D0GbSk+7NWITAXXeftMV1g== MIME-Version: 1.0 X-Received: by 10.202.77.67 with SMTP id a64mr12492291oib.123.1457981366728; Mon, 14 Mar 2016 11:49:26 -0700 (PDT) Received: by 10.157.38.100 with HTTP; Mon, 14 Mar 2016 11:49:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 Mar 2016 13:49:26 -0500 Message-ID: From: Mary Barnes To: Victor Pascual Avila Content-Type: multipart/alternative; boundary=001a1134e92a73ffa1052e06bd68 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Reminder: Deadlines for IETF-95 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 18:49:29 -0000 --001a1134e92a73ffa1052e06bd68 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry about that - I'm late getting that material posted. I'll update the wiki shortly, but the following topics will be discussed in BA: 1) Peterson/Housley security proposal (should consider that in conjunction with Alan's OSRTP draft): https://mailarchive.ietf.org/arch/msg/dispatch/oo07CgmvMHQ3qBGbzDCDCJ3T3Q4 2) https://datatracker.ietf.org/doc/draft-holmberg-dispatch-mcptt-rp-namespace= / 3) https://datatracker.ietf.org/doc/draft-weinronk-dispatch-last-diverting-lin= e-id/ The draft agenda will be submitted shortly. Regards, Mary. On Fri, Mar 11, 2016 at 3:50 AM, Victor Pascual Avila < victor.pascual.avila@gmail.com> wrote: > Where could I find the dispatched topics for IETF95? > > Thank you in advance, > -Victor > > On Wed, Feb 10, 2016 at 2:54 PM, Mary Barnes > wrote: > > Hi all, > > > > Just a reminder of the DISPATCH WG deadlines for IETF-95: > > https://trac.tools.ietf.org/wg/dispatch/trac/wiki > > > > February 22, 2016. Cutoff date to notify the chairs/DISPATCH WG of plan= s > to > > submit a proposal. > > > > February 29, 2016. Cutoff for charter proposals for topics. > > > > March 7, 2016. Announcement of topics that have been dispatched for > IETF-95. > > > > March 21, 2016. Draft deadline. > > > > > > Regards, > > Mary > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > -- > Victor Pascual =C3=81vila > --001a1134e92a73ffa1052e06bd68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry about that - I'm late getting that material post= ed.=C2=A0 I'll update the wiki shortly, but the following topics will b= e discussed in BA:

1) Pe= terson/Housley security proposal (should consider that in conjunction with = Alan's OSRTP draft):



The draft agenda will be submitte= d shortly.=C2=A0

Regard= s,
Mary.


On Fri, Mar 1= 1, 2016 at 3:50 AM, Victor Pascual Avila <victor.pascual.avil= a@gmail.com> wrote:
Where c= ould I find the dispatched topics for IETF95?

Thank you in advance,
-Victor

On Wed, Feb 10, 2016 at 2:54 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
> Hi all,
>
> Just a reminder of the DISPATCH WG deadlines for IETF-95:
> https://trac.tools.ietf.org/wg/dispatch/trac/w= iki
>
> February 22, 2016. Cutoff date to notify the chairs/DISPATCH WG of pla= ns to
> submit a proposal.
>
> February 29, 2016. Cutoff for charter proposals for topics.
>
> March 7, 2016. Announcement of topics that have been dispatched for IE= TF-95.
>
> March 21, 2016. Draft deadline.
>
>
> Regards,
> Mary
>
> __________________= _____________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>



--
Victor Pascual =C3=81vila

--001a1134e92a73ffa1052e06bd68-- From nobody Mon Mar 14 20:15:33 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCAA12D7B1 for ; Mon, 14 Mar 2016 20:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.534 X-Spam-Level: X-Spam-Status: No, score=-0.534 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 nQQ0AOkc4Fze for ; Mon, 14 Mar 2016 20:15:30 -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 7C89112D5C8 for ; Mon, 14 Mar 2016 20:15:30 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-12v.sys.comcast.net with comcast id W3FR1s0052LrikM013FVkK; Tue, 15 Mar 2016 03:15:29 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-12v.sys.comcast.net with comcast id W3FU1s00K1nMCLR013FVPj; Tue, 15 Mar 2016 03:15:29 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u2F3FSiZ030071; Mon, 14 Mar 2016 23:15:28 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u2F3FRTg030063; Mon, 14 Mar 2016 23:15:27 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: nweinronk@btinternet.com In-Reply-To: <30488691.40732.1455810861085.JavaMail.defaultUser@defaultHost> (nweinronk@btinternet.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 14 Mar 2016 23:15:27 -0400 Message-ID: <87mvq0ctyo.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458011729; bh=R+M0zB8T7aMzy8BAPZmZuYt8MsaKKAQRUzSFOEi5TQg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=rGc1zumlMRKkaVR7estQbbvhLUQwbeTsVf64tYDr5ODjb49Ck7E6xz7+kxcJAjstX ddDvtsHbuLR7yQJUMJYU23lKs7hrrptZWHpQeunMowPB18tdxg180cmRp3IUGYX6f/ tERLsvl2ZDhOdcQ/q0N5Bd84ay7diA4Sw+Z96PjmNDromiNHAZUuGRuL85nzVV2QN3 ihyZu1/kBvcnVkK70YI+FJGi/V9XTnIntjOVyUiFIRvt7B4phym6kpVA5eN5rbGm5i llvw3usfb5CwWQWGMIIhMAPMc/mqej6KCEWcxKAcjp1bCoFJDZV0CQFTiIQgfcv6Lx VauYV9XnBK6TQ== Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] New Version Notification for draft-weinronk-last-diverting-line-identity-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 03:15:32 -0000 N WEINRONK writes: > I have resubmitted this draft under the dispatch working group as: > > https://datatracker.ietf.org/doc/draft-weinronk-dispatch-last-diverting-line-id/ Section 6.1 says: priv-value = "ldli" You want to say: priv-value =/ "ldli" which adds an alternative to priv-value. Dale From nobody Tue Mar 15 00:04:51 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7229412D51E for ; Tue, 15 Mar 2016 00:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btinternet.com 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 SOtAJWgz9YZs for ; Tue, 15 Mar 2016 00:04:48 -0700 (PDT) Received: from rgout0503.bt.lon5.cpcloud.co.uk (rgout0503.bt.lon5.cpcloud.co.uk [65.20.0.224]) by ietfa.amsl.com (Postfix) with ESMTP id 2897C12D7B8 for ; Tue, 15 Mar 2016 00:04:48 -0700 (PDT) X-OWM-Source-IP: 10.110.13.1 () X-OWM-Env-Sender: nweinronk@btinternet.com X-CTCH-RefID: str=0001.0A090201.56E7B402.002B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-Junkmail-Premium-Raw: score=11/50, refid=2.7.2:2016.3.14.174816:17:11.486, ip=, rules=__HAS_FROM, __PHISH_FROM2, __FRAUD_WEBMAIL_FROM, FROM_NAME_ALLCAPS, __HAS_REPLYTO, __FRAUD_WEBMAIL_REPLYTO, __TO_MALFORMED_2, __TO_NO_NAME, __HAS_MSGID, __SANE_MSGID, INVALID_MSGID_NO_FQDN, __IN_REP_TO, __FRAUD_SUBJ_A, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, CT_TEXT_PLAIN_UTF8_CAPS, __CTE, __HAS_X_PRIORITY, __REPLYTO_SAMEAS_FROM_ADDY, __REPLYTO_SAMEAS_FROM_ACC, __REPLYTO_SAMEAS_FROM_DOMAIN, __ANY_URI, __HTTPS_URI, __URI_WITH_PATH, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __CP_URI_IN_BODY, __SUBJ_ALPHA_NEGATE, __URI_IN_BODY, __FORWARDED_MSG, BODY_SIZE_600_699, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, __PHISH_FROM, __SINGLE_URI_TEXT, SINGLE_URI_IN_BODY, __PHISH_SPEAR_STRUCTURE_1, BODY_SIZE_1000_LESS, BODY_SIZE_2000_LESS, PRIORITY_NO_NAME, __PHISH_SPEAR_STRUCTURE_2, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-CTCH-Spam: Unknown Received: from webmail09.bt.ext.cpcloud.co.uk (10.110.13.1) by rgout05.bt.lon5.cpcloud.co.uk (8.6.122.06) (authenticated as nweinronk@btinternet.com) id 56D82BD3015784F6; Tue, 15 Mar 2016 07:04:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1458025472; bh=Qmua8v6UwZv3DDO51fzVslc9GXgKI832dCuLJCPOCXA=; h=Date:From:Reply-To:To:Cc:Message-ID:In-Reply-To:References:Subject:MIME-Version; b=HUpeRvJEI2LPQGIek932PZEza2QQ/BdZ4D5L34ER0NRavLrgbQM/59+62I8kQ8lOyrZoFT18e+ZJcUBlpSCfZgVR1BBKm17nMtf08dXg9Gmwm+4MFCwgzI3WVSreVBlZ/FTgQxX3uL0ni1LFFzgXI0agZFFuGphKuETrzV7L7Os= Date: Tue, 15 Mar 2016 07:04:34 +0000 (GMT) From: N WEINRONK To: worley@ariadne.com Message-ID: <23443319.1306.1458025474316.JavaMail.defaultUser@defaultHost> In-Reply-To: <87mvq0ctyo.fsf@hobgoblin.ariadne.com> References: <87mvq0ctyo.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CP-REPLY-ALL-UID: 25649 X-CP-REPLY-ALL-UID: 25649 X-CP-REPLY-ALL-PATH: INBOX X-CP-REPLY-ALL-PATH: INBOX Importance: 3 (Normal) X-Priority: 3 (Normal) X-Client-IP: IPv4[86.145.180.157] Epoch[1458025474303] Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] New Version Notification for draft-weinronk-last-diverting-line-identity-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nweinronk@btinternet.com List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 07:04:50 -0000 Thank you for that - and the comment which does clarify what I am trying to achieve. Nigel ----Original message---- >From : worley@ariadne.com Date : 15/03/2016 - 03:15 (GMTST) To : nweinronk@btinternet.com Cc : dispatch@ietf.org Subject : Re: [dispatch] New Version Notification for draft-weinronk-last-diverting-line-identity-00.txt N WEINRONK writes: > I have resubmitted this draft under the dispatch working group as: > > https://datatracker.ietf.org/doc/draft-weinronk-dispatch-last-diverting-line-id/ Section 6.1 says: priv-value = "ldli" You want to say: priv-value =/ "ldli" which adds an alternative to priv-value. Dale From nobody Sat Mar 19 09:34:16 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865AC12D8BE for ; Thu, 17 Mar 2016 12:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru 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 QlrJwaDc1LuE for ; Thu, 17 Mar 2016 12:05:39 -0700 (PDT) Received: from forward18m.cmail.yandex.net (forward18m.cmail.yandex.net [IPv6:2a02:6b8:b030::9f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B80012D758 for ; Thu, 17 Mar 2016 12:04:30 -0700 (PDT) Received: from web28m.yandex.ru (web28m.yandex.ru [37.140.138.119]) by forward18m.cmail.yandex.net (Yandex) with ESMTP id 7D5C421958 for ; Thu, 17 Mar 2016 22:04:27 +0300 (MSK) Received: from web28m.yandex.ru (localhost [127.0.0.1]) by web28m.yandex.ru (Yandex) with ESMTP id F011F2A19E2; Thu, 17 Mar 2016 22:04:26 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1458241467; bh=DxmCIiZBSDfZRWqFLLFyquB2edBQly2+5Qas2F/xZ2Y=; h=From:To:Subject:Date; b=gLRg5yWRDCesZAAEe3774AG3Pwbc0oSmgxG+y1ZPtv+9QAhIRJ8UkB1ViSbsxF7K4 5a+7kEcZhPTf1bTLRSop+PVu8+PFGZObbSR98BvzIj4pk7UTTuNTqJxeHENs/Vf6KL oLZQi0M3QWkfUsqUbtt6IBfDs90afs8beLtO8hyA= Received: by web28m.yandex.ru with HTTP; Thu, 17 Mar 2016 22:04:26 +0300 From: =?koi8-r?B?9NfF0sXUyc4g4c7Uz84g88XSx8XF18ne?= To: DISPATCH list MIME-Version: 1.0 Message-Id: <1197661458241466@web28m.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 18 Mar 2016 00:04:26 +0500 Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: X-Mailman-Approved-At: Sat, 19 Mar 2016 09:34:15 -0700 Subject: [dispatch] My Drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 19:05:42 -0000 Hello All, Recently I've updated my I-Ds. Note: I used my other e-mail in I-Ds. I read both. draft-tveretin-dispatch-l2tp-sdp-01: Changed proposed status to INFORMATIONAL, and separated normative and informative references. I believe that the I-D should get dispatch'ed to mmusic. Or launch a new WG or BOF to discuss tunnelling using SIP. Someone might argue that Session Initiation Protocol is not to initiate sessions. :) draft-tveretin-dispatch-remote-02: I believe that the I-D belongs to sipcore, as it defines new methods. Finally, I did some examples. Regards, Anton. From nobody Mon Mar 21 07:55:32 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1166612D50E for ; Mon, 21 Mar 2016 07:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 lzaRFukYiXkm for ; Mon, 21 Mar 2016 07:55:29 -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 AA48012D0CF for ; Mon, 21 Mar 2016 07:55:29 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-12v.sys.comcast.net with comcast id YetV1s0032PT3Qt01evU8G; Mon, 21 Mar 2016 14:55:28 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-14v.sys.comcast.net with comcast id YevU1s0091nMCLR01evUDs; Mon, 21 Mar 2016 14:55:28 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u2LEtRvq011088; Mon, 21 Mar 2016 10:55:27 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u2LEtRWh011085; Mon, 21 Mar 2016 10:55:27 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: =?utf-8?B?0KLQstC10YDQtdGC0LjQvSDQkNC90YLQvtC9INCh0LXRgNCz0LXQtdCy0Lg=?= =?utf-8?B?0Yc=?= In-Reply-To: <1197661458241466@web28m.yandex.ru> (tveretinas@yandex.ru) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 21 Mar 2016 10:55:27 -0400 Message-ID: <87a8lr6fts.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458572128; bh=vHedXziU6TTG5VtFEULWLL2zPqftL8iQSNpLthJEU34=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=vLeu18YO4O8jnwZikaKX6I5a+VIfdNyvNuYnKH5NIqN/gGKY1feWlewdOXymf+v/C kCH27jFnvYPBmLn6qn/Ub9h/60kz2xOD/8JL9cohTtqdyy5yUP0uUdIC6vwBzdhiAa Vcd5h3nKufwgWP5zJiQj3xgxCHG/Rmzc6g+cJ7IQtwgT6RuY/ij6g0r6qM6UxSNP9Q ZgV01J4DHCQU2ij9eyK4e2+8GyTNfTthBLzYRmgjQ1ktBZsNytWbhGUmA+8Sumra2f DYpF50S5AFxVHKZV+kTovu/+C5VrDhpx0Y9b2MmsPIAPte4pYZXExCQuzlTP12a9eD HQ/Azf9iMVCSw== Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] My Drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 14:55:31 -0000 writes: > draft-tveretin-dispatch-l2tp-sdp-01: > Changed proposed status to INFORMATIONAL, and separated normative and > informative references. > I believe that the I-D should get dispatch'ed to mmusic. Or launch a > new WG or BOF to discuss tunnelling using SIP. Someone might argue > that Session Initiation Protocol is not to initiate sessions. :) Of course, what you are proposing is an application/l2tp as a *media* type within a session. And so SIP can be used to set up an L2TP connection as part of its media. Section 1 contains: Alice switches to data mode, uses text chat, sends a file using Zmodem, and Bob receives it. Or Bob sends a file. Now Alice starts a PPP [RFC1661] session. To maintain connectivity with Bob, a tunnel (as of L2TP [RFC2661], PPTP [RFC2637], IPsec [RFC2401], GPRS Tunneling Protocol) is needed. The last thing is currently not standartised. This document is to fill the gap. I'm not sure what "the last thing" is; it appears to be "GPRS Tunneling Protocol", which is currently not standardized. But since this document is about L2TP, the sentence "This document is to fill the gap" is incorrect. There needs to be some discussion of the effect of re-INVITE, subsequent offer/answer cycles. I would expect (not knowing anything about L2TP) that if the tunnel specified by the last offer/answer cycle was still up, the presence of the same m= line in the current offer/answer cycle means that the tunnel is to be continued. OTOH, it may require that the tunnel send some sort of end-to-end check to ensure that the tunnel is working, and a teardown/reopen cycle if it is not. (This needs to be based on best current practices in L2TP.) Is there any need to carry L2TP authentication information in SDP? Is there practical demand for establishing tunnels as part of the media? > draft-tveretin-dispatch-remote-02: > I believe that the I-D belongs to sipcore, as it defines new > methods. Finally, I did some examples. Does this proposal enable any behaviors that are not already possible (e.g., with RFC 3891, "Replaces")? Dale From nobody Mon Mar 21 12:24:52 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E359A12DA70 for ; Mon, 21 Mar 2016 12:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 bkEmCzZ3qRiy for ; Mon, 21 Mar 2016 12:24:49 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0844E12DA90 for ; Mon, 21 Mar 2016 12:24:13 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id BA2FF1803D4 for ; Mon, 21 Mar 2016 20:24:11 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 990E712005B for ; Mon, 21 Mar 2016 20:24:11 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0279.002; Mon, 21 Mar 2016 20:24:11 +0100 From: To: "dispatch@ietf.org" Thread-Topic: New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt Thread-Index: AdGDpY0Ib/ORDZABTLCpqAH3VVtD0w== Date: Mon, 21 Mar 2016 19:24:10 +0000 Message-ID: <21379_1458588251_56F04A5B_21379_5094_1_8B970F90C584EA4E97D5BAAC9172DBB81A970D51@OPEXCLILMA4.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.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 19:24:51 -0000 SGVsbG8sDQoNClBsZWFzZSBmaW5kIGhlcmVhZnRlciBhIG5ldyBJbnRlcm5ldC1EcmFmdCAgIlAt U2VydmVkLVVzZXIgSGVhZGVyIEZpZWxkIFBhcmFtZXRlciBmb3IgT3JpZ2luYXRpbmcgQ0RJViBz ZXNzaW9uIGNhc2UgaW4gU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIi4NClRoZSBw dXJwb3NlIG9mIHRoZSBkcmFmdCBpcyB0byByZWdpc3RlciBhIG5ldyBTSVAgcGFyYW1ldGVyIGZv ciB0aGUgUC1TZXJ2ZWQtVXNlciBoZWFkZXIgZmllbGQgZGVmaW5lZCBhcyBwZXIgUkZDNTUwMi4N Cg0KQWJzdHJhY3Q6DQogICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIG5ldyBTZXNzaW9u IEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgUC0NCiAgIFNlcnZlZC1Vc2VyIGhlYWRlciBmaWVs ZCBwYXJhbWV0ZXIsICJvcmlnLWNkaXYtcGFyYW0iLCB3aGljaCBkZWZpbmVzDQogICB0aGUgc2Vz c2lvbiBjYXNlIHVzZWQgYnkgYSBwcm94eSB3aGVuIGhhbmRsaW5nIGFuIG9yaWdpbmF0aW5nIHNl c3Npb24NCiAgIGFmdGVyIENhbGwgRGl2ZXJzaW9uIChDRElWKSBzZXJ2aWNlcyBoYXMgYmVlbiBp bnZva2VkIGZvciB0aGUgc2VydmVkDQogICB1c2VyLiAgVGhlIFAtU2VydmVkLVVzZXIgaGVhZGVy IGZpZWxkIGlzIGRlZmluZWQgaW4gW1JGQzU1MDJdLiAgVGhlDQogICBQLVNlcnZlZC1Vc2VyIGhl YWRlciBmaWVsZCBjb252ZXlzIHRoZSBpZGVudGl0eSBvZiB0aGUgc2VydmVkIHVzZXINCiAgIGFu ZCB0aGUgc2Vzc2lvbiBjYXNlIHRoYXQgYXBwbGllcyB0byB0aGlzIHBhcnRpY3VsYXIgY29tbXVu aWNhdGlvbg0KICAgc2Vzc2lvbiBhbmQgYXBwbGljYXRpb24gaW52b2NhdGlvbi4NCiAgIFRoaXMg ZG9jdW1lbnQgdXBkYXRlcyBbUkZDNTUwMl0gaW4gb3JkZXIgdG8gYWRkIHRoZSBvcmlnaW5hdGlu ZyBhZnRlcg0KICAgQ0RJViBzZXNzaW9uIGNhc2UuDQoNClRoZSBkcmFmdCBjYW4gYmUgZm91bmQg aW4gOg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1tb2hhbGktZGlzcGF0Y2gtb3JpZ2luYXRpbmctY2Rpdi1wYXJhbWV0ZXItMDAudHh0 DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt bW9oYWxpLWRpc3BhdGNoLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVyLw0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tb2hhbGktZGlzcGF0Y2gtb3Jp Z2luYXRpbmctY2Rpdi1wYXJhbWV0ZXItMDANCg0KQmVzdCBSZWdhcmRzLA0KTWFyaWFubmUgTW9o YWxpDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50 IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVl cyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl ZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Mon Mar 21 15:21:00 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D88412D0DF for ; Mon, 21 Mar 2016 15:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 Wb1Z6a6ycvWN for ; Mon, 21 Mar 2016 15:20:57 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 DECF812D0BF for ; Mon, 21 Mar 2016 15:20:56 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.11/8.16.0.11) with SMTP id u2LMG03A004223; Mon, 21 Mar 2016 18:20:49 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 21s338ysw5-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 Mar 2016 18:20:48 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.230]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Mon, 21 Mar 2016 18:20:48 -0400 From: "Peterson, Jon" To: Ben Campbell , Mary Barnes Thread-Topic: [dispatch] Reminder: Deadlines for IETF-95 Thread-Index: AQHRZAqTJ+2zqOwoS02MQXPireE1/p8n/OoAgBuhi4CAIOb7gA== Date: Mon, 21 Mar 2016 22:20:48 +0000 Message-ID: References: <8119825D-F91F-4494-AE59-39E3956B02F1@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-originating-ip: [192.168.128.54] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-21_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603210351 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Reminder: Deadlines for IETF-95 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 22:20:59 -0000 This is our submission on media confidentiality negotiated via SIP. If there's interest, we could discuss at DISPATCH. https://www.ietf.org/id/draft-peterson-dispatch-rtpsec-00.txt Jon Peterson Neustar, Inc. On 2/29/16, 3:53 PM, "Peterson, Jon" wrote: > >I just wanted to confirm that Ben here is correct. This idea came out of a >discussion in Yokohama about identifying the best practices for media >security when setting up sessions with SIP, and in particular the glue >that binds security in SIP to SDP and to RTP. This would invoke things >like STIR, and would also potentially nod to more opportunistic approaches >like those outlined in Alan's draft, as media confidentiality is one of >the more important security properties in this post-PERPASS world of ours. > >So, we expect to have a draft before the deadline - happy to discuss the >general topic here in the meantime if there's interest. > >Jon Peterson >Neustar, Inc. > >On 2/11/16, 5:56 PM, "dispatch on behalf of Ben Campbell" > wrote: > >>Hi, >> >>I understand that Jon, Ekr, Richard, and Russ plan to submit a draft on >>security recommendations for point-to-point, SIP-signaled RTP in time >>for Buenos Aires. While I would be pleasantly surprised if the >>discussion is far enough along by then for a charter proposal, I think >>discussion in DISPATCH would be worthwhile. >> >>So, please consider this notice of their intent to propose a discussion >>topic, on their behalf. >> >>Thanks! >> >>Ben. >> >>On 10 Feb 2016, at 7:54, Mary Barnes wrote: >> >>> Hi all, >>> >>> Just a reminder of the DISPATCH WG deadlines for IETF-95: >>> https://trac.tools.ietf.org/wg/dispatch/trac/wiki >>> >>> >>> - February 22, 2016. Cutoff date to notify the chairs/DISPATCH WG of >>> plans to submit a proposal. >>> >>> >>> - February 29, 2016. Cutoff for charter proposals for topics. >>> >>> >>> - March 7, 2016. Announcement of topics that have been dispatched for >>> IETF-95. >>> >>> >>> - March 21, 2016. Draft deadline. >>> >>> >>> Regards, >>> Mary >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >>_______________________________________________ >>dispatch mailing list >>dispatch@ietf.org >>https://www.ietf.org/mailman/listinfo/dispatch > From nobody Mon Mar 21 15:27:21 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4870C12D127 for ; Mon, 21 Mar 2016 15:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 6e92UDmsTQyc for ; Mon, 21 Mar 2016 15:27:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 881AB12D104 for ; Mon, 21 Mar 2016 15:27:14 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2LMRAGp070613 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 21 Mar 2016 17:27:11 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Peterson, Jon" Date: Mon, 21 Mar 2016 17:27:11 -0500 Message-ID: <8BF3C829-2DD0-4305-8098-1BD1F23FDEDC@nostrum.com> In-Reply-To: References: <8119825D-F91F-4494-AE59-39E3956B02F1@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Reminder: Deadlines for IETF-95 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 22:27:20 -0000 I'm interested ;-) Seriously, though, there was already issue expressed for the subject back when we pre-announced it. Ben. On 21 Mar 2016, at 17:20, Peterson, Jon wrote: > This is our submission on media confidentiality negotiated via SIP. If > there's interest, we could discuss at DISPATCH. > > https://www.ietf.org/id/draft-peterson-dispatch-rtpsec-00.txt > > > Jon Peterson > Neustar, Inc. > > > > On 2/29/16, 3:53 PM, "Peterson, Jon" wrote: > >> >> I just wanted to confirm that Ben here is correct. This idea came out >> of a >> discussion in Yokohama about identifying the best practices for media >> security when setting up sessions with SIP, and in particular the >> glue >> that binds security in SIP to SDP and to RTP. This would invoke >> things >> like STIR, and would also potentially nod to more opportunistic >> approaches >> like those outlined in Alan's draft, as media confidentiality is one >> of >> the more important security properties in this post-PERPASS world of >> ours. >> >> So, we expect to have a draft before the deadline - happy to discuss >> the >> general topic here in the meantime if there's interest. >> >> Jon Peterson >> Neustar, Inc. >> >> On 2/11/16, 5:56 PM, "dispatch on behalf of Ben Campbell" >> wrote: >> >>> Hi, >>> >>> I understand that Jon, Ekr, Richard, and Russ plan to submit a draft >>> on >>> security recommendations for point-to-point, SIP-signaled RTP in >>> time >>> for Buenos Aires. While I would be pleasantly surprised if the >>> discussion is far enough along by then for a charter proposal, I >>> think >>> discussion in DISPATCH would be worthwhile. >>> >>> So, please consider this notice of their intent to propose a >>> discussion >>> topic, on their behalf. >>> >>> Thanks! >>> >>> Ben. >>> >>> On 10 Feb 2016, at 7:54, Mary Barnes wrote: >>> >>>> Hi all, >>>> >>>> Just a reminder of the DISPATCH WG deadlines for IETF-95: >>>> https://trac.tools.ietf.org/wg/dispatch/trac/wiki >>>> >>>> >>>> - February 22, 2016. Cutoff date to notify the chairs/DISPATCH WG >>>> of >>>> plans to submit a proposal. >>>> >>>> >>>> - February 29, 2016. Cutoff for charter proposals for topics. >>>> >>>> >>>> - March 7, 2016. Announcement of topics that have been dispatched >>>> for >>>> IETF-95. >>>> >>>> >>>> - March 21, 2016. Draft deadline. >>>> >>>> >>>> Regards, >>>> Mary >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> From nobody Tue Mar 22 11:31:21 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648E012D78F for ; Tue, 22 Mar 2016 11:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 8MRnScHdBCdl for ; Tue, 22 Mar 2016 11:31:19 -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 D8F9112D132 for ; Tue, 22 Mar 2016 11:31:18 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-08v.sys.comcast.net with comcast id Z6WJ1s0042Fh1PH016XHbC; Tue, 22 Mar 2016 18:31:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-08v.sys.comcast.net with comcast id Z6XH1s00E3KdFy1016XHEq; Tue, 22 Mar 2016 18:31:17 +0000 To: dispatch@ietf.org References: <21379_1458588251_56F04A5B_21379_5094_1_8B970F90C584EA4E97D5BAAC9172DBB81A970D51@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Paul Kyzivat Message-ID: <56F18F74.9050504@alum.mit.edu> Date: Tue, 22 Mar 2016 14:31:16 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <21379_1458588251_56F04A5B_21379_5094_1_8B970F90C584EA4E97D5BAAC9172DBB81A970D51@OPEXCLILMA4.corporate.adroot.infra.ftgroup> 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=1458671477; bh=Zri5DJtidNkVFGNOyjAdvKV/EPWr+sSx9RaJeB3xBrg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=hWLHZpA74n4zHnt7s1BKo3u7YgXbRpecvKSuA1K4N0VWLUWeyGQ44cGXjH+KB3TM2 vqJBjsJcPgjVZKdpnrlcVF56nd3xu9eW+M7P46OYBKAyOXakswQ8SEjLmzbq/R4mhL oc19OfNfFkn9mTRHqP0NyKgDSAB3YPfEJ273Lv6d0RDEEEXVjrXMcaUHlIMG6sCqUG GlHmNtAHU8xrKeLh7nfPbOuHuk3bBndpDjBCbG5I3PJ1mBoQr5UCofs8UxArt27p1C IZfOtW5xCbzsFGuKzrH0rTcdwDHdKUS+DqV+Uqo3SKinofW1RMLfZ1XKoDpm90pzpT VwlJ42YAREr/w== Archived-At: Subject: Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 18:31:20 -0000 Marianne, Thank you. This draft is a huge improvement over the prior proposal for this purpose! I don't have a problem with this approach. The draft seems in reasonable shape. (I didn't read it for nits, as doing that seems premature.) One thing I noticed, which is really an issue with rfc5502: The P-Served-User header field doesn't seem to have the usual provision of headers like this for comma-separated repetition. And there is no mention pro or con regarding whether this header field can be repeated. Since it can already have both orig and term options, that presumably can coexist, I guess it can be repeated, but not using comma. Is that how it is being used in practice? It would be wise to clarify the ways in which this header field may be repeated. (E.g., every usage must have a distinct value of sessioncase-param.) And if multiple values separated by comma are being used in practice then the syntax ought to be corrected to allow that. Thanks, Paul On 3/21/16 3:24 PM, marianne.mohali@orange.com wrote: > Hello, > > Please find hereafter a new Internet-Draft "P-Served-User Header Field Parameter for Originating CDIV session case in Session Initiation Protocol (SIP)". > The purpose of the draft is to register a new SIP parameter for the P-Served-User header field defined as per RFC5502. > > Abstract: > This specification defines a new Session Initiation Protocol (SIP) P- > Served-User header field parameter, "orig-cdiv-param", which defines > the session case used by a proxy when handling an originating session > after Call Diversion (CDIV) services has been invoked for the served > user. The P-Served-User header field is defined in [RFC5502]. The > P-Served-User header field conveys the identity of the served user > and the session case that applies to this particular communication > session and application invocation. > This document updates [RFC5502] in order to add the originating after > CDIV session case. > > The draft can be found in : > URL: https://www.ietf.org/internet-drafts/draft-mohali-dispatch-originating-cdiv-parameter-00.txt > Status: https://datatracker.ietf.org/doc/draft-mohali-dispatch-originating-cdiv-parameter/ > Htmlized: https://tools.ietf.org/html/draft-mohali-dispatch-originating-cdiv-parameter-00 > > Best 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. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Tue Mar 22 15:00:07 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0829112DA68; Tue, 22 Mar 2016 15:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 0NR9H0ysqHhR; Tue, 22 Mar 2016 15:00:05 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6A67412DAAA; Tue, 22 Mar 2016 15:00:05 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2MM03qe089646 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 22 Mar 2016 17:00:04 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "The IETF" , DISPATCH Date: Tue, 22 Mar 2016 17:00:03 -0500 Message-ID: <8F0632C7-CFB4-4757-A35B-1ACB75E5E734@nostrum.com> References: <20160311210515.25419.67867.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-campbell-art-rfc5727-update@tools.ietf.org Subject: [dispatch] Fwd: New Version Notification for draft-campbell-art-rfc5727-update-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 22:00:07 -0000 Hi, We've submitted version 03 in response to last call discussion and the Gen-ART review. Thanks! Ben. Forwarded message: > From: internet-drafts@ietf.org > To: Barry Leiba , Ben Campbell > , Alissa Cooper , ALissa Cooper > > Subject: New Version Notification for > draft-campbell-art-rfc5727-update-03.txt > Date: Fri, 11 Mar 2016 13:05:15 -0800 > > > A new version of I-D, draft-campbell-art-rfc5727-update-03.txt > has been successfully submitted by Ben Campbell and posted to the > IETF repository. > > Name: draft-campbell-art-rfc5727-update > Revision: 03 > Title: DISPATCH-Style Working Groups and the SIP-Change Process > Document date: 2016-03-11 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-campbell-art-rfc5727-update-03.txt > Status: > https://datatracker.ietf.org/doc/draft-campbell-art-rfc5727-update/ > Htmlized: > https://tools.ietf.org/html/draft-campbell-art-rfc5727-update-03 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-campbell-art-rfc5727-update-03 > > Abstract: > RFC 5727 defined several processes for the former Real-time > Applications and Infrastructure (RAI) area. These processes > include > the evolution of the Session Initiation Protocol (SIP) and related > protocols, as well as the operation of the DISPATCH and SIPCORE > working groups. This document updates RFC 5727 to allow > flexibility > for the area and working group structure, while preserving the SIP- > change processes. It also generalizes the DISPATCH working group > processes so that they can be easily adopted by other working > groups. > > > > > 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. > > The IETF Secretariat > From nobody Tue Mar 22 15:44:44 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF1F12D0B4 for ; Tue, 22 Mar 2016 15:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 ANNLGKe87h7k for ; Tue, 22 Mar 2016 15:44:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9F23212D096 for ; Tue, 22 Mar 2016 15:44:41 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2MMidTx093473 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 22 Mar 2016 17:44:40 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Dawes, Peter, Vodafone Group" Date: Tue, 22 Mar 2016 17:44:39 -0500 Message-ID: <02EE1690-A9A5-4C4B-8E7F-B4A9D628B1F9@nostrum.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C89EE030@VOEXM31W.internal.vodafone.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C89EE030@VOEXM31W.internal.vodafone.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "dispatch-chairs@tools.ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] https://www.ietf.org/id/draft-dawes-sipcore-mediasec-parameter-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 22:44:43 -0000 Hi, The ADs and chairs discussed this offline, and we think that this might be a candidate for AD sponsorship. However, in my opinion as an ART AD, there are some issues that need to be discussed before going that route (and are probably relevant however this progresses: 2. The draft creates a "media security" sub-class of security mechanisms that are registered in a separate registry with a "specification-required" policy. The existing security mechanism registry has a policy of "RFC required". I think that's a reasonable policy, given the security implications of RFC 3329 extensions. In my opinion, this draft should get rid of the separate registry, and put any media-specific mechanism into the existing one. But failing that, the policy on this new registry should be no weaker than that of the existing one. ( If people think "RFC Required" is not the right policy for either registry, we can discuss that.) 3. The draft assumes that the first hop SIP proxy is also the first hop media-plane device, a la a p-cscf. This may be a reasonable assumption for IMS and IMS-like architectures, but it's not an assumption we want to encourage in general. This could be mitigated by stronger language scoping the work to IMS, and discouraging its use elsewhere. (This is designed to enable the IMS end-to-edge-agent security model, and should probably say so.) 3. There's a fair amount of work left. The security considerations seem inadequate, and there are sections that still have xml2rfc sample text. If we progress this, we should get targeted reviews from Gonzalo and/or Jari, as well as secdir. So it's only worth trying to progress this if the authors are willing put non-trivial additional work in on it. This is not an exhaustive list--I'm sure other issues will shake out if we move forward. But I think these are important for figuring out the strategy for progressing the work. Thanks! Ben. On 10 Feb 2016, at 5:32, Dawes, Peter, Vodafone Group wrote: > Hello All, > I would like to ask dispatch to (re-)consider the proposals in > https://datatracker.ietf.org/doc/draft-dawes-sipcore-mediasec-parameter/ > and how it might be progressed. One of the sipcore chairs has > indicated that this draft probably does not belong in sipcore and > dispatch did not make a detailed evaluation the first time it was > brought to the group. > > The most recent comments on the sipcore mailing list are > https://mailarchive.ietf.org/arch/msg/sipcore/mD1Qedh93ep9oVOxttIxKN7lIcg > and it might help to repeat part of what I said there about the new > header field parameter that is the reason for the draft: > > "...the header field parameter introduced by this draft originates > from 3GPP specifications and related procedures and header field > values are also described in 3GPP specifications. The purpose of this > draft is to name the header field parameter, give several illustrative > examples to make it clear how it is used, and set up an IANA registry > for existing and future values. The draft does not propose that IETF > defines any new security setup procedures, ciphering, integrity > protection etc." > > Thanks and regards, > Peter > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Mar 22 15:53:03 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E787F12DAF2; Tue, 22 Mar 2016 15:53:01 -0700 (PDT) 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 autolearn_force=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 Q7RNRmBS-mks; Tue, 22 Mar 2016 15:53:00 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 AE58812DAED; Tue, 22 Mar 2016 15:52:59 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A32FF509B5; Tue, 22 Mar 2016 18:52:58 -0400 (EDT) References: <20160321235553.10930.4801.idtracker@ietfa.amsl.com> To: ietf-smtp@ietf.org, dispatch@ietf.org From: Sean Leonard X-Forwarded-Message-Id: <20160321235553.10930.4801.idtracker@ietfa.amsl.com> Message-ID: <56F1CD23.2040002@seantek.com> Date: Tue, 22 Mar 2016 15:54:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160321235553.10930.4801.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 22:53:02 -0000 Greetings IETF-SMTP Gods and Denizens (and dispatch): Over the winter I worked on a new Internet-Draft that I would like to propose the IETF adopts: Regular Expressions for Internet Mail. The draft focuses on two identifiers: email addresses and Message-IDs. The purpose of this standard (proposed as a Best Current Practice) is to have *IETF-vetted* expressions that implementers and non-mail standards authors can plug-and-chug without futzing with trying to interpret 40 years of (occasionally conflicting and arcane) RFCs and implementation lore. There are many non-mail systems out there (read: nearly every web app, reservation system, customer database, etc. on Earth) that use or consume email addresses as identifiers, and their inability to accept the most obvious valid characters (like "+" or even "-"; I have used apps that do not even accept "-") is a great source of interoperability problems. (This document is also relevant to some other threads about the nature of email address identifiers in security artifacts such as certificates, PGP keys, and DNS records: anyone who is vouching for an email address ought to be sure that they are recording something that actually is a valid email address in the first place.) We should get this right now, before Unicode/EAI makes interoperability issues 50000x more expensive to correct. The document is not meant to modify the mail standards, but merely to reflect and track them as they are updated over time. As a first draft, the document is in rough shape and has extensive notes about issues that came up during R&D but have yet to be addressed. Significant areas that need adequate treatment include: 1. the impact of Unicode (EAI) on identifiers. 2. handling domain names, which comprise 50% of an email address, but perhaps 85% of the complexity when Unicode gets involved. 2. "deliverable email address" (complying with the modern SMTP infrastructure) vs. other kinds of email addresses (Internet Message Format, historic forms). 3. regular expression engines and grammars (i.e., which grammars to use, which are widely used and produce uniform results). 4. efficiency of the regular expressions. 5. different expressions for validation (testing), part extraction (capturing groups), decoding, encoding, and searching through text. 6. test vectors. Hopefully the adoption of this work as an IETF item, coupled with input from those with extensive experience (Thanks to John Levine, Pete Resnick, and others for taking initial questions and discussion on the topic.) Discussion welcome. Thanks. Sean -------- Forwarded Message -------- Subject: New Version Notification for draft-seantek-mail-regexen-00.txt Date: Mon, 21 Mar 2016 16:55:53 -0700 From: internet-drafts@ietf.org A new version of I-D, draft-seantek-mail-regexen-00.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-mail-regexen Revision: 00 Title: Regular Expressions for Internet Mail Document date: 2016-03-21 Group: Individual Submission Pages: 24 URL: https://www.ietf.org/internet-drafts/draft-seantek-mail-regexen-00.txt Status: https://datatracker.ietf.org/doc/draft-seantek-mail-regexen/ Htmlized: https://tools.ietf.org/html/draft-seantek-mail-regexen-00 Abstract: Internet Mail identifiers are used ubiquitously throughout computing systems as building blocks of online identity. Unfortunately, incomplete understandings of the syntaxes of these identifiers has led to interoperability problems and poor user experiences. Many users use specific characters in their addresses that are not properly accepted on various systems. This document prescribes normative regular expression (regex) patterns for all Internet- connected systems to use when validating or parsing Internet Mail identifiers, with special attention to regular expressions that work with popular languages and platforms. From nobody Tue Mar 22 23:49:49 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44D712D7E8 for ; Tue, 22 Mar 2016 23:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 aTqUeN9PELWv for ; Tue, 22 Mar 2016 23:49:46 -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 66A5312D562 for ; Tue, 22 Mar 2016 23:49:45 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-30-56f23ba87c53 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CB.89.16394.8AB32F65; Wed, 23 Mar 2016 07:46:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Wed, 23 Mar 2016 07:46:00 +0100 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt Thread-Index: AQHRhGkLzUOrLDCZ4kW4P8hV8CvBOp9mln93 Date: Wed, 23 Mar 2016 06:45:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F040EE@ESESSMB209.ericsson.se> References: <21379_1458588251_56F04A5B_21379_5094_1_8B970F90C584EA4E97D5BAAC9172DBB81A970D51@OPEXCLILMA4.corporate.adroot.infra.ftgroup>, <56F18F74.9050504@alum.mit.edu> In-Reply-To: <56F18F74.9050504@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_7594FB04B1934943A5C02806D1A2204B37F040EEESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbHdUrfd5lOYwdydrBZLJy1gtVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWxcdd9poJJ0RUv+l8wNTB+8e1i5OSQEDCR eHnqIDOELSZx4d56ti5GLg4hgcOMEu/bZ7NAOIsZJU7862TtYuTgYBOwkOj+pw3SICIQLHHw 8E4WEFtYIFriR1s3O0Q8RqLt43EmCNtIYur5rYwgNouAqsTnt/PA6nkFfCWuLl/ICDF/BaNE +6oNYM2cAjoSf1v/gjUzAl30/dQaMJtZQFyi6ctKVohLBSSW7DkPdbWoxMvH/1ghavIlnqz4 xAixQFDi5MwnLBMYhWchaZ+FpGwWkjKIuIHEl/e3oWxtiWULXzND2PoS3e9PMyGLL2BkX8Uo WpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGEEHt/xW3cF4+Y3jIUYBDkYlHt6Ccx/DhFgTy4or cw8xSnAwK4nwRql+ChPiTUmsrEotyo8vKs1JLT7EKM3BoiTOy/rpcpiQQHpiSWp2ampBahFM lomDU6qB0e1aNZsqe7z7qU9B58JX5rmnxRlPOf79QbbshVeBoQcfl6S5NZ865pG6w5/xw4TG 7/FFGuW/F866s+3+9aXimndur33Qw1ueOW+Rsl82U+TmM9z7Hl4JXKPh4plctabRvUFpcvTV VeJVJ6ptOG5yhh48advx+/+CSVFbwrZfcpp1v1VOM97moBJLcUaioRZzUXEiAHwCmIKcAgAA Archived-At: Subject: Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 06:49:48 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F040EEESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, As far as I remember, in SIP all "repeatable" header fields shall also be "= comma separabable". I can't think of a header field where that would not be the case. Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD22/=FD03/=FD2016 20:31 To: dispatch@ietf.org Subject: Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-pa= rameter-00.txt Marianne, Thank you. This draft is a huge improvement over the prior proposal for this purpose! I don't have a problem with this approach. The draft seems in reasonable shape. (I didn't read it for nits, as doing that seems premature.) One thing I noticed, which is really an issue with rfc5502: The P-Served-User header field doesn't seem to have the usual provision of headers like this for comma-separated repetition. And there is no mention pro or con regarding whether this header field can be repeated. Since it can already have both orig and term options, that presumably can coexist, I guess it can be repeated, but not using comma. Is that how it is being used in practice? It would be wise to clarify the ways in which this header field may be repeated. (E.g., every usage must have a distinct value of sessioncase-param.) And if multiple values separated by comma are being used in practice then the syntax ought to be corrected to allow that. Thanks, Paul On 3/21/16 3:24 PM, marianne.mohali@orange.com wrote: > Hello, > > Please find hereafter a new Internet-Draft "P-Served-User Header Field P= arameter for Originating CDIV session case in Session Initiation Protocol (= SIP)". > The purpose of the draft is to register a new SIP parameter for the P-Ser= ved-User header field defined as per RFC5502. > > Abstract: > This specification defines a new Session Initiation Protocol (SIP) P- > Served-User header field parameter, "orig-cdiv-param", which defines > the session case used by a proxy when handling an originating session > after Call Diversion (CDIV) services has been invoked for the served > user. The P-Served-User header field is defined in [RFC5502]. The > P-Served-User header field conveys the identity of the served user > and the session case that applies to this particular communication > session and application invocation. > This document updates [RFC5502] in order to add the originating after > CDIV session case. > > The draft can be found in : > URL: https://www.ietf.org/internet-drafts/draft-mohali-dispatc= h-originating-cdiv-parameter-00.txt > Status: https://datatracker.ietf.org/doc/draft-mohali-dispatch-or= iginating-cdiv-parameter/ > Htmlized: https://tools.ietf.org/html/draft-mohali-dispatch-origina= ting-cdiv-parameter-00 > > Best Regards, > Marianne Mohali > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_7594FB04B1934943A5C02806D1A2204B37F040EEESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Marianne,

Thank you. This draft is a huge improvement over the prior proposal for this purpose!

I don't have a problem with this approach. The draft seems in reasonable shape. (I didn't read it for nits, as doing that seems premature.)

One thing I noticed, which is really an issue with rfc5502:

The P-Served-User header field doesn't seem to have the usual provision of headers like this for comma-separated repetition. And there is no
mention pro or con regarding whether this header field can be repeated. Since it can already have both orig and term options, that presumably
can coexist, I guess it can be repeated, but not using comma. Is that
how it is being used in practice?

It would be wise to clarify the ways in which this header field may be
repeated. (E.g., every usage must have a distinct value of
sessioncase-param.) And if multiple values separated by comma are being used in practice then the syntax ought to be corrected to allow that.

        Thanks,
        Paul

On 3/21/16 3:24 PM, marianne.mohali@orange.com wrote:
> Hello,
>
> Please find hereafter a new Internet-Draft  "P-Served-User H= eader Field Parameter for Originating CDIV session case in Session Initiati= on Protocol (SIP)".
> The purpose of the draft is to register a new SIP parameter for the P-= Served-User header field defined as per RFC5502.
>
> Abstract:
>     This specification defines a new Session Initi= ation Protocol (SIP) P-
>     Served-User header field parameter, "orig= -cdiv-param", which defines
>     the session case used by a proxy when handling= an originating session
>     after Call Diversion (CDIV) services has been = invoked for the served
>     user.  The P-Served-User header field is = defined in [RFC5502].  The
>     P-Served-User header field conveys the identit= y of the served user
>     and the session case that applies to this part= icular communication
>     session and application invocation.
>     This document updates [RFC5502] in order to ad= d the originating after
>     CDIV session case.
>
> The draft can be found in :
> URL:           = https://www.ietf.org/internet-drafts/draft-mohali-dispatch-originating-cdiv= -parameter-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-mohali-dispatch-originating-cdiv-par= ameter/
> Htmlized:       https://tools.ietf.org/html/draft-mohali-dispatch-originating-cdiv-paramete= r-00
>
> Best Regards,
> Marianne Mohali
>
>
> ______________________________________________________________________= ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 messag= es electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privilege= d information that may be protected by law;
> they should not be distributed, used or copied without authorisation.<= br> > 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.
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www= .ietf.org/mailman/listinfo/dispatch
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch
 --_000_7594FB04B1934943A5C02806D1A2204B37F040EEESESSMB209erics_-- From nobody Wed Mar 23 05:20:31 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE5112DCEA for ; Wed, 23 Mar 2016 05:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 80EIdCVkXuTh for ; Wed, 23 Mar 2016 05:20:22 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 D809C12DC44 for ; Wed, 23 Mar 2016 05:11:24 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id m184so35571440iof.1 for ; Wed, 23 Mar 2016 05:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=iJ0qdBG35fDPhbnTNYW3JnMciiY2rLNRzuq1Zu9H+TI=; b=uGjL5m4R1Wdbs7DP3ctHSZh2WYGqXmpRneIK4WtjoL+PFH8ZbM3vP+KQui7AFigNMH tbs1C6kjyfG04E5f3lvxM/2lE/pNNhe7+Q/0xt0LdMPXuiYZ71IMuU1zq0zsiWNA2YIR qydfbYYx7qu5JhpmzFHqOZKBHBroFEmvU7pyd551Aj/vy8DfOk+gWx+qxPkGsT0jhLTN EI6AIM/sQDJDa9a/1cUDVXLuuoaSb1JYpWdQJx0PSeS4/GgHeaQ40i5uU1biXXuW5zRT RwzjgbqZzNAsgbyBBSO/Ke8JD1rko24jaF2lhV+Yb7TAxkvcwggr07kHL+CQK6cSGS0a 3bww== 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; bh=iJ0qdBG35fDPhbnTNYW3JnMciiY2rLNRzuq1Zu9H+TI=; b=bDuJQX7N1N2Db4MUVJw8IXbaG4d6PccJTaBAkh6rMvTeIsu1ub5qawYklc2qReqNQL bPF6JrEsERBLbDYBKnbfs5DZIgQrVZy9C++PWp7K/9f0e2Py0Uv4PUiSTMmrHYtgiRk6 OePiQAk72hgXFflyjdzyYh3DhqRALOr6SkhP1/+VFiqoq2mcBUgdy2gHkdFeooKWT9VA LioMMyXG03FEtziTidEjfGzUlWrQU6a3pLflvdIGcYDCtv3L6dA/lDrgLJEaxxGoeMkd xMf/3C+IPUWFvmwut1vwSmbUieGxTJEaQtinqz9dN2xpivkg9EwR0KfTYskn5W+u3jqh lnAw== X-Gm-Message-State: AD7BkJKhJpHVKcWZJhpcMm2XveIRwF0kInT590sMjsqT426j8VVX8P7IJ/nd5GoWj9nqLY3w3JWWej/C1g9BOXkx X-Received: by 10.107.39.139 with SMTP id n133mr2856561ion.57.1458731229884; Wed, 23 Mar 2016 04:07:09 -0700 (PDT) From: Brett Tate References: <21379_1458588251_56F04A5B_21379_5094_1_8B970F90C584EA4E97D5BAAC9172DBB81A970D51@OPEXCLILMA4.corporate.adroot.infra.ftgroup>, <56F18F74.9050504@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37F040EE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F040EE@ESESSMB209.ericsson.se> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIhakPXQQmTGBPTZD4lEyrix4n4mQH+xOQHAaDnjMKeqhSDMA== Date: Wed, 23 Mar 2016 07:07:09 -0400 Message-ID: To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=001a114082eec7cc75052eb5548b Archived-At: Subject: Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 12:20:28 -0000 --001a114082eec7cc75052eb5548b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, RFC 3261 section 7.3.1 indicates the rule and the exceptions. =E2=80=9C Multiple header field rows with the same field-name MAY be prese= nt in a message if and only if the entire field-value for that header field is defined as a comma-separated list (that is, if follows the grammar defined in Section 7.3). It MUST be possible to combine the multiple header field rows into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy- Authenticate, and Proxy-Authorization header fields. Multiple header field rows with these names MAY be present in a message, but since their grammar does not follow the general form listed in Section 7.3, they MUST NOT be combined into a single header field row.=E2=80=9D *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Christer Holmberg *Sent:* Wednesday, March 23, 2016 2:46 AM *To:* Paul Kyzivat; dispatch@ietf.org *Subject:* Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt Hi, As far as I remember, in SIP all "repeatable" header fields shall also be "comma separabable". I can't think of a header field where that would not be the case. Regards, Christer Sent from my Windows Phone ------------------------------ *From: *Paul Kyzivat *Sent: *=E2=80=8E22/=E2=80=8E03/=E2=80=8E2016 20:31 *To: *dispatch@ietf.org *Subject: *Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt Marianne, Thank you. This draft is a huge improvement over the prior proposal for this purpose! I don't have a problem with this approach. The draft seems in reasonable shape. (I didn't read it for nits, as doing that seems premature.) One thing I noticed, which is really an issue with rfc5502: The P-Served-User header field doesn't seem to have the usual provision of headers like this for comma-separated repetition. And there is no mention pro or con regarding whether this header field can be repeated. Since it can already have both orig and term options, that presumably can coexist, I guess it can be repeated, but not using comma. Is that how it is being used in practice? It would be wise to clarify the ways in which this header field may be repeated. (E.g., every usage must have a distinct value of sessioncase-param.) And if multiple values separated by comma are being used in practice then the syntax ought to be corrected to allow that. Thanks, Paul On 3/21/16 3:24 PM, marianne.mohali@orange.com wrote: > Hello, > > Please find hereafter a new Internet-Draft "P-Served-User Header Field Parameter for Originating CDIV session case in Session Initiation Protocol (SIP)". > The purpose of the draft is to register a new SIP parameter for the P-Served-User header field defined as per RFC5502. > > Abstract: > This specification defines a new Session Initiation Protocol (SIP) P- > Served-User header field parameter, "orig-cdiv-param", which defines > the session case used by a proxy when handling an originating session > after Call Diversion (CDIV) services has been invoked for the served > user. The P-Served-User header field is defined in [RFC5502]. The > P-Served-User header field conveys the identity of the served user > and the session case that applies to this particular communication > session and application invocation. > This document updates [RFC5502] in order to add the originating after > CDIV session case. > > The draft can be found in : > URL: https://www.ietf.org/internet-drafts/draft-mohali-dispatch-originating-cdiv= -parameter-00.txt > Status: https://datatracker.ietf.org/doc/draft-mohali-dispatch-originating-cdiv-par= ameter/ > Htmlized: https://tools.ietf.org/html/draft-mohali-dispatch-originating-cdiv-paramete= r-00 > > Best 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. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --001a114082eec7cc75052eb5548b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi= ,

=C2=A0=

RFC 3261 section 7.3.= 1 indicates the rule and the exceptions.

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=C2=A0

=E2=80=9C=C2=A0 Multiple header field rows with the same = field-name MAY be present in

=C2=A0=C2=A0 a message if and only if the entire field-valu= e for that header field

=C2=A0=C2=A0 is defined as a comma-separated list (that is, if fol= lows the grammar

= =C2=A0 =C2=A0header field rows into one "field-name: field-value"= pair, without

= =C2=A0=C2=A0 changing the semantics of the message, by appending each subse= quent

=C2=A0=C2= =A0 field-value to the first, each separated by a comma.=C2=A0 The exceptio= ns

=C2=A0=C2=A0= to this rule are the WWW-Authenticate, Authorization, Proxy-

=C2=A0=C2=A0 Authenticate, a= nd Proxy-Authorization header fields.=C2=A0 Multiple header

=C2=A0=C2=A0 field rows with t= hese names MAY be present in a message, but since

=C2=A0=C2=A0 their grammar does not foll= ow the general form listed in Section 7.3,

=C2=A0=C2=A0 they MUST NOT be combined into a s= ingle header field row.=E2=80=9D

=C2=A0

From: dispatch [mailto:dispatch-bounces@ietf.org] On Beh= alf Of Christer Holmberg
Sent: Wednesday, March 23, 2016 2:46= AM
To: Paul Kyzivat; dispat= ch@ietf.org
Subject: Re: [dispatch] New draft draft-mohali-di= spatch-originating-cdiv-parameter-00.txt

=C2=A0

Hi,=

As far as I remember, in SIP all "repeatable" header fiel= ds shall also be "comma separabable".

I can't think of= a header field where that would not be the case.

Regards,

Ch= rister

Sent from my Windows Phone

From: Paul Kyzivat
Sent: =E2=80=8E22/=E2=80=8E03/=E2=80=8E2016 20:31=
To: dispatch@ietf.org
Subject: <= /span>Re: [dispatch] New draft draft-mohali-dispatch-origi= nating-cdiv-parameter-00.txt

Marianne,

Thank you. This draft= is a huge improvement over the prior proposal for
this purpose!
I don't have a problem with this approach. The draft seems in reasonab= le
shape. (I didn't read it for nits, as doing that seems premature= .)

One thing I noticed, which is really an issue with rfc5502:
The P-Served-User header field doesn't seem to have the usual provisi= on
of headers like this for comma-separated repetition. And there is no=
mention pro or con regarding whether this header field can be repeated= .
Since it can already have both orig and term options, that presumably=
can coexist, I guess it can be repeated, but not using comma. Is that =
how it is being used in practice?

It would be wise to clarify th= e ways in which this header field may be
repeated. (E.g., every usage m= ust have a distinct value of
sessioncase-param.) And if multiple values= separated by comma are being
used in practice then the syntax ought to= be corrected to allow that.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Thanks,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Paul

On 3/= 21/16 3:24 PM, marianne.mohal= i@orange.com wrote:
> Hello,
>
> Please find hereafte= r a new Internet-Draft=C2=A0 "P-Served-User Header Field Parameter for= Originating CDIV session case in Session Initiation Protocol (SIP)".<= br>> The purpose of the draft is to register a new SIP parameter for the= P-Served-User header field defined as per RFC5502.
>
> Abstrac= t:
>=C2=A0=C2=A0=C2=A0=C2=A0 This specification defines a new Session= Initiation Protocol (SIP) P-
>=C2=A0=C2=A0=C2=A0=C2=A0 Served-User h= eader field parameter, "orig-cdiv-param", which defines
>= =C2=A0=C2=A0=C2=A0=C2=A0 the session case used by a proxy when handling an = originating session
>=C2=A0=C2=A0=C2=A0=C2=A0 after Call Diversion (C= DIV) services has been invoked for the served
>=C2=A0=C2=A0=C2=A0=C2= =A0 user.=C2=A0 The P-Served-User header field is defined in [RFC5502].=C2= =A0 The
>=C2=A0=C2=A0=C2=A0=C2=A0 P-Served-User header field conveys = the identity of the served user
>=C2=A0=C2=A0=C2=A0=C2=A0 and the ses= sion case that applies to this particular communication
>=C2=A0=C2=A0= =C2=A0=C2=A0 session and application invocation.
>=C2=A0=C2=A0=C2=A0= =C2=A0 This document updates [RFC5502] in order to add the originating afte= r
>=C2=A0=C2=A0=C2=A0=C2=A0 CDIV session case.
>
> The dr= aft can be found in :
> URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.= org/internet-drafts/draft-mohali-dispatch-originating-cdiv-parameter-00.txt=
> Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/draft-mohali-dispatch-origin= ating-cdiv-parameter/
> Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 https://tools.ietf.org/html/draft-mohali-dispatch-o= riginating-cdiv-parameter-00
>
> Best Regards,
> Mari= anne Mohali
>
>
> _______________________________________= ___________________________________________________________________________= _______
>
> Ce message et ses pieces jointes peuvent contenir d= es 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.
>
> Thi= s message and its attachments may contain confidential or privileged inform= ation that may be protected by law;
> they should not be distributed,= used or copied without authorisation.
> If you have received this em= ail in error, please notify the sender and delete this message and its atta= chments.
> As emails may be altered, Orange is not liable for message= s that have been modified, changed or falsified.
> Thank you.
>=
> _______________________________________________
> dispatch m= ailing list
> dispatch@ietf.org<= /a>
> http= s://www.ietf.org/mailman/listinfo/dispatch
>

_____________= __________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dis= patch

--001a114082eec7cc75052eb5548b-- From nobody Wed Mar 23 07:27:09 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5B412D7D1 for ; Wed, 23 Mar 2016 07:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9MQ3ij-5uExb for ; Wed, 23 Mar 2016 07:27:06 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 F2A8412DBCF for ; Wed, 23 Mar 2016 07:18:27 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id z68so21198867vkg.3 for ; Wed, 23 Mar 2016 07:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=9/7VEfwD9qIJ+eAz7oB+sJv/RLGby0Pugzfr7LdAxB4=; b=SKLcDUHsHwMlSiXQfndyx3NbMt5sTZj9MNjrMsiVFxsMBpY319yOXmLOk8DlxsRxj2 IR/gtK8c9Fuv0/fGcPho8e7tdhgFmpbB399VDEXv2p1unuaRyFUF8TsscUIqgnRzawXD gAyDaRQN8iRGnoKqfv3v6DOXtwgh+RVETbisYWPh8Eb3Zh7ierZG+BeBwTlEUygKmZqr uxcsgfYKdRmJC55ZURjCYyZUYelnu5qLgZow05AdGyzUcsmLHGKY7KAJoz+KdnJHz5t0 4Hy+nP+DKwudS9YO2B7Z/svAaeetynLQ+44ww8JUVmvUcnA7vggega/VB5GloJftXGNz YGog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=9/7VEfwD9qIJ+eAz7oB+sJv/RLGby0Pugzfr7LdAxB4=; b=QZiB8IlHRJsdn6qUUbyptOcQywe9FR5rupbdv0BL3jLVd/bMMUZIVLFbS6dB70Rkbt 8G86/dtZkSdxjun9HH8idgbGdjuGcasZK320IgMVO/DZs4JhgUzS2c7VbE2iJ+22lPi0 0MrDmdgrizanoqov6m3vBjt+Fu4yhZuA2spu7VPrALF8gYr/wZjD2KcmKmF4DMdCipcP Wn8PPmlv0bbdNG+IEZxyqnvzhEaqBF6DgD5Q1OOFbWBZoRakfEjWxibLdnWHGOHLOnSZ pMGoyNQiM0GN8jxtIWGXEiGl+XY22taYDEMSjojan0InQrjAtOQORZU7oW5fAjfpZsmI YwRw== X-Gm-Message-State: AD7BkJJchc3pr607S0fBb2D8mzhL1NNVlzNli3p7V7VAlir0jCRM04p5txG0MkYsAGU7la6iMLNChBW5gjQh/w== MIME-Version: 1.0 X-Received: by 10.176.3.48 with SMTP id 45mr1589241uat.123.1458742707117; Wed, 23 Mar 2016 07:18:27 -0700 (PDT) Received: by 10.103.43.5 with HTTP; Wed, 23 Mar 2016 07:18:27 -0700 (PDT) Date: Wed, 23 Mar 2016 07:18:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=001a113e23eae0668c052eb80038 Archived-At: Subject: [dispatch] Draft agenda for IETF 95 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 14:27:08 -0000 --001a113e23eae0668c052eb80038 Content-Type: text/plain; charset=UTF-8 Colleagues, The draft agenda for the DISPATCH meeting is available: https://datatracker.ietf.org/meeting/95/agenda/dispatch/ Comments welcome. See you in Buenos Aires! -MSK, DISPATCH co-chair --001a113e23eae0668c052eb80038 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

The draft age= nda for the DISPATCH meeting is available:
https://datatracker.ietf.org/meetin= g/95/agenda/dispatch/

Comments welcome.

See y= ou in Buenos Aires!
-MSK, DISPATCH co-chair

--001a113e23eae0668c052eb80038-- From nobody Wed Mar 23 07:30:08 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F29312D0D8 for ; Wed, 23 Mar 2016 07:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 2xI65PFpTslL for ; Wed, 23 Mar 2016 07:30:05 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF35412D53F for ; Wed, 23 Mar 2016 07:23:01 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-09v.sys.comcast.net with comcast id ZSNh1s0092Bo0NV01SP0Uk; Wed, 23 Mar 2016 14:23:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-05v.sys.comcast.net with comcast id ZSP01s00C3KdFy101SP0SU; Wed, 23 Mar 2016 14:23:00 +0000 To: Christer Holmberg , "dispatch@ietf.org" References: <21379_1458588251_56F04A5B_21379_5094_1_8B970F90C584EA4E97D5BAAC9172DBB81A970D51@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <56F18F74.9050504@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37F040EE@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56F2A6C3.6020403@alum.mit.edu> Date: Wed, 23 Mar 2016 10:22:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F040EE@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=1458742980; bh=TyzYP/dNUjIyqUAd8EUDb7Kw72m7PTjGg9eXAJ6MLlY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=OxT3wridhD64oLNyg/BmC5aqOBJYUwHOC3pPL+Psv9pIfLcb1mWaD+IEVXkfVT9c8 LBFOFR5PVNx1JOha84y6ZIcUR4F0gWLuOyUOMY/YpaMPp/5Yi5iE31yxk8hZqe5m6o WmMvJIPHhXk1IqEcrJi2eavsV+4uqorwlm4W7tqRXugQom1h93W/crm05cOIuWFmR+ M/8G8wDLucqsXNBhJ7OOKjeVkvpyKtQkdfVErlFEE4OA9D6Oz8qI3F5BODcp8Ytb4X DsLWkvCCSNCO5UqxTFusZxcgbcwzclHbtNdTFYkr7XFrz4PFDSqHLTZ/83rDCyjZgX MeC9acNgOVXLw== Archived-At: Subject: Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 14:30:06 -0000 On 3/23/16 2:45 AM, Christer Holmberg wrote: > Hi, > > As far as I remember, in SIP all "repeatable" header fields shall also > be "comma separabable". > > I can't think of a header field where that would not be the case. The header fields with that property have syntax to match. The syntax in 5502 doesn't support that for this header field. If that was then intent then the syntax should be revised. Thanks, Paul > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Paul Kyzivat > Sent: ý22/ý03/ý2016 20:31 > To: dispatch@ietf.org > Subject: Re: [dispatch] New draft > draft-mohali-dispatch-originating-cdiv-parameter-00.txt > > Marianne, > > Thank you. This draft is a huge improvement over the prior proposal for > this purpose! > > I don't have a problem with this approach. The draft seems in reasonable > shape. (I didn't read it for nits, as doing that seems premature.) > > One thing I noticed, which is really an issue with rfc5502: > > The P-Served-User header field doesn't seem to have the usual provision > of headers like this for comma-separated repetition. And there is no > mention pro or con regarding whether this header field can be repeated. > Since it can already have both orig and term options, that presumably > can coexist, I guess it can be repeated, but not using comma. Is that > how it is being used in practice? > > It would be wise to clarify the ways in which this header field may be > repeated. (E.g., every usage must have a distinct value of > sessioncase-param.) And if multiple values separated by comma are being > used in practice then the syntax ought to be corrected to allow that. > > Thanks, > Paul > > On 3/21/16 3:24 PM, marianne.mohali@orange.com wrote: >> Hello, >> >> Please find hereafter a new Internet-Draft "P-Served-User Header Field Parameter for Originating CDIV session case in Session Initiation Protocol (SIP)". >> The purpose of the draft is to register a new SIP parameter for the P-Served-User header field defined as per RFC5502. >> >> Abstract: >> This specification defines a new Session Initiation Protocol (SIP) P- >> Served-User header field parameter, "orig-cdiv-param", which defines >> the session case used by a proxy when handling an originating session >> after Call Diversion (CDIV) services has been invoked for the served >> user. The P-Served-User header field is defined in [RFC5502]. The >> P-Served-User header field conveys the identity of the served user >> and the session case that applies to this particular communication >> session and application invocation. >> This document updates [RFC5502] in order to add the originating after >> CDIV session case. >> >> The draft can be found in : >> URL:https://www.ietf.org/internet-drafts/draft-mohali-dispatch-originating-cdiv-parameter-00.txt >> Status:https://datatracker.ietf.org/doc/draft-mohali-dispatch-originating-cdiv-parameter/ >> Htmlized:https://tools.ietf.org/html/draft-mohali-dispatch-originating-cdiv-parameter-00 >> >> Best 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. >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >>https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Mar 23 08:05:11 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3225E12D164 for ; Wed, 23 Mar 2016 08:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 iNQHFkIL0fb5 for ; Wed, 23 Mar 2016 08:05:07 -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 AB6AA12D0BD for ; Wed, 23 Mar 2016 08:05:06 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-dd-56f2b0a059da Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 25.9C.23401.0A0B2F65; Wed, 23 Mar 2016 16:05:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Wed, 23 Mar 2016 16:04:42 +0100 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt Thread-Index: AQHRhGkLzUOrLDCZ4kW4P8hV8CvBOp9mln93gABu64CAABwWIA== Date: Wed, 23 Mar 2016 15:04:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F07F91@ESESSMB209.ericsson.se> References: <21379_1458588251_56F04A5B_21379_5094_1_8B970F90C584EA4E97D5BAAC9172DBB81A970D51@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <56F18F74.9050504@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37F040EE@ESESSMB209.ericsson.se> <56F2A6C3.6020403@alum.mit.edu> In-Reply-To: <56F2A6C3.6020403@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.148] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7me6CDZ/CDLavV7NYOmkBq8WKDQdY HZg8/r7/wOSxZMlPpgCmKC6blNSczLLUIn27BK6MY8ffshb8V644evQaewPjetkuRk4OCQET idUbmpghbDGJC/fWs4HYQgKHGSWuzHSFsBczSvyZKNzFyMHBJmAh0f1PGyQsIhAscfDwThYQ W1ggWuJHWzc7RDxGou3jcSYI20li8trlzCCtLAKqEjNvZ4KEeQV8JTa+msHYxcgFNH0Ck8St 7asYQRKcAjoSvfe3g9mMQOd8P7UGbA6zgLjErSfzmSDOFJBYsuc81MmiEi8f/2OFsJUkGpc8 YYWoN5A4t30jO4StLbFs4WtmiMWCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG0eLU4uLc dCMjvdSizOTi4vw8vbzUkk2MwBg5uOW31Q7Gg88dDzEKcDAq8fAWnPsYJsSaWFZcmXuIUYKD WUmEt3TNpzAh3pTEyqrUovz4otKc1OJDjNIcLErivGyfLocJCaQnlqRmp6YWpBbBZJk4OKUa GFdaT0j/ylV5VUSDr2Dn7pDGyXkMihPuC22u+76Sky3WeoHtF8nZSY+/2Vp29JdLGVWuXbuo MHjWrDtfeh6uydWTLO06/e39EeOwstN35pjp7WjT1vwst1T/lYEae6PXQs0twi0HlXKdmJ7P 73J/22tqFrf5b5NVkPazFTvnzjTaGDr7fHkNkxJLcUaioRZzUXEiAPUMPrSNAgAA Archived-At: Subject: Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 15:05:10 -0000 Hi, >> As far as I remember, in SIP all "repeatable" header fields shall also=20 >> be "comma separabable". >> >> I can't think of a header field where that would not be the case. > > The header fields with that property have syntax to match. > > The syntax in 5502 doesn't support that for this header field. If that wa= s then intent then the syntax > should be revised. Correct. Regards, Christer > From: Paul Kyzivat > Sent: =FD22/=FD03/=FD2016 20:31 > To: dispatch@ietf.org > Subject: Re: [dispatch] New draft > draft-mohali-dispatch-originating-cdiv-parameter-00.txt > > Marianne, > > Thank you. This draft is a huge improvement over the prior proposal=20 > for this purpose! > > I don't have a problem with this approach. The draft seems in=20 > reasonable shape. (I didn't read it for nits, as doing that seems=20 > premature.) > > One thing I noticed, which is really an issue with rfc5502: > > The P-Served-User header field doesn't seem to have the usual=20 > provision of headers like this for comma-separated repetition. And=20 > there is no mention pro or con regarding whether this header field can be= repeated. > Since it can already have both orig and term options, that presumably=20 > can coexist, I guess it can be repeated, but not using comma. Is that=20 > how it is being used in practice? > > It would be wise to clarify the ways in which this header field may be=20 > repeated. (E.g., every usage must have a distinct value of > sessioncase-param.) And if multiple values separated by comma are=20 > being used in practice then the syntax ought to be corrected to allow tha= t. > > Thanks, > Paul > > On 3/21/16 3:24 PM, marianne.mohali@orange.com wrote: >> Hello, >> >> Please find hereafter a new Internet-Draft "P-Served-User Header Field = Parameter for Originating CDIV session case in Session Initiation Protocol = (SIP)". >> The purpose of the draft is to register a new SIP parameter for the P-Se= rved-User header field defined as per RFC5502. >> >> Abstract: >> This specification defines a new Session Initiation Protocol (SIP) P= - >> Served-User header field parameter, "orig-cdiv-param", which defines >> the session case used by a proxy when handling an originating sessio= n >> after Call Diversion (CDIV) services has been invoked for the served >> user. The P-Served-User header field is defined in [RFC5502]. The >> P-Served-User header field conveys the identity of the served user >> and the session case that applies to this particular communication >> session and application invocation. >> This document updates [RFC5502] in order to add the originating afte= r >> CDIV session case. >> >> The draft can be found in : >> URL:https://www.ietf.org/internet-drafts/draft-mohali-dispatch-origin >> ating-cdiv-parameter-00.txt=20 >> Status:https://datatracker.ietf.org/doc/draft-mohali-dispatch-origina >> ting-cdiv-parameter/ >> Htmlized:https://tools.ietf.org/html/draft-mohali-dispatch-originatin >> g-cdiv-parameter-00 >> >> Best Regards, >> Marianne Mohali >> >> >> _____________________________________________________________________ >> ____________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >>https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Mar 23 10:53:01 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA8112D7E3 for ; Wed, 23 Mar 2016 10:52:52 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 2GxyyxmCMaVk for ; Wed, 23 Mar 2016 10:52:48 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 5CEE612D73A for ; Wed, 23 Mar 2016 10:52:48 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id v187so24922088ioe.2 for ; Wed, 23 Mar 2016 10:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to; bh=/NNqcCOwdzgHJ6ZcAUxD5HhzaYwggVwO/Wa3AQT2IAs=; b=YEpDVWaQeUhOtFLOFJKYBoVKlPOd78VXQ/eZbVTJSPvRi+yaXYLOPziFpagxsOo4Yv 6/fmfr5nsmZ1VCBzDUCm3RgyhF6CKP1iANrsCKlZvXOAHL8BF4ifdR9qlBmRhOz0OxDO p3vTzEAtXLRxRPgsDGm6WtYpE64hVxZI99aATH16yQh6NdlxOV576jau4JgbPbg4qH30 sscKITIAGQSNhCIp4UBMO8VI4QGyEYl6k4SyKyDxpAjC4mWWb+fMdyx7HUWlI2q7AwDN /oxdGoKW9uvoqoQQfQfhiMOdjZ6UflJX6WBsfmYp8C7GQuqaQn2RXonYnxGrGkFhmlIg Z5dg== 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; bh=/NNqcCOwdzgHJ6ZcAUxD5HhzaYwggVwO/Wa3AQT2IAs=; b=W6iH8JjtbrnP/h7m1Oq4hSrA0noHTUY5vDGNwAmgixQ43Ra3orEZzD7hDSQ3KUm/RS rFqTiNAfK3e6LALO3ZhAf5pQRs3JwIUnETOG+uYQ2LF9fnvO+E/1p/pG4wmxKurQrAMj eHvBnkhCnOeLjPnt4Dhzk976rNgB/H8BbpmBBvf+iSwYya3CrCMjIsvrX1k1isw2eVu7 wOhjlNlFiDHnfVN1Y5xzEQ0ANx1KYCCcdoMZw4Sv94MSpE+oSMGCrXsjgOHbh41bxc3h tBXvlIsXKjqOVL9B72ZTk330PAGpPUjrvisgCpvKKtM42LB5sRTuOixDi/9m41oTUal7 nabw== X-Gm-Message-State: AD7BkJJ+qI7PeWF/HKJC33vzABUCxlwYhqbi5m3UaIN8q/dtGFaU4+341vr6vvJd4GGmOAuLveUmdJTpulpNtmM3 X-Received: by 10.50.43.133 with SMTP id w5mr24559547igl.80.1458755567444; Wed, 23 Mar 2016 10:52:47 -0700 (PDT) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGFLKUn7pBcj0z4RBmzP+jh+8We2g== Date: Wed, 23 Mar 2016 13:52:46 -0400 Message-ID: To: marianne.mohali@orange.com, dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dispatch] draft-mohali-dispatch-originating-cdiv-parameter: question/comment X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 17:52:53 -0000 Hi, Since draft-mohali-dispatch-originating-cdiv-parameter is updating RFC 5502, should the draft be updated to include the missing rule concerning when name-addr must be used? As mentioned within the following email from 2013, RFC 5502 does not indicate to use the RFC 3261 section 20 bracket rule (or provide a similar rule). Without such a rule, it is ambiguous if parameters decode as part of PServedUser-value or served-user-param. http://www.ietf.org/mail-archive/web/sipcore/current/msg05731.html Thanks, Brett From nobody Wed Mar 23 12:02:34 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C5212D807 for ; Wed, 23 Mar 2016 12:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 48Df8zIUW0Hk for ; Wed, 23 Mar 2016 12:02:32 -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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D9D12D755 for ; Wed, 23 Mar 2016 12:02:16 -0700 (PDT) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by comcast with SMTP id io2qamWo0BQoYio2qa9DAS; Wed, 23 Mar 2016 19:02:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458759736; bh=Yr1ukRb25W8O18kMkqCsFvJewKZ2P+CbDScZMx+08HQ=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=XOxSzxXWcPxqTvi6maXZeju0frqdQr2h2DyzgizUQVNdRndHrKCJs4XlRf2wV+sd6 qUTHlm0nj64igQuvcpk2/rvaWX6bEO8yKW2kHhtMRv4yFBV5qKM81hDI7OSl0ytY2W H+PNfL81E96eJQdDojk4f/3hNCrx6l2nv0hBQ5DRGG2V+6EhoUT1LiYFU9aQ7C5r/w Z0RHTrQSdJo4hl8ch4/hLDeNk8p0bGTGr6IcJtFENLxCmVUty5lsriuOLTchnd0Xhx +1/E8RP1Er7ZXNE6DvSDaOg4+mWSqUt6DG4V5PLiG4URE+zf0isR55oikgdZ01FElm GiavLisYtBroQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-10v.sys.comcast.net with comcast id ZX2F1s0041nMCLR01X2FEc; Wed, 23 Mar 2016 19:02:16 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u2NJ2EnW027580; Wed, 23 Mar 2016 15:02:14 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u2NJ2DX5027573; Wed, 23 Mar 2016 15:02:13 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Sean Leonard In-Reply-To: <56F1CD23.2040002@seantek.com> (dev+ietf@seantek.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 23 Mar 2016 15:02:13 -0400 Message-ID: <87a8lp10i2.fsf@hobgoblin.ariadne.com> Archived-At: Cc: dispatch@ietf.org, ietf-smtp@ietf.org Subject: Re: [dispatch] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 19:02:33 -0000 [I'm not sure why this was sent to Dispatch, as it doesn't seem to involve SIP.] As a work, this seems very useful, as it pulls together (or will pull together) a lot of useful information about e-mail addresses in both specification and practice. But the terminology needs to be clarified at some point: a single document (or sentence) is either normative or not. If something is a "best common practice", it is not normative, the rules are set somewhere else. Dale From nobody Wed Mar 23 12:06:12 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189E012D1CA for ; Wed, 23 Mar 2016 12:06:11 -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 autolearn_force=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 pEejAJr2E0Rh for ; Wed, 23 Mar 2016 12:06:09 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E08DD12D0EC for ; Wed, 23 Mar 2016 12:06:09 -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.2/8.14.9) with ESMTPSA id u2NJ61er052308 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 23 Mar 2016 14:06:02 -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 To: "Dale R. Worley" References: <87a8lp10i2.fsf@hobgoblin.ariadne.com> From: Adam Roach Message-ID: <56F2E919.4070706@nostrum.com> Date: Wed, 23 Mar 2016 14:06:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <87a8lp10i2.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 19:06:11 -0000 On 3/23/16 14:02, Dale R. Worley wrote: > [I'm not sure why this was sent to Dispatch, as it doesn't seem to > involve SIP.] DISPATCH is area-wide. With the merging of APPS and RAI to form ART, you're going to see DISPATCH being asked to handle topics that would have traditionally been part of APPS' purview. /a From nobody Wed Mar 23 12:37:13 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DB0127058 for ; Wed, 23 Mar 2016 12:37:11 -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 autolearn_force=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 29NDGGzkmFbV for ; Wed, 23 Mar 2016 12:37:10 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 72C8712D6B8 for ; Wed, 23 Mar 2016 12:37:10 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2NJb6Dn066130 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 23 Mar 2016 14:37:06 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Adam Roach" Date: Wed, 23 Mar 2016 14:37:05 -0500 Message-ID: In-Reply-To: <56F2E919.4070706@nostrum.com> References: <87a8lp10i2.fsf@hobgoblin.ariadne.com> <56F2E919.4070706@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 19:37:12 -0000 On 23 Mar 2016, at 14:06, Adam Roach wrote: > On 3/23/16 14:02, Dale R. Worley wrote: >> [I'm not sure why this was sent to Dispatch, as it doesn't seem to >> involve SIP.] > > DISPATCH is area-wide. With the merging of APPS and RAI to form ART, > you're going to see DISPATCH being asked to handle topics that would > have traditionally been part of APPS' purview. Adam beat me to it. We are all ART now :-) There's even a new charter: https://datatracker.ietf.org/wg/dispatch/charter/ Ben. From nobody Wed Mar 23 12:38:50 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA021127058 for ; Wed, 23 Mar 2016 12:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 5SREbsMySvOu for ; Wed, 23 Mar 2016 12:38:48 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 8492712D6B8 for ; Wed, 23 Mar 2016 12:38:48 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by comcast with SMTP id ioZiaFKfXYCx6iocBaF3Mr; Wed, 23 Mar 2016 19:38:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458761927; bh=BNkNTEQRGbl2C7wP5AUOM9uxZ1GSp6gvLm+UWT68cGQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=uhimw3PxknnNiUgmedBie5LBTChiI/SpXgxkyCIAeKaVnVOqWoXj8P+0Flo+wgqTp ify3Z6J3RinPKKOug71OyfUjD3k9IwQxp+pNu8NaLaOymKi+JIhTRTr9ik2lxu/48R Wvq4LPjkh8Yj+wdekqy8JMoW1foDuWvo+nDBGp7Crfk+OlGriq4mOTZxRFY9b5qyrq 8BnoYNWgLGwp4Vx+tDdpbIxL9qFnG7+QGyw5wLrWjLaLJSBrx8+hLtXHfC12XeY4ND VOqMxnfPAXtsT07ngRYx5QM6CVrxnEZAQnWh8p1O3RmamGei878h4F5Iw4McBNCZDS fPiOBGx/85hXw== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with comcast id ZXen1s00A3KdFy101Xenon; Wed, 23 Mar 2016 19:38:47 +0000 To: dispatch@ietf.org References: <87a8lp10i2.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <56F2F0C6.30003@alum.mit.edu> Date: Wed, 23 Mar 2016 15:38:46 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <87a8lp10i2.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 19:38:50 -0000 On 3/23/16 3:02 PM, Dale R. Worley wrote: > [I'm not sure why this was sent to Dispatch, as it doesn't seem to > involve SIP.] dispatch is being rechartered to have scope encompassing all of the ART area. I *think* this proposal falls in that scope. Thanks, Paul From nobody Wed Mar 23 14:26:27 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A765412D966; Wed, 23 Mar 2016 14:26:25 -0700 (PDT) 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 autolearn_force=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 tS6BKCaese6B; Wed, 23 Mar 2016 14:26:23 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 8A35212D685; Wed, 23 Mar 2016 14:26:19 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D7BCA50A88; Wed, 23 Mar 2016 17:26:17 -0400 (EDT) To: "Dale R. Worley" References: <87a8lp10i2.fsf@hobgoblin.ariadne.com> From: Sean Leonard Message-ID: <56F30A52.50305@seantek.com> Date: Wed, 23 Mar 2016 14:27:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <87a8lp10i2.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dispatch@ietf.org, ietf-smtp@ietf.org Subject: Re: [dispatch] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 21:26:26 -0000 On 3/23/2016 12:02 PM, Dale R. Worley wrote: > As a work, this seems very useful, as it pulls together (or will pull > together) a lot of useful information about e-mail addresses in both > specification and practice. Great! > But the terminology needs to be clarified > at some point: a single document (or sentence) is either normative or > not. If something is a "best common practice", it is not normative, th= e > rules are set somewhere else. IETF Process issue: Well, RFC 5646/BCP 47 "Tags for Identifying Languages" is a BCP.=20 However, it is referred to normatively by a slew of Standards Track=20 documents. I would propose that this document be seen in a similar=20 light. One would not expect the Mail Standards to adopt these regular=20 expressions, but other standards that use regular expressions for e-mail = would probably do best to refer to this document. Examples include=20 CBOR/CDDL (draft-greevenbosch-appsawg-cbor-cddl), and DNS/NAPTR records=20 (RFCs 3401-3404), when the subject matter is e-mail stuff. When I raised the classification issue during initial development, one=20 advisor said something to the effect of oh, so it's like a Real BCP,=20 where it actually prescribes actual Best Current Practices, unlike what=20 most of the BCPs these days are. (Whatever that means, just the messenger= !) Sean From nobody Wed Mar 23 14:34:30 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CB712D947 for ; Wed, 23 Mar 2016 14:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 6ZsK89aSKPD3 for ; Wed, 23 Mar 2016 14:33:19 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (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 01D8A12D962 for ; Wed, 23 Mar 2016 14:33:18 -0700 (PDT) Received: by mail-lb0-x231.google.com with SMTP id qe11so18386460lbc.3 for ; Wed, 23 Mar 2016 14:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6M8NIBSUBzWIqPX94UUh5qo/f6kBhN9g9QaCrhn5QG0=; b=BEAafWxvqXgZ9yykknJoo05EcbdSfceHsSigL8iYruCcmNGWyW+Cvk6HqztpQ4YrQy TyAhaiMo2u18vyUyOUEosGcBRaOMsdghC4jUj6zExVkKuOTYstm63fO9xz93TzqJkE2w 1op0xv3ky3noj5v3s2zdPshKZSElKYTv+qWCmtRGk9eprFV0lkji/t65HQ+Zn3wqvU8Z DQ9g8nq1oKfKb66qTaJa6L9hvCVK5jbtm8NirxYflZ3mVZ/GyNw4vnTOuATkoWcOHIjx sU0nZkR6IYsi70fqztEBUb8HdeaW8gLNThy5tOG995vwruticbIsMCVyKgIeae/lIBAE HyfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6M8NIBSUBzWIqPX94UUh5qo/f6kBhN9g9QaCrhn5QG0=; b=iDXqbpc7FiQM4jmzPfwksSRMqObfpk7rAEBqSLiJEwR5a+C7DapGhCiFxhzb+iQsJQ +Y8iedRYwjD24QDLmGU44EYMjvUVbAb0ZmS+3A3UOLkgXRlSzecRNPM9ow1v7DXw6U5c AxUeby2+IPvPyUqH2WFXupgbkFAcf59Wcp9GWAM9CHb0XxCNTqDhUNUN+Eohg7QadAMW rPcBI/S2+UokG1NOfdNSsi7V/jQccfIswSUW7y5N2LjwQf4ZB9aWxfdIwHzDY8zHx1tU SWsr8vaupbe0+mDiVuzog+5J2lJo5V0C9j/nhibb2IuOlS8ulpehK5hh68KUzT6X4xKC zSjQ== X-Gm-Message-State: AD7BkJJk6xM3ltRt/fHZG6whc8v47gGCQeYlkvTSmn4I297f4EUfEbLs8v3/TQuUy6FzoZK6O3h/lBjwwdtENQ== X-Received: by 10.112.169.105 with SMTP id ad9mr2100730lbc.135.1458768797212; Wed, 23 Mar 2016 14:33:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.40.136 with HTTP; Wed, 23 Mar 2016 14:32:37 -0700 (PDT) X-Originating-IP: [72.66.83.34] In-Reply-To: <56F30A52.50305@seantek.com> References: <87a8lp10i2.fsf@hobgoblin.ariadne.com> <56F30A52.50305@seantek.com> From: Ted Lemon Date: Wed, 23 Mar 2016 17:32:37 -0400 Message-ID: To: Sean Leonard Content-Type: multipart/alternative; boundary=001a11c38c08f7bc34052ebe131c Archived-At: X-Mailman-Approved-At: Wed, 23 Mar 2016 14:34:27 -0700 Cc: dispatch@ietf.org, ietf-smtp@ietf.org Subject: Re: [dispatch] [ietf-smtp] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 21:33:23 -0000 --001a11c38c08f7bc34052ebe131c Content-Type: text/plain; charset=UTF-8 BCPs can be normative, Dale. It's informational docs that are not. They are "informative." :) On Wed, Mar 23, 2016 at 5:27 PM, Sean Leonard wrote: > On 3/23/2016 12:02 PM, Dale R. Worley wrote: > >> As a work, this seems very useful, as it pulls together (or will pull >> together) a lot of useful information about e-mail addresses in both >> specification and practice. >> > > Great! > > But the terminology needs to be clarified >> at some point: a single document (or sentence) is either normative or >> not. If something is a "best common practice", it is not normative, the >> rules are set somewhere else. >> > > IETF Process issue: > Well, RFC 5646/BCP 47 "Tags for Identifying Languages" is a BCP. However, > it is referred to normatively by a slew of Standards Track documents. I > would propose that this document be seen in a similar light. One would not > expect the Mail Standards to adopt these regular expressions, but other > standards that use regular expressions for e-mail would probably do best to > refer to this document. Examples include CBOR/CDDL > (draft-greevenbosch-appsawg-cbor-cddl), and DNS/NAPTR records (RFCs > 3401-3404), when the subject matter is e-mail stuff. > > When I raised the classification issue during initial development, one > advisor said something to the effect of oh, so it's like a Real BCP, where > it actually prescribes actual Best Current Practices, unlike what most of > the BCPs these days are. (Whatever that means, just the messenger!) > > Sean > > > _______________________________________________ > ietf-smtp mailing list > ietf-smtp@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-smtp > --001a11c38c08f7bc34052ebe131c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
BCPs can be normative, Dale. =C2=A0 It's informational= docs that are not. =C2=A0 They are "informative." =C2=A0 :)

On Wed, Mar 23, = 2016 at 5:27 PM, Sean Leonard <dev+ietf@seantek.com> wrot= e:
On 3/23/2016 12:02 PM, Dale R. Worley = wrote:
As a work, this seems very useful, as it pulls together (or will pull
together) a lot of useful information about e-mail addresses in both
specification and practice.

Great!

=C2=A0 =C2=A0But the terminology needs to be clarified
at some point:=C2=A0 a single document (or sentence) is either normative or=
not.=C2=A0 If something is a "best common practice", it is not no= rmative, the
rules are set somewhere else.

IETF Process issue:
Well, RFC 5646/BCP 47 "Tags for Identifying Languages" is a BCP. = However, it is referred to normatively by a slew of Standards Track documen= ts. I would propose that this document be seen in a similar light. One woul= d not expect the Mail Standards to adopt these regular expressions, but oth= er standards that use regular expressions for e-mail would probably do best= to refer to this document. Examples include CBOR/CDDL (draft-greevenbosch-= appsawg-cbor-cddl), and DNS/NAPTR records (RFCs 3401-3404), when the subjec= t matter is e-mail stuff.

When I raised the classification issue during initial development, one advi= sor said something to the effect of oh, so it's like a Real BCP, where = it actually prescribes actual Best Current Practices, unlike what most of t= he BCPs these days are. (Whatever that means, just the messenger!)

Sean


_______________________________________________
ietf-smtp mailing list
ietf-smtp@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/ietf-smtp

--001a11c38c08f7bc34052ebe131c-- From nobody Wed Mar 23 19:02:48 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F80F12D63B for ; Wed, 23 Mar 2016 19:02:46 -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 autolearn_force=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 JBXKmbdsuMdk for ; Wed, 23 Mar 2016 19:02:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 92A8912D6A0 for ; Wed, 23 Mar 2016 19:02:40 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2O22b5K011200 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 23 Mar 2016 21:02:38 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Paul Kyzivat" Date: Wed, 23 Mar 2016 21:02:36 -0500 Message-ID: <2B1E5803-9F28-4511-AB7F-AA3E7A733369@nostrum.com> In-Reply-To: <56F2F0C6.30003@alum.mit.edu> References: <87a8lp10i2.fsf@hobgoblin.ariadne.com> <56F2F0C6.30003@alum.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 02:02:47 -0000 On 23 Mar 2016, at 14:38, Paul Kyzivat wrote: > On 3/23/16 3:02 PM, Dale R. Worley wrote: >> [I'm not sure why this was sent to Dispatch, as it doesn't seem to >> involve SIP.] > > dispatch is being rechartered to have scope encompassing all of the > ART area. I *think* this proposal falls in that scope. For the record, it _has_been_ rechartered. (Otherwise, I agree.) Ben. From nobody Thu Mar 24 04:16:14 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D771B12D7F9 for ; Thu, 24 Mar 2016 04:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 bDFjnbawD8OO for ; Thu, 24 Mar 2016 04:16:09 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.140]) (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 3ECB512D7DA for ; Thu, 24 Mar 2016 04:16:08 -0700 (PDT) Received: from [85.158.139.163] by server-4.bemta-5.messagelabs.com id 46/1D-20731-77CC3F65; Thu, 24 Mar 2016 11:16:07 +0000 X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-7.tower-188.messagelabs.com!1458818166!24010259!1 X-Originating-IP: [195.232.244.136] X-StarScan-Received: X-StarScan-Version: 8.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19670 invoked from network); 24 Mar 2016 11:16:06 -0000 Received: from mailout04.vodafone.com (HELO mailout04.vodafone.com) (195.232.244.136) by server-7.tower-188.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Mar 2016 11:16:06 -0000 Received: from mailint04.vodafone.com (mailint04.vodafone.com [195.232.244.201]) by mailout04.vodafone.com (Postfix) with ESMTP id 3qW3lV0YsQznTYm; Thu, 24 Mar 2016 12:16:05 +0100 (CET) Received: from mailint04.vodafone.com (localhost [127.0.0.1]) by mailint04.vodafone.com (Postfix) with ESMTP id 3qW3lT5L49zfZ6S; Thu, 24 Mar 2016 12:16:05 +0100 (CET) Received: from VOEXC06W.internal.vodafone.com (voexc06w.dc-ratingen.de [145.230.101.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailint04.vodafone.com (Postfix) with ESMTPS id 3qW3lT4yW2zfYyN; Thu, 24 Mar 2016 12:16:05 +0100 (CET) Received: from VOEXC15W.internal.vodafone.com (145.230.101.17) by VOEXC06W.internal.vodafone.com (145.230.101.26) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 24 Mar 2016 12:16:05 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.72]) by voexc15w.internal.vodafone.com ([145.230.101.17]) with mapi id 14.03.0224.002; Thu, 24 Mar 2016 12:16:04 +0100 From: "Dawes, Peter, Vodafone Group" To: Ben Campbell Thread-Topic: [dispatch] https://www.ietf.org/id/draft-dawes-sipcore-mediasec-parameter-03.txt Thread-Index: AQHRhIxvmJN1GTx1qkKHeu0/YHudE59oaAqA Date: Thu, 24 Mar 2016 11:16:03 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8A25B11@VOEXM31W.internal.vodafone.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C89EE030@VOEXM31W.internal.vodafone.com> <02EE1690-A9A5-4C4B-8E7F-B4A9D628B1F9@nostrum.com> In-Reply-To: <02EE1690-A9A5-4C4B-8E7F-B4A9D628B1F9@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dispatch-chairs@tools.ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] https://www.ietf.org/id/draft-dawes-sipcore-mediasec-parameter-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 11:16:12 -0000 Hello Ben and dispatch chairs, Thanks for taking the time to discuss this draft and give your views. I thi= nk it is important that this "media security" sub-class of security mechani= sms has a registry (either new or existing) and I am certainly willing to d= iscuss and follow up your comments below, and any others that may arise. If= the draft can be revised in such a way that new "media security" mechanism= s are described and scoped consistent with existing similar IETF standards = and can therefore be IANA registered then it's worth doing. Since I started= the draft the IMS has needed to add MSRP to the media protocols that requi= re protection and MIKEY-TICKET (RFC 6043) as a key management option, so a = registry is needed to keep track. Regarding scope, I agree with your comment that the draft applies only to I= MS and IMS-like architectures and I can think about ways to make the scope = more explicit. Regarding security considerations, I can expand on those but= it might help to have specific review comments to work from. Regarding "sp= ecification required" or "RFC required" it would help if someone could poin= t me at any previous occasions where the decision between the two was made,= or any RFCs that give guidelines, so that I can understand the criteria.=20 Thanks again, Peter -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: 22 March 2016 22:45 To: Dawes, Peter, Vodafone Group Cc: dispatch@ietf.org; dispatch-chairs@tools.ietf.org Subject: Re: [dispatch] https://www.ietf.org/id/draft-dawes-sipcore-mediase= c-parameter-03.txt Hi, The ADs and chairs discussed this offline, and we think that this might be = a candidate for AD sponsorship. However, in my opinion as an ART AD, there = are some issues that need to be discussed before going that route (and are = probably relevant however this progresses: 2. The draft creates a "media security" sub-class of security mechanisms th= at are registered in a separate registry with a "specification-required" po= licy. The existing security mechanism registry has a policy of "RFC require= d". I think that's a reasonable policy, given the security implications of = RFC 3329 extensions. In my opinion, this draft should get rid of the separ= ate registry, and put any media-specific mechanism into the existing one. B= ut failing that, the policy on this new registry should be no weaker than t= hat of the existing one. ( If people think "RFC Required" is not the right = policy for either registry, we can discuss that.) 3. The draft assumes that the first hop SIP proxy is also the first hop med= ia-plane device, a la a p-cscf. This may be a reasonable assumption for IMS= and IMS-like architectures, but it's not an assumption we want to encourag= e in general. This could be mitigated by stronger language scoping the work= to IMS, and discouraging its use elsewhere. (This is designed to enable th= e IMS end-to-edge-agent security model, and should probably say so.) 3. There's a fair amount of work left. The security considerations seem ina= dequate, and there are sections that still have xml2rfc sample text.=20 If we progress this, we should get targeted reviews from Gonzalo and/or Jar= i, as well as secdir. So it's only worth trying to progress this if the aut= hors are willing put non-trivial additional work in on it. This is not an exhaustive list--I'm sure other issues will shake out if we = move forward. But I think these are important for figuring out the strategy= for progressing the work. Thanks! Ben. On 10 Feb 2016, at 5:32, Dawes, Peter, Vodafone Group wrote: > Hello All, > I would like to ask dispatch to (re-)consider the proposals in=20 > https://datatracker.ietf.org/doc/draft-dawes-sipcore-mediasec-paramete > r/ and how it might be progressed. One of the sipcore chairs has=20 > indicated that this draft probably does not belong in sipcore and=20 > dispatch did not make a detailed evaluation the first time it was=20 > brought to the group. > > The most recent comments on the sipcore mailing list are=20 > https://mailarchive.ietf.org/arch/msg/sipcore/mD1Qedh93ep9oVOxttIxKN7l > Icg and it might help to repeat part of what I said there about the=20 > new header field parameter that is the reason for the draft: > > "...the header field parameter introduced by this draft originates=20 > from 3GPP specifications and related procedures and header field=20 > values are also described in 3GPP specifications. The purpose of this=20 > draft is to name the header field parameter, give several illustrative=20 > examples to make it clear how it is used, and set up an IANA registry=20 > for existing and future values. The draft does not propose that IETF=20 > defines any new security setup procedures, ciphering, integrity=20 > protection etc." > > Thanks and regards, > Peter > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Mar 24 08:25:41 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818DC12D658 for ; Thu, 24 Mar 2016 03:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 mxy1rjQDWE2O for ; Thu, 24 Mar 2016 03:13:03 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id CFA5A12D6E9 for ; Thu, 24 Mar 2016 03:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1458814379; d=isode.com; s=selector; i=@isode.com; bh=jkxE+28RYEkphaLCny2Q8BUFljHobKOBHKKk8IR6q5A=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=O+g+CBi38RrrlEc08hUAG+Fu+IM70/t7T//E3dIWWOdvjJbMMDDQUgISL1j0EVompM48t0 7NahfOCx4MsgGO8N/8pzGN22nfbGZr0zGBWVQhOXxrq8xahy5OwnTtCc5Zc36zCgewjbUS LNNgwJPx30zFSFSgoWo7ffqq1iN1mqo=; Received: from [10.14.138.209] ((unknown) [85.255.232.206]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 24 Mar 2016 10:12:58 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPhone Mail (13D15) In-Reply-To: <87a8lp10i2.fsf@hobgoblin.ariadne.com> Date: Thu, 24 Mar 2016 10:15:44 +0000 Message-Id: References: <87a8lp10i2.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 24 Mar 2016 08:25:40 -0700 Cc: dispatch@ietf.org Subject: Re: [dispatch] [ietf-smtp] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 10:13:04 -0000 Hi Dale, > On 23 Mar 2016, at 19:02, Dale R. Worley wrote: > > [I'm not sure why this was sent to Dispatch, as it doesn't seem to > involve SIP.] Dispatch is now ART-area-wide, so other ART topics can be brought here. From nobody Fri Mar 25 14:42:16 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4931312D646 for ; Fri, 25 Mar 2016 14:42:15 -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 autolearn_force=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 X3YW9DTaC53V for ; Fri, 25 Mar 2016 14:42:13 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2271C12D5D5 for ; Fri, 25 Mar 2016 14:42:13 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2PLgBp3078178 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 25 Mar 2016 16:42:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Dawes, Peter, Vodafone Group" Date: Fri, 25 Mar 2016 16:42:11 -0500 Message-ID: In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8A25B11@VOEXM31W.internal.vodafone.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C89EE030@VOEXM31W.internal.vodafone.com> <02EE1690-A9A5-4C4B-8E7F-B4A9D628B1F9@nostrum.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8A25B11@VOEXM31W.internal.vodafone.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "dispatch-chairs@tools.ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] https://www.ietf.org/id/draft-dawes-sipcore-mediasec-parameter-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 21:42:15 -0000 Thanks for the response. Some more comments inline: Thanks! Ben. On 24 Mar 2016, at 6:16, Dawes, Peter, Vodafone Group wrote: > Hello Ben and dispatch chairs, > > Thanks for taking the time to discuss this draft and give your views. > I think it is important that this "media security" sub-class of > security mechanisms has a registry (either new or existing) and I am > certainly willing to discuss and follow up your comments below, and > any others that may arise. If the draft can be revised in such a way > that new "media security" mechanisms are described and scoped > consistent with existing similar IETF standards and can therefore be > IANA registered then it's worth doing. Since I started the draft the > IMS has needed to add MSRP to the media protocols that require > protection and MIKEY-TICKET (RFC 6043) as a key management option, so > a registry is needed to keep track. It's probably worth discussion the motivations behind why the draft proposes a separate registry for "media security" mechanisms, rather than just adding new mechanisms to the "Security Mechanism Names" registry from RFC 3329. > > Regarding scope, I agree with your comment that the draft applies only > to IMS and IMS-like architectures and I can think about ways to make > the scope more explicit. That would be helpful. > Regarding security considerations, I can expand on those but it might > help to have specific review comments to work from. Regarding > "specification required" or "RFC required" it would help if someone > could point me at any previous occasions where the decision between > the two was made, or any RFCs that give guidelines, so that I can > understand the criteria. The registration policies are defined in RFC 5226, section 4.1. One previous occasion that is especially relevant is RFC 3329 :-) I have to assume the working group chose the "RFC Required policy" because they wanted to make sure that security mechanisms got sufficient review in the IETF, and that they wanted to make sure the specifications were sufficiently accessible and archived. In any case, the proposed "Media security mechanism" registry is effectively an expansion of the "security mechanism" registry. Given that, if the authors think that the media security mechanism should have a weaker policy, the draft should explain why. > > Thanks again, > Peter > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: 22 March 2016 22:45 > To: Dawes, Peter, Vodafone Group > Cc: dispatch@ietf.org; dispatch-chairs@tools.ietf.org > Subject: Re: [dispatch] > https://www.ietf.org/id/draft-dawes-sipcore-mediasec-parameter-03.txt > > Hi, > > The ADs and chairs discussed this offline, and we think that this > might be a candidate for AD sponsorship. However, in my opinion as an > ART AD, there are some issues that need to be discussed before going > that route (and are probably relevant however this progresses: > > > 2. The draft creates a "media security" sub-class of security > mechanisms that are registered in a separate registry with a > "specification-required" policy. The existing security mechanism > registry has a policy of "RFC required". I think that's a reasonable > policy, given the security implications of RFC 3329 extensions. In my > opinion, this draft should get rid of the separate registry, and put > any media-specific mechanism into the existing one. But failing that, > the policy on this new registry should be no weaker than that of the > existing one. ( If people think "RFC Required" is not the right policy > for either registry, we can discuss that.) > > 3. The draft assumes that the first hop SIP proxy is also the first > hop media-plane device, a la a p-cscf. This may be a reasonable > assumption for IMS and IMS-like architectures, but it's not an > assumption we want to encourage in general. This could be mitigated by > stronger language scoping the work to IMS, and discouraging its use > elsewhere. (This is designed to enable the IMS end-to-edge-agent > security model, and should probably say so.) > > > 3. There's a fair amount of work left. The security considerations > seem inadequate, and there are sections that still have xml2rfc sample > text. > If we progress this, we should get targeted reviews from Gonzalo > and/or Jari, as well as secdir. So it's only worth trying to progress > this if the authors are willing put non-trivial additional work in on > it. > > This is not an exhaustive list--I'm sure other issues will shake out > if we move forward. But I think these are important for figuring out > the strategy for progressing the work. > > Thanks! > > Ben. > > > On 10 Feb 2016, at 5:32, Dawes, Peter, Vodafone Group wrote: > >> Hello All, >> I would like to ask dispatch to (re-)consider the proposals in >> https://datatracker.ietf.org/doc/draft-dawes-sipcore-mediasec-paramete >> r/ and how it might be progressed. One of the sipcore chairs has >> indicated that this draft probably does not belong in sipcore and >> dispatch did not make a detailed evaluation the first time it was >> brought to the group. >> >> The most recent comments on the sipcore mailing list are >> https://mailarchive.ietf.org/arch/msg/sipcore/mD1Qedh93ep9oVOxttIxKN7l >> Icg and it might help to repeat part of what I said there about the >> new header field parameter that is the reason for the draft: >> >> "...the header field parameter introduced by this draft originates >> from 3GPP specifications and related procedures and header field >> values are also described in 3GPP specifications. The purpose of this >> draft is to name the header field parameter, give several >> illustrative >> examples to make it clear how it is used, and set up an IANA registry >> for existing and future values. The draft does not propose that IETF >> defines any new security setup procedures, ciphering, integrity >> protection etc." >> >> Thanks and regards, >> Peter >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri Mar 25 15:30:19 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA38E12D154 for ; Fri, 25 Mar 2016 15:30:17 -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 autolearn_force=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 coSGI7mBVDVB for ; Fri, 25 Mar 2016 15:30:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 17D6912D68F for ; Fri, 25 Mar 2016 15:30:15 -0700 (PDT) Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2PMU8qR081892 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Fri, 25 Mar 2016 17:30:09 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local To: Christer Holmberg , Paul Kyzivat , "dispatch@ietf.org" References: <21379_1458588251_56F04A5B_21379_5094_1_8B970F90C584EA4E97D5BAAC9172DBB81A970D51@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <56F18F74.9050504@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37F040EE@ESESSMB209.ericsson.se> From: Robert Sparks Message-ID: <56F5BBEF.2060204@nostrum.com> Date: Fri, 25 Mar 2016 17:30:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F040EE@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------010702010005070609000800" Archived-At: Subject: Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 22:30:17 -0000 This is a multi-part message in MIME format. --------------010702010005070609000800 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/23/16 1:45 AM, Christer Holmberg wrote: > Hi, > > As far as I remember, in SIP all "repeatable" header fields shall also > be "comma separabable". It would be good to look at the bottom of page 30 of RFC3261 to inform this conversation. In particular: " It MUST be possible to combine the multiple header field rows into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma." > > I can't think of a header field where that would not be the case. "The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy- Authenticate, and Proxy-Authorization header fields." > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Paul Kyzivat > Sent: ‎22/‎03/‎2016 20:31 > To: dispatch@ietf.org > Subject: Re: [dispatch] New draft > draft-mohali-dispatch-originating-cdiv-parameter-00.txt > > Marianne, > > Thank you. This draft is a huge improvement over the prior proposal for > this purpose! > > I don't have a problem with this approach. The draft seems in reasonable > shape. (I didn't read it for nits, as doing that seems premature.) > > One thing I noticed, which is really an issue with rfc5502: > > The P-Served-User header field doesn't seem to have the usual provision > of headers like this for comma-separated repetition. And there is no > mention pro or con regarding whether this header field can be repeated. > Since it can already have both orig and term options, that presumably > can coexist, I guess it can be repeated, but not using comma. Is that > how it is being used in practice? > > It would be wise to clarify the ways in which this header field may be > repeated. (E.g., every usage must have a distinct value of > sessioncase-param.) And if multiple values separated by comma are being > used in practice then the syntax ought to be corrected to allow that. > > Thanks, > Paul > > On 3/21/16 3:24 PM, marianne.mohali@orange.com wrote: > > Hello, > > > > Please find hereafter a new Internet-Draft "P-Served-User Header > Field Parameter for Originating CDIV session case in Session > Initiation Protocol (SIP)". > > The purpose of the draft is to register a new SIP parameter for the > P-Served-User header field defined as per RFC5502. > > > > Abstract: > > This specification defines a new Session Initiation Protocol > (SIP) P- > > Served-User header field parameter, "orig-cdiv-param", which defines > > the session case used by a proxy when handling an originating > session > > after Call Diversion (CDIV) services has been invoked for the served > > user. The P-Served-User header field is defined in [RFC5502]. The > > P-Served-User header field conveys the identity of the served user > > and the session case that applies to this particular communication > > session and application invocation. > > This document updates [RFC5502] in order to add the originating > after > > CDIV session case. > > > > The draft can be found in : > > URL: > https://www.ietf.org/internet-drafts/draft-mohali-dispatch-originating-cdiv-parameter-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-mohali-dispatch-originating-cdiv-parameter/ > > Htmlized: > https://tools.ietf.org/html/draft-mohali-dispatch-originating-cdiv-parameter-00 > > > > Best 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. > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------010702010005070609000800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 3/23/16 1:45 AM, Christer Holmberg wrote:
Hi,

As far as I remember, in SIP all "repeatable" header fields shall also be "comma separabable".
It would be good to look at the bottom of page 30 of RFC3261 to inform this conversation.
In particular:
" It MUST be possible to combine the multiple
   header field rows into one "field-name: field-value" pair, without
   changing the semantics of the message, by appending each subsequent
   field-value to the first, each separated by a comma."


I can't think of a header field where that would not be the case.
"The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy- Authenticate, and Proxy-Authorization header fields."

Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: ‎22/‎03/‎2016 20:31
To: dispatch@ietf.org
Subject: Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt

Marianne,

Thank you. This draft is a huge improvement over the prior proposal for
this purpose!

I don't have a problem with this approach. The draft seems in reasonable
shape. (I didn't read it for nits, as doing that seems premature.)

One thing I noticed, which is really an issue with rfc5502:

The P-Served-User header field doesn't seem to have the usual provision
of headers like this for comma-separated repetition. And there is no
mention pro or con regarding whether this header field can be repeated.
Since it can already have both orig and term options, that presumably
can coexist, I guess it can be repeated, but not using comma. Is that
how it is being used in practice?

It would be wise to clarify the ways in which this header field may be
repeated. (E.g., every usage must have a distinct value of
sessioncase-param.) And if multiple values separated by comma are being
used in practice then the syntax ought to be corrected to allow that.

        Thanks,
        Paul

On 3/21/16 3:24 PM, marianne.mohali@orange.com wrote:
> Hello,
>
> Please find hereafter a new Internet-Draft  "P-Served-User Header Field Parameter for Originating CDIV session case in Session Initiation Protocol (SIP)".
> The purpose of the draft is to register a new SIP parameter for the P-Served-User header field defined as per RFC5502.
>
> Abstract:
>     This specification defines a new Session Initiation Protocol (SIP) P-
>     Served-User header field parameter, "orig-cdiv-param", which defines
>     the session case used by a proxy when handling an originating session
>     after Call Diversion (CDIV) services has been invoked for the served
>     user.  The P-Served-User header field is defined in [RFC5502].  The
>     P-Served-User header field conveys the identity of the served user
>     and the session case that applies to this particular communication
>     session and application invocation.
>     This document updates [RFC5502] in order to add the originating after
>     CDIV session case.
>
> The draft can be found in :
> URL:            https://www.ietf.org/internet-drafts/draft-mohali-dispatch-originating-cdiv-parameter-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-mohali-dispatch-originating-cdiv-parameter/
> Htmlized:       https://tools.ietf.org/html/draft-mohali-dispatch-originating-cdiv-parameter-00
>
> Best 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.
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

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

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

--------------010702010005070609000800-- From nobody Sun Mar 27 22:29:41 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA91D12D684 for ; Sun, 27 Mar 2016 22:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jY9NoDbMym0o for ; Sun, 27 Mar 2016 22:29:38 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 44E6212D683 for ; Sun, 27 Mar 2016 22:29:38 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id e185so143902945vkb.1 for ; Sun, 27 Mar 2016 22:29:38 -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; bh=HSojwCOfWNA+V+QODxTwCE23gkl4qvseyIcxfBz0D+k=; b=IvsegTA7Z1eRN0hzNWrPeVXQcXHUy5U0wWBWMP4p+fQRuDdDmkSziCcre13hJtyRzA Qxcwa2dMIhGhznI/DX/chSPGFx69b/SxlSEbAorXbPn2DuwjMyeBUsDmEotqTIe5ghXa 4W3WE7xQfbZkFH9nm6PZ3BmDRpqxVg/E+suPaQJfMr5Pmfe125+xAqsQO65yXHERrZA3 kT5iIhDgElo7b3WRNx44c8+rAcKubUQurwAv1fV2L1ap5g0V7ZVrOuouyNEE7dbCFd6h l/PdfwO8sAvUO1lS+PLcXCBXWfKGnwpc3PiZy1mp/hxiEn0PMj3ECvuOYJS8c8VmPI5L TE6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=HSojwCOfWNA+V+QODxTwCE23gkl4qvseyIcxfBz0D+k=; b=lY07RiDOnJEWWYuaJdq6t8Jr2Y08T5U4BK3VUpNM9bMuSfMhFTl+LmW46GLoBUdTKe TtRwcbIJXgRhdZCofjWyAV5k8hN2yKZFlVZDrRqQTQ62IilU3+ZMy24sx03BL+Qa9Hkr L39uMgVyULA1cCaqw37XEy1vcSEYJbCo64WYnKaE+r7GOMfDhnLIjVK6AH7fhWs6ALvt LRWjMESUeXb+r0f442ftN6RALHw+r2ziAjRqpVWNCLv3XZhJR1rWUNc7s61CBs047zA+ KTG3WypTw2Vwk8SAN7WV5lutElzMxWoJKX95Ea+UDtP2Qur3C7XtX1KLUJFDxe4odICQ awSQ== X-Gm-Message-State: AD7BkJL9H0YQTdA2vQoPB2D8YwURCXbjEG/mE3OkX1v91ZgDfnz85aiLo90dr/48I2ck0dOuT+Q/5kvIP9kAxg== MIME-Version: 1.0 X-Received: by 10.159.37.101 with SMTP id 92mr13254966uaz.66.1459142977354; Sun, 27 Mar 2016 22:29:37 -0700 (PDT) Received: by 10.103.43.5 with HTTP; Sun, 27 Mar 2016 22:29:37 -0700 (PDT) In-Reply-To: <56F2F0C6.30003@alum.mit.edu> References: <87a8lp10i2.fsf@hobgoblin.ariadne.com> <56F2F0C6.30003@alum.mit.edu> Date: Sun, 27 Mar 2016 22:29:37 -0700 Message-ID: From: "Murray S. Kucherawy" To: Paul Kyzivat Content-Type: multipart/alternative; boundary=94eb2c123f1cd780b9052f1532b9 Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 05:29:40 -0000 --94eb2c123f1cd780b9052f1532b9 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 23, 2016 at 12:38 PM, Paul Kyzivat wrote: > On 3/23/16 3:02 PM, Dale R. Worley wrote: > >> [I'm not sure why this was sent to Dispatch, as it doesn't seem to >> involve SIP.] >> > > dispatch is being rechartered to have scope encompassing all of the ART > area. I *think* this proposal falls in that scope. > (Just to make it somewhat official) This is correct. -MSK, DISPATCH co-chair --94eb2c123f1cd780b9052f1532b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 23, 2016 at 12:38 PM, Paul Kyzivat <pky= zivat@alum.mit.edu> wrote:
On 3= /23/16 3:02 PM, Dale R. Worley wrote:
[I'm not sure why this was sent to Dispatch, as it doesn't seem to<= br> involve SIP.]

 dispatch is being rechartered to have scope encompassing all of the ART are= a. I *think* this proposal falls in that scope.

(Just to make it somewhat official)=C2=A0 This is correct.

=
-MSK, DISPATCH co-chair
--94eb2c123f1cd780b9052f1532b9-- From nobody Sun Mar 27 22:41:09 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA9A12D0A0; Sun, 27 Mar 2016 22:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xta3WpI9RaR9; Sun, 27 Mar 2016 22:41:03 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 F1E8812D67C; Sun, 27 Mar 2016 22:41:02 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id z68so144295508vkg.3; Sun, 27 Mar 2016 22:41:02 -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; bh=ip9I7mqZ7ICQY4EIitr68dYQRWw8Xe5oHx90oqnGFcw=; b=lJNsolByVU7+MKOzf/7NAZqzrAaHu6gpLsfdQzwBokNUc+dh7eLKLMVw/I/Em/PmK7 vSddBaZimJRxA4u76Vi3ZfcUxGPDfUb8PXzxfV+1p8ISxw1M9eNqjJHBDBfQqc9DiDmr eM1mByKuk0AORi/lYanXb9xSwNKNlvtUpocC/vq0i1wavSxxBpGIbJ6Du0hYzU+61suX CtE7ru9WHudQpazArgyyL5haDgAsHjaRMprI3oMGUuyeOo+38qZhF1Ws6w7To8gMNd84 Uc2sR59thf7mAs/41/TjVeCgYWOqn5bBGgb2NhbTZsD+qkDhWEFOIb8MFmzVitVQ6xtc bDSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ip9I7mqZ7ICQY4EIitr68dYQRWw8Xe5oHx90oqnGFcw=; b=ZSmZ1Me71uLu+UQ3MqReA+XwCsMkQSLI7kOnXX75XasH+C/5oXjgt0wrtZX69GA6o+ SJgGPAaWjZdpa++WpgmKk1hAsQaZInFzNzVrELrpNt1A/61TUq4fQqebdP94W1vYKN5Q 1WiOHjUQClEP7NvvVFS4TA39eI86VVmQlIOXixDg6zRnAOMxuQRwBGpFcoTpxI++wVUF kJ2xZmvtgODSgRin8gh7ENsoPUKBmsA8DTXqZNgYr3f7zd2wW683Ed8sZhpBb6j9/tXB znnzBFLhcrqxkiuQvVKg5nN9KQQTADd32G6p0h8n8GeRLiAgUHkHu396anJtNHJfntEp Y8Fw== X-Gm-Message-State: AD7BkJJapUpoksksaXUb9d0Rzp57P5YE+W1TTRAEpjsQDuHJ9dJvce+s+sEZHQS6wsuTRoxklq7d4eCd551psA== MIME-Version: 1.0 X-Received: by 10.31.188.142 with SMTP id m136mr13063855vkf.89.1459143662131; Sun, 27 Mar 2016 22:41:02 -0700 (PDT) Received: by 10.103.43.5 with HTTP; Sun, 27 Mar 2016 22:41:02 -0700 (PDT) In-Reply-To: <56F30A52.50305@seantek.com> References: <87a8lp10i2.fsf@hobgoblin.ariadne.com> <56F30A52.50305@seantek.com> Date: Sun, 27 Mar 2016 22:41:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=001a1143026ea86019052f155bd0 Archived-At: Cc: dispatch@ietf.org, ietf-smtp Subject: Re: [dispatch] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 05:41:05 -0000 --001a1143026ea86019052f155bd0 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 23, 2016 at 2:27 PM, Sean Leonard wrote: > But the terminology needs to be clarified >> at some point: a single document (or sentence) is either normative or >> not. If something is a "best common practice", it is not normative, the >> rules are set somewhere else. >> > > IETF Process issue: > Well, RFC 5646/BCP 47 "Tags for Identifying Languages" is a BCP. However, > it is referred to normatively by a slew of Standards Track documents. I > would propose that this document be seen in a similar light. One would not > expect the Mail Standards to adopt these regular expressions, but other > standards that use regular expressions for e-mail would probably do best to > refer to this document. Examples include CBOR/CDDL > (draft-greevenbosch-appsawg-cbor-cddl), and DNS/NAPTR records (RFCs > 3401-3404), when the subject matter is e-mail stuff. > It seems to me RFC2026's definition of BCP would cover what you're trying to do here. And if what you're really producing is regular expressions that match anything that the ABNFs in the mail RFCs will legitimately produce, you might want to do a standards track document that explicitly updates those documents where those ABNFs are listed. Then again, I could see this just as easily going Informational since it's unlikely (to me, at least) that anyone will point compliance language at such a document. How's that for actionable feedback? :-/ -MSK --001a1143026ea86019052f155bd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 23, 2016 at 2:27 PM, Sean Leonard <dev+iet= f@seantek.com> wrote:


=C2=A0 =C2=A0But the terminology needs to be clarified
at some point:=C2=A0 a single document (or sentence) is either normative or=
not.=C2=A0 If something is a "best common practice", it is not no= rmative, the
rules are set somewhere else.

 IETF Process issue:
Well, RFC 5646/BCP 47 "Tags for Identifying Languages" is a BCP. = However, it is referred to normatively by a slew of Standards Track documen= ts. I would propose that this document be seen in a similar light. One woul= d not expect the Mail Standards to adopt these regular expressions, but oth= er standards that use regular expressions for e-mail would probably do best= to refer to this document. Examples include CBOR/CDDL (draft-greevenbosch-= appsawg-cbor-cddl), and DNS/NAPTR records (RFCs 3401-3404), when the subjec= t matter is e-mail stuff.

It seems to m= e RFC2026's definition of BCP would cover what you're trying to do = here.

And if what you're really producing is regular = expressions that match anything that the ABNFs in the mail RFCs will legiti= mately produce, you might want to do a standards track document that explic= itly updates those documents where those ABNFs are listed.

Then again, I could see this just as easily going Informational since it&= #39;s unlikely (to me, at least) that anyone will point compliance language= at such a document.

How's that for actionable feedba= ck?=C2=A0 :-/

-MSK
--001a1143026ea86019052f155bd0-- From nobody Mon Mar 28 07:42:51 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6949112D93B; Mon, 28 Mar 2016 06:19:09 -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 autolearn_force=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 xHUPK5moIJRC; Mon, 28 Mar 2016 06:19:07 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4E612D932; Mon, 28 Mar 2016 06:19:06 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1akX4R-000FP2-TU; Mon, 28 Mar 2016 09:19:03 -0400 Date: Mon, 28 Mar 2016 09:18:58 -0400 From: John C Klensin To: "Murray S. Kucherawy" , Sean Leonard Message-ID: <0AC7C26B5A969CA50015ACFB@JcK-HP8200.jck.com> In-Reply-To: References: <87a8lp10i2.fsf@hobgoblin.ariadne.com> <56F30A52.50305@seantek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Mon, 28 Mar 2016 07:42:50 -0700 Cc: dispatch@ietf.org, ietf-smtp Subject: Re: [dispatch] [ietf-smtp] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 13:19:09 -0000 --On Sunday, March 27, 2016 22:41 -0700 "Murray S. Kucherawy" wrote: >... > And if what you're really producing is regular expressions > that match anything that the ABNFs in the mail RFCs will > legitimately produce, you might want to do a standards track > document that explicitly updates those documents where those > ABNFs are listed. Murray, That captures my concern about this effort. Based on prior experience (including RFC RFC 3696 and even the effort to make RFCs 2821 and 5321 internally consistent), it is _really_ easy to express a requirement in two different ways and have them be _almost_ the same. That is a problem because different people will read different docs. It seems to me that it would be much better to either do this as an Informational document that is clearly identified as Sean's opinion about regular expressions that impose the same requirements as 5321/5322 but that those continue to control or to do a standards-track document that contains both the regular expressions and ABNF, makes clear which one is primary, and updates the syntax requirements of the base specs. Perhaps a BCP that recommends use of strings that are clearly a proper subset of what the standard allows would be ok, but it needs to be frightfully clear that it is a recommended subset, not a requirement. For example, I've seen enough problems with the two quoting conventions over the years that I'd be delighted to see them eliminated entirely. On the other hand, I've seen one attempt after another (outside the IETF) to reduce the rules to simple regular expressions or equivalent that would forbid subaddresses and/or the required syntax for conversions of addresses from some other systems (the X.400 stuff stands out, even though very few people care about it any more). best. john From nobody Mon Mar 28 17:19:58 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830B812D0E8; Mon, 28 Mar 2016 17:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 IGKlzoS5s7VC; Mon, 28 Mar 2016 17:19:55 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 15F3312D0DF; Mon, 28 Mar 2016 17:19:55 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 76DB850A85; Mon, 28 Mar 2016 20:19:53 -0400 (EDT) To: "Murray S. Kucherawy" , ietf-smtp References: <87a8lp10i2.fsf@hobgoblin.ariadne.com> <56F30A52.50305@seantek.com> From: Sean Leonard Message-ID: <56F9CA83.2030707@seantek.com> Date: Mon, 28 Mar 2016 17:21:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050301090101060209010609" Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 00:19:57 -0000 This is a multi-part message in MIME format. --------------050301090101060209010609 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 3/27/2016 10:41 PM, Murray S. Kucherawy wrote: > On Wed, Mar 23, 2016 at 2:27 PM, Sean Leonard > wrote: > > > But the terminology needs to be clarified > at some point: a single document (or sentence) is either > normative or > not. If something is a "best common practice", it is not > normative, the > rules are set somewhere else. > > > IETF Process issue: > Well, RFC 5646/BCP 47 "Tags for Identifying Languages" is a BCP. > However, it is referred to normatively by a slew of Standards > Track documents. I would propose that this document be seen in a > similar light. One would not expect the Mail Standards to adopt > these regular expressions, but other standards that use regular > expressions for e-mail would probably do best to refer to this > document. Examples include CBOR/CDDL > (draft-greevenbosch-appsawg-cbor-cddl), and DNS/NAPTR records > (RFCs 3401-3404), when the subject matter is e-mail stuff. > > > It seems to me RFC2026's definition of BCP would cover what you're=20 > trying to do here. > > And if what you're really producing is regular expressions that match=20 > anything that the ABNFs in the mail RFCs will legitimately produce,=20 > you might want to do a standards track document that explicitly=20 > updates those documents where those ABNFs are listed. BCP or Standards Track are fine by me. > > Then again, I could see this just as easily going Informational since=20 > it's unlikely (to me, at least) that anyone will point compliance=20 > language at such a document. They said that for RFC 4627, too. :) I will make this easy: not going to pursue Informational status. I=20 foresee compliance language referring to these regular expressions: if=20 not in the IETF, then in other bodies. Any software library that has=20 Internet + regular expression capabilities, would be an example.=20 Consider, for example, the POSIX standard, and the C++ standard library=20 standards. It would be reasonable for web browers/ECMAScript/HTML/DOM to = offer e-mail address validation capabilities at some point in the=20 future, with polyfill to fill in older implementations. Oh wait, they already do that...and badly: https://html.spec.whatwg.org/multipage/forms.html#e-mail-state-(type=3Dem= ail) BCP seems like the best choice. Sean --------------050301090101060209010609 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 3/27/2016 10:41 PM, Murray S. Kucherawy wrote:
On Wed, Mar 23, 2016 at 2:27 PM, Sean Leonard <dev+ietf@seantek.com> wrote:


   But the terminology needs to be clarified
at some point:  a single document (or sentence) is either normative or
not.  If something is a "best common practice", it is not normative, the
rules are set somewhere else.

 IETF Process issue:
Well, RFC 5646/BCP 47 "Tags for Identifying Languages" is a BCP. However, it is referred to normatively by a slew of Standards Track documents. I would propose that this document be seen in a similar light. One would not expect the Mail Standards to adopt these regular expressions, but other standards that use regular expressions for e-mail would probably do best to refer to this document. Examples include CBOR/CDDL (draft-greevenbosch-appsawg-cbor-cddl), and DNS/NAPTR records (RFCs 3401-3404), when the subject matter is e-mail stuff.

It seems to me RFC2026's definition of BCP would cover what you're trying to do here.

And if what you're really producing is regular expressions that match anything that the ABNFs in the mail RFCs will legitimately produce, you might want to do a standards track document that explicitly updates those documents where those ABNFs are listed.

BCP or Standards Track are fine by me.


Then again, I could see this just as easily going Informational since it's unlikely (to me, at least) that anyone will point compliance language at such a document.

They said that for RFC 4627, too. :)

I will make this easy: not going to pursue Informational status. I foresee compliance language referring to these regular expressions: if not in the IETF, then in other bodies. Any software library that has Internet + regular expression capabilities, would be an example. Consider, for example, the POSIX standard, and the C++ standard library standards. It would be reasonable for web browers/ECMAScript/HTML/DOM to offer e-mail address validation capabilities at some point in the future, with polyfill to fill in older implementations.

Oh wait, they already do that...and badly:
https://html.spec.whatwg.org/multipage/forms.html#e-mail-state-(type=email)

BCP seems like the best choice.

Sean
--------------050301090101060209010609-- From nobody Mon Mar 28 17:57:03 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630BD12D1BA; Mon, 28 Mar 2016 17:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lviiTcOPH1DK; Mon, 28 Mar 2016 17:57:00 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 9D25712D195; Mon, 28 Mar 2016 17:57:00 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id g127so933969ywf.2; Mon, 28 Mar 2016 17:57:00 -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; bh=TNpcZiYEVa3hY2KqT3Nk8PIJzBUM98K5lx6VqKmPwrs=; b=rASt02lUYki4fZI/jUFCH+d+evbPdngrD02jtfTdqTUJTbUX/NrrOyUMfYL5/zvQ0v ih2wxegnTqC8QYJprsB3StdSYDNeO+Y/miuqvz0U4fdqsI4OS8glSTP7idc3OoTnAwIC YsvAA9EHBg9FyNx84pdfVMwKIX3Qhl3Y8vWBBKLD6OOFFouz7GmP41bJKnGbKhvjCdor 5oS8XXZaJ62i0949Gq1dnkoo2syeKcM8+cAmoPi2joo0SwTLulJPZjNi0E/OLfebZKxG 6GRdpcB/YpX2jexafIpz74Q0w/zvyqu8ExK6keGeYB4AfOqaNs2D9DxqVLQrwBvKk4Nw +64g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=TNpcZiYEVa3hY2KqT3Nk8PIJzBUM98K5lx6VqKmPwrs=; b=m9D6uKJTsdWkGisQWxczycowo9fu8Y3vDig90+YCU1Mxlew8e9uUMnk6Gbb54Qzlns tn1wNVhdSzAGniZ4XEiABbVSm06NgqwkkMcodMHTJtzFN3b59SRO1SIzUgfoyoWPLI8a dJ9T2xORxkmf1MMDLGzJkLxjYysvxqDUYrMj4tr+y8sVR2uIrQ60mDZAgxYLfJCLlPxF wRzqGujKswSb2JfOn+IiKAvA5AGMV/KpiGDeAXadnQMFpdFDbCP9DJvB6haaYqTvlHRs wOG7G51bOlZCTG3DGLwBcgBmmeGaGVPl3ktKk0ibW7gDUy7bJlVdlv0qNtL+xdD3q76C Wueg== X-Gm-Message-State: AD7BkJLwEqiG2n98D02Pal9ZR5UbGt8LK4C70AGiz3ABjHkGGmqpe14xVF1K5pBz7WRsWiPtFexiKfXZq02Tug== MIME-Version: 1.0 X-Received: by 10.13.212.199 with SMTP id w190mr2326169ywd.229.1459213019875; Mon, 28 Mar 2016 17:56:59 -0700 (PDT) Received: by 10.13.204.71 with HTTP; Mon, 28 Mar 2016 17:56:59 -0700 (PDT) In-Reply-To: <56F9CA83.2030707@seantek.com> References: <87a8lp10i2.fsf@hobgoblin.ariadne.com> <56F30A52.50305@seantek.com> <56F9CA83.2030707@seantek.com> Date: Mon, 28 Mar 2016 17:56:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=001a114fd454b3ab8b052f2581da Archived-At: Cc: dispatch@ietf.org, ietf-smtp Subject: Re: [dispatch] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 00:57:02 -0000 --001a114fd454b3ab8b052f2581da Content-Type: text/plain; charset=UTF-8 On Mon, Mar 28, 2016 at 5:21 PM, Sean Leonard wrote: > I will make this easy: not going to pursue Informational status. I foresee > compliance language referring to these regular expressions: if not in the > IETF, then in other bodies. Any software library that has Internet + > regular expression capabilities, would be an example. Consider, for > example, the POSIX standard, and the C++ standard library standards. It > would be reasonable for web browers/ECMAScript/HTML/DOM to offer e-mail > address validation capabilities at some point in the future, with polyfill > to fill in older implementations. > John Klensin makes a compelling argument that this stuff should actually not be published in a way that's equally normative with the existing standards track documents. I wonder if that compels it in the Informational direction. Your choice of publication status will require some amount of consensus, so your assertion might be premature... ;-) -MSK --001a114fd454b3ab8b052f2581da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 28, 2016 at 5:21 PM, Sean Leonard <dev+iet= f@seantek.com> wrote:
=20 =20 =20
I will = make this easy: not going to pursue Informational status. I foresee compliance language referring to these regular expressions: if not in the IETF, then in other bodies. Any software library that has Internet + regular expression capabilities, would be an example. Consider, for example, the POSIX standard, and the C++ standard library standards. It would be reasonable for web browers/ECMAScript/HTML/DOM to offer e-mail address validation capabilities at some point in the future, with polyfill to fill in older implementations.

John K= lensin makes a compelling argument that this stuff should actually not be p= ublished in a way that's equally normative with the existing standards = track documents.=C2=A0 I wonder if that compels it in the Informational dir= ection.

Your choice of publication status will require so= me amount of consensus, so your assertion might be premature... ;-)

-MSK
--001a114fd454b3ab8b052f2581da-- From nobody Mon Mar 28 23:34:43 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FD712D0E3 for ; Mon, 28 Mar 2016 23:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 CMefbaFNlQHV for ; Mon, 28 Mar 2016 23:34:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FDC12D0C5 for ; Mon, 28 Mar 2016 23:34:39 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 76CF922C42F; Tue, 29 Mar 2016 08:34:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.66]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 55AAC35C048; Tue, 29 Mar 2016 08:34:37 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0279.002; Tue, 29 Mar 2016 08:34:37 +0200 From: To: Paul Kyzivat , Christer Holmberg , "dispatch@ietf.org" Thread-Topic: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt Thread-Index: AQHRhGkLD+IuHzAGKUaPUdte2w2GWJ9mhbuAgAB/r4CACO1f4A== Date: Tue, 29 Mar 2016 06:34:36 +0000 Message-ID: <22571_1459233277_56FA21FD_22571_6152_1_8B970F90C584EA4E97D5BAAC9172DBB81A975829@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <21379_1458588251_56F04A5B_21379_5094_1_8B970F90C584EA4E97D5BAAC9172DBB81A970D51@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <56F18F74.9050504@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37F040EE@ESESSMB209.ericsson.se> <56F2A6C3.6020403@alum.mit.edu> In-Reply-To: <56F2A6C3.6020403@alum.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.29.55718 Archived-At: Subject: Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 06:34:42 -0000 SGkgUGF1bCwNCg0KVGhhbmsgeW91IGZvciB5b3VyIGZlZWRiYWNrIQ0KDQpGcm9tIG15IHZpZXcs IEkgd2FzIHRoaW5raW5nIHRoYXQgb25seSBvbmUgUC1TZXJ2ZWQtVXNlciAod2l0aCBvbmUgc2Vz c2lvbi1jYXNlKSBjYW4gYmUgcHJlc2VudCBpbiBhIHJlcXVlc3QgYXQgdGhlIHNhbWUgdGltZS4N CkVnOiBBIGNhbGxzIEIgd2hpY2ggaGFzIGEgQ0RJViBzZXJ2aWNlLiBUaGUgaW5jb21pbmcgcmVx dWVzdCB0byBCIHdpbGwgY29udGFpbiBhIFAtU2VydmVkLVVzZXIgd2l0aCB0aGUgc2Vzc2lvbiBj YXNlICd0ZXJtJywgdGhlbiB0aGUgQVMgdHJpZ2dlcmluZyBDRElWIHNlcnZpY2Ugd2lsbCByZW1v dmUgdGhpcyBlbnRyeSBjb250YWluaW5nIHRoZSAndGVybScgc2Vzc2lvbiBjYXNlIGFuZCByZXBs YWNlIGl0IGJ5IGEgUC1TZXJ2ZWQtVXNlciAod2l0aCB0aGUgc2FtZSB1c2VyKSBidXQgdGhlICdv cmlnLWNkaXYnIHNlc3Npb24gY2FzZSB0byBpbmRpY2F0ZSB0byB0aGUgUy1DU0NGIHdoaWNoIGlG QyBhcHBseS4NCg0KRm9yIHRoYXQsIEknbSBub3Qgc3VyZSB3ZSBjYW4gaGF2ZSB0aGUgUC1TZXJ2 ZWQtVXNlciByZXBlYXRlZC4gSG93IGRvZXMgdGhlIHJlY2VpdmluZyBlbnRpdHkgd2lsbCBrbm93 IHdoYXQgdG8gZG8gYW5kIGZvciAid2hvIiBpZiB0aGVyZSBhcmUgc2V2ZXJhbCBjaG9pY2VzPw0K DQpCUiwNCk1hcmlhbm5lDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogZGlz cGF0Y2ggW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFBh dWwgS3l6aXZhdA0KRW52b3nDqcKgOiBtZXJjcmVkaSAyMyBtYXJzIDIwMTYgMTU6MjMNCsOAwqA6 IENocmlzdGVyIEhvbG1iZXJnOyBkaXNwYXRjaEBpZXRmLm9yZw0KT2JqZXTCoDogUmU6IFtkaXNw YXRjaF0gTmV3IGRyYWZ0IGRyYWZ0LW1vaGFsaS1kaXNwYXRjaC1vcmlnaW5hdGluZy1jZGl2LXBh cmFtZXRlci0wMC50eHQNCg0KT24gMy8yMy8xNiAyOjQ1IEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3 cm90ZToNCj4gSGksDQo+DQo+IEFzIGZhciBhcyBJIHJlbWVtYmVyLCBpbiBTSVAgYWxsICJyZXBl YXRhYmxlIiBoZWFkZXIgZmllbGRzIHNoYWxsIGFsc28gDQo+IGJlICJjb21tYSBzZXBhcmFiYWJs ZSIuDQo+DQo+IEkgY2FuJ3QgdGhpbmsgb2YgYSBoZWFkZXIgZmllbGQgd2hlcmUgdGhhdCB3b3Vs ZCBub3QgYmUgdGhlIGNhc2UuDQoNClRoZSBoZWFkZXIgZmllbGRzIHdpdGggdGhhdCBwcm9wZXJ0 eSBoYXZlIHN5bnRheCB0byBtYXRjaC4NCg0KVGhlIHN5bnRheCBpbiA1NTAyIGRvZXNuJ3Qgc3Vw cG9ydCB0aGF0IGZvciB0aGlzIGhlYWRlciBmaWVsZC4gSWYgdGhhdCB3YXMgdGhlbiBpbnRlbnQg dGhlbiB0aGUgc3ludGF4IHNob3VsZCBiZSByZXZpc2VkLg0KDQoJVGhhbmtzLA0KCVBhdWwNCg0K PiBSZWdhcmRzLA0KPg0KPiBDaHJpc3Rlcg0KPg0KPiBTZW50IGZyb20gbXkgV2luZG93cyBQaG9u ZQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+IEZyb206IFBhdWwgS3l6aXZhdCA8bWFpbHRvOnBr eXppdmF0QGFsdW0ubWl0LmVkdT4NCj4gU2VudDog4oCOMjIv4oCOMDMv4oCOMjAxNiAyMDozMQ0K PiBUbzogZGlzcGF0Y2hAaWV0Zi5vcmcgPG1haWx0bzpkaXNwYXRjaEBpZXRmLm9yZz4NCj4gU3Vi amVjdDogUmU6IFtkaXNwYXRjaF0gTmV3IGRyYWZ0DQo+IGRyYWZ0LW1vaGFsaS1kaXNwYXRjaC1v cmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlci0wMC50eHQNCj4NCj4gTWFyaWFubmUsDQo+DQo+IFRo YW5rIHlvdS4gVGhpcyBkcmFmdCBpcyBhIGh1Z2UgaW1wcm92ZW1lbnQgb3ZlciB0aGUgcHJpb3Ig cHJvcG9zYWwgDQo+IGZvciB0aGlzIHB1cnBvc2UhDQo+DQo+IEkgZG9uJ3QgaGF2ZSBhIHByb2Js ZW0gd2l0aCB0aGlzIGFwcHJvYWNoLiBUaGUgZHJhZnQgc2VlbXMgaW4gDQo+IHJlYXNvbmFibGUg c2hhcGUuIChJIGRpZG4ndCByZWFkIGl0IGZvciBuaXRzLCBhcyBkb2luZyB0aGF0IHNlZW1zIA0K PiBwcmVtYXR1cmUuKQ0KPg0KPiBPbmUgdGhpbmcgSSBub3RpY2VkLCB3aGljaCBpcyByZWFsbHkg YW4gaXNzdWUgd2l0aCByZmM1NTAyOg0KPg0KPiBUaGUgUC1TZXJ2ZWQtVXNlciBoZWFkZXIgZmll bGQgZG9lc24ndCBzZWVtIHRvIGhhdmUgdGhlIHVzdWFsIA0KPiBwcm92aXNpb24gb2YgaGVhZGVy cyBsaWtlIHRoaXMgZm9yIGNvbW1hLXNlcGFyYXRlZCByZXBldGl0aW9uLiBBbmQgDQo+IHRoZXJl IGlzIG5vIG1lbnRpb24gcHJvIG9yIGNvbiByZWdhcmRpbmcgd2hldGhlciB0aGlzIGhlYWRlciBm aWVsZCBjYW4gYmUgcmVwZWF0ZWQuDQo+IFNpbmNlIGl0IGNhbiBhbHJlYWR5IGhhdmUgYm90aCBv cmlnIGFuZCB0ZXJtIG9wdGlvbnMsIHRoYXQgcHJlc3VtYWJseSANCj4gY2FuIGNvZXhpc3QsIEkg Z3Vlc3MgaXQgY2FuIGJlIHJlcGVhdGVkLCBidXQgbm90IHVzaW5nIGNvbW1hLiBJcyB0aGF0IA0K PiBob3cgaXQgaXMgYmVpbmcgdXNlZCBpbiBwcmFjdGljZT8NCj4NCj4gSXQgd291bGQgYmUgd2lz ZSB0byBjbGFyaWZ5IHRoZSB3YXlzIGluIHdoaWNoIHRoaXMgaGVhZGVyIGZpZWxkIG1heSBiZSAN Cj4gcmVwZWF0ZWQuIChFLmcuLCBldmVyeSB1c2FnZSBtdXN0IGhhdmUgYSBkaXN0aW5jdCB2YWx1 ZSBvZg0KPiBzZXNzaW9uY2FzZS1wYXJhbS4pIEFuZCBpZiBtdWx0aXBsZSB2YWx1ZXMgc2VwYXJh dGVkIGJ5IGNvbW1hIGFyZSANCj4gYmVpbmcgdXNlZCBpbiBwcmFjdGljZSB0aGVuIHRoZSBzeW50 YXggb3VnaHQgdG8gYmUgY29ycmVjdGVkIHRvIGFsbG93IHRoYXQuDQo+DQo+ICAgICAgICAgIFRo YW5rcywNCj4gICAgICAgICAgUGF1bA0KPg0KPiBPbiAzLzIxLzE2IDM6MjQgUE0sIG1hcmlhbm5l Lm1vaGFsaUBvcmFuZ2UuY29tIHdyb3RlOg0KPj4gSGVsbG8sDQo+Pg0KPj4gUGxlYXNlIGZpbmQg aGVyZWFmdGVyIGEgbmV3IEludGVybmV0LURyYWZ0ICAiUC1TZXJ2ZWQtVXNlciBIZWFkZXIgRmll bGQgUGFyYW1ldGVyIGZvciBPcmlnaW5hdGluZyBDRElWIHNlc3Npb24gY2FzZSBpbiBTZXNzaW9u IEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkiLg0KPj4gVGhlIHB1cnBvc2Ugb2YgdGhlIGRyYWZ0 IGlzIHRvIHJlZ2lzdGVyIGEgbmV3IFNJUCBwYXJhbWV0ZXIgZm9yIHRoZSBQLVNlcnZlZC1Vc2Vy IGhlYWRlciBmaWVsZCBkZWZpbmVkIGFzIHBlciBSRkM1NTAyLg0KPj4NCj4+IEFic3RyYWN0Og0K Pj4gICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgbmV3IFNlc3Npb24gSW5pdGlhdGlv biBQcm90b2NvbCAoU0lQKSBQLQ0KPj4gICAgIFNlcnZlZC1Vc2VyIGhlYWRlciBmaWVsZCBwYXJh bWV0ZXIsICJvcmlnLWNkaXYtcGFyYW0iLCB3aGljaCBkZWZpbmVzDQo+PiAgICAgdGhlIHNlc3Np b24gY2FzZSB1c2VkIGJ5IGEgcHJveHkgd2hlbiBoYW5kbGluZyBhbiBvcmlnaW5hdGluZyBzZXNz aW9uDQo+PiAgICAgYWZ0ZXIgQ2FsbCBEaXZlcnNpb24gKENESVYpIHNlcnZpY2VzIGhhcyBiZWVu IGludm9rZWQgZm9yIHRoZSBzZXJ2ZWQNCj4+ICAgICB1c2VyLiAgVGhlIFAtU2VydmVkLVVzZXIg aGVhZGVyIGZpZWxkIGlzIGRlZmluZWQgaW4gW1JGQzU1MDJdLiAgVGhlDQo+PiAgICAgUC1TZXJ2 ZWQtVXNlciBoZWFkZXIgZmllbGQgY29udmV5cyB0aGUgaWRlbnRpdHkgb2YgdGhlIHNlcnZlZCB1 c2VyDQo+PiAgICAgYW5kIHRoZSBzZXNzaW9uIGNhc2UgdGhhdCBhcHBsaWVzIHRvIHRoaXMgcGFy dGljdWxhciBjb21tdW5pY2F0aW9uDQo+PiAgICAgc2Vzc2lvbiBhbmQgYXBwbGljYXRpb24gaW52 b2NhdGlvbi4NCj4+ICAgICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgW1JGQzU1MDJdIGluIG9yZGVy IHRvIGFkZCB0aGUgb3JpZ2luYXRpbmcgYWZ0ZXINCj4+ICAgICBDRElWIHNlc3Npb24gY2FzZS4N Cj4+DQo+PiBUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGluIDoNCj4+IFVSTDpodHRwczovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbW9oYWxpLWRpc3BhdGNoLW9yaWdpbg0KPj4g YXRpbmctY2Rpdi1wYXJhbWV0ZXItMDAudHh0IA0KPj4gU3RhdHVzOmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1vaGFsaS1kaXNwYXRjaC1vcmlnaW5hDQo+PiB0aW5nLWNk aXYtcGFyYW1ldGVyLw0KPj4gSHRtbGl6ZWQ6aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LW1vaGFsaS1kaXNwYXRjaC1vcmlnaW5hdGluDQo+PiBnLWNkaXYtcGFyYW1ldGVyLTAwDQo+ Pg0KPj4gQmVzdCBSZWdhcmRzLA0KPj4gTWFyaWFubmUgTW9oYWxpDQo+Pg0KPj4NCj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4NCj4+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyANCj4+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCANCj4+IGV4cGxvaXRl cyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3Nh Z2UgDQo+PiBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+Pg0KPj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIA0KPj4gcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4+IElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPj4g QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPj4gVGhh bmsgeW91Lg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4+IGRpc3BhdGNoQGlldGYub3JnDQo+ Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCj4+DQo+DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRpc3Bh dGNoIG1haWxpbmcgbGlzdA0KPiBkaXNwYXRjaEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCmRpc3BhdGNo QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNo DQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250 ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNh bnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNp IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50 IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi eSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Tue Mar 29 07:07:59 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E7712D820 for ; Tue, 29 Mar 2016 07:07:57 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 F6_aZxfKpvUL for ; Tue, 29 Mar 2016 07:07:51 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 8C8F212D833 for ; Tue, 29 Mar 2016 07:07:51 -0700 (PDT) Received: by mail-ig0-x233.google.com with SMTP id ma7so34498037igc.0 for ; Tue, 29 Mar 2016 07:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=MiT5B5JGAm+wJyG0OmnUKX3+zMR5+FLENDOSxJZwRPs=; b=rJCKBd2cb6RS2apsYRmWnpIEsAEtdzHf4x6M2t6PrrIOn03EiOHLqqE7kglKFyDml2 6HAE3VZJC0uw8AIpnevNzLHPl9qKbSuUDRN6QMiufXRriXw655KsqTNenwzRYIsnG9Hi +9XNYpHAPbiiXDBEruPTBh80zg8tGvuCNvHe+GiDT0o0EeCFMmyeADMV9Z40MyopL64l ZnK1ayHKv+pA2SUGA3iaYbF1cbXYOu1ujpUwmnLlqcNnc/TYiFQPPktoWqVoFkYFsGjI gVsGFtOcw0W1lNbVvS0HRSw7Zv8/00pXMTcU+SHPphm1bd5gTTIjF2kh0JiuRchUR8Ld I0eQ== 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; bh=MiT5B5JGAm+wJyG0OmnUKX3+zMR5+FLENDOSxJZwRPs=; b=hAKdW7/OtrJ6KxLCdHBPrC7DIP6bqNvHcokG25h6cGfWu5n9KvUZxV14m/BCcBTuJW NMFW5bCqi75+FeInhIpkQDXr0N0zwO1DvgHakn0vnIkEVjFSy/O6VVnNW5/oWSxzfuaP 0ZuSMTETTF99otIyXRvmhPjV9fuyb91YbGQ4T+fSWQ1CG+wX4kIczq3F56TeZyPFUNYn 9LCP/4SPVT4sQ3BxnvGbQA0hdjPizfFFeskZ6Ikmlj0kdSzAFi0ASEK653D0D7t7d8rz Dm2DJdLYWJQHOlBK3muW0Wh0uPOvLAxGLOCdVXiMkI3lK7R9Uvhlpea4tamliofZEq+W WBag== X-Gm-Message-State: AD7BkJKWHKCLbjnZvNkHoLswDoDeZQfR4XvoB9MaPPqHGzgbSEFmCKSrilH4B0SSGDPtCONk3UQCbN0BjH6+WRlD X-Received: by 10.50.111.8 with SMTP id ie8mr16397670igb.46.1459260470895; Tue, 29 Mar 2016 07:07:50 -0700 (PDT) From: Brett Tate References: d50f75327ab8843f911520a74372f33a@mail.gmail.com In-Reply-To: d50f75327ab8843f911520a74372f33a@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGFLKUn7pBcj0z4RBmzP+jh+8We2gElrkVA Date: Tue, 29 Mar 2016 10:07:50 -0400 Message-ID: <12f8e2ad9f7e9f28abac7aba96bea50d@mail.gmail.com> To: marianne.mohali@orange.com, dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dispatch] draft-mohali-dispatch-originating-cdiv-parameter: question/comment X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 14:07:58 -0000 Hi, You can ignore my question/comment since it is likely better to address through errata. I created errata ID 4648. http://www.rfc-editor.org/errata_search.php?rfc=5502&eid=4648 Thanks, Brett > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Wednesday, March 23, 2016 1:53 PM > To: 'marianne.mohali@orange.com'; 'dispatch@ietf.org' > Subject: draft-mohali-dispatch-originating-cdiv-parameter: question/comment > > Hi, > > Since draft-mohali-dispatch-originating-cdiv-parameter is updating RFC 5502, > should the draft be updated to include the missing rule concerning when name- > addr must be used? > > As mentioned within the following email from 2013, RFC 5502 does not indicate > to use the RFC 3261 section 20 bracket rule (or provide a similar rule). > Without such a rule, it is ambiguous if parameters decode as part of > PServedUser-value or served-user-param. > > http://www.ietf.org/mail-archive/web/sipcore/current/msg05731.html > > Thanks, > Brett From nobody Tue Mar 29 08:09:16 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEF012D910 for ; Tue, 29 Mar 2016 08:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 BNH_dAonJUNI for ; Tue, 29 Mar 2016 08:09:12 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (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 9344212D900 for ; Tue, 29 Mar 2016 08:09:06 -0700 (PDT) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by comcast with SMTP id kvFtahNxEVrUDkvGUatY1K; Tue, 29 Mar 2016 15:09:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459264146; bh=LGxpSSLoIoW05m/nmIOOmUQGa1QO1lkZNoizfZqOohA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=VphxdoZVPC0Vsm38tirIg1viI0Os4Mz9Vm0jdxOL5hqiyCZovAv2dyteeQSwR8p6d 97lW/InR7rrV2/Z727fVODeZ1NZP1UO6qVZAHn4IROx/c8RhcOx7f3Y0mPyBRVBy8y G3x3Cxu0lqayz4CtXEvEtAFk3RqrPC+bQVbbWynNe1JsUYFe8VcZraui2sHpQBWgg6 SuWMauOg3WxeAcJN4enHvFBiZuUGgQSKGFiRqOaDnIEaUdJMiWn3kwEqBWT70+t9rI OCPjWtnmc/c2WpAfwthqRTTKjhCz7oYWxmkz7yed7+4nXwQ6zrp5CcjzyXy2EKnrDJ 8JIYhoNkG7Exg== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-11v.sys.comcast.net with comcast id br951s0023KdFy101r95Zo; Tue, 29 Mar 2016 15:09:05 +0000 To: marianne.mohali@orange.com, Christer Holmberg , "dispatch@ietf.org" References: <21379_1458588251_56F04A5B_21379_5094_1_8B970F90C584EA4E97D5BAAC9172DBB81A970D51@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <56F18F74.9050504@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37F040EE@ESESSMB209.ericsson.se> <56F2A6C3.6020403@alum.mit.edu> <22571_1459233277_56FA21FD_22571_6152_1_8B970F90C584EA4E97D5BAAC9172DBB81A975829@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Paul Kyzivat Message-ID: <56FA9A90.4080702@alum.mit.edu> Date: Tue, 29 Mar 2016 11:09:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <22571_1459233277_56FA21FD_22571_6152_1_8B970F90C584EA4E97D5BAAC9172DBB81A975829@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 15:09:14 -0000 On 3/29/16 2:34 AM, marianne.mohali@orange.com wrote: > Hi Paul, > > Thank you for your feedback! > > From my view, I was thinking that only one P-Served-User (with one session-case) can be present in a request at the same time. > Eg: A calls B which has a CDIV service. The incoming request to B will contain a P-Served-User with the session case 'term', then the AS triggering CDIV service will remove this entry containing the 'term' session case and replace it by a P-Served-User (with the same user) but the 'orig-cdiv' session case to indicate to the S-CSCF which iFC apply. > > For that, I'm not sure we can have the P-Served-User repeated. How does the receiving entity will know what to do and for "who" if there are several choices? I'm just going by what I read - I don't otherwise know how you imagine it being used. If you think there can be only one instance of this header field at a time, and it might be revised/replaced/removed along the way, then it would be good to say that. I was thinking that you might have multiple instances with different modifiers, indicating different *kinds* of served users. Thanks, Paul > BR, > Marianne > > -----Message d'origine----- > De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de Paul Kyzivat > Envoyé : mercredi 23 mars 2016 15:23 > À : Christer Holmberg; dispatch@ietf.org > Objet : Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt > > On 3/23/16 2:45 AM, Christer Holmberg wrote: >> Hi, >> >> As far as I remember, in SIP all "repeatable" header fields shall also >> be "comma separabable". >> >> I can't think of a header field where that would not be the case. > > The header fields with that property have syntax to match. > > The syntax in 5502 doesn't support that for this header field. If that was then intent then the syntax should be revised. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ---------------------------------------------------------------------- >> -- >> From: Paul Kyzivat >> Sent: ‎22/‎03/‎2016 20:31 >> To: dispatch@ietf.org >> Subject: Re: [dispatch] New draft >> draft-mohali-dispatch-originating-cdiv-parameter-00.txt >> >> Marianne, >> >> Thank you. This draft is a huge improvement over the prior proposal >> for this purpose! >> >> I don't have a problem with this approach. The draft seems in >> reasonable shape. (I didn't read it for nits, as doing that seems >> premature.) >> >> One thing I noticed, which is really an issue with rfc5502: >> >> The P-Served-User header field doesn't seem to have the usual >> provision of headers like this for comma-separated repetition. And >> there is no mention pro or con regarding whether this header field can be repeated. >> Since it can already have both orig and term options, that presumably >> can coexist, I guess it can be repeated, but not using comma. Is that >> how it is being used in practice? >> >> It would be wise to clarify the ways in which this header field may be >> repeated. (E.g., every usage must have a distinct value of >> sessioncase-param.) And if multiple values separated by comma are >> being used in practice then the syntax ought to be corrected to allow that. >> >> Thanks, >> Paul >> >> On 3/21/16 3:24 PM, marianne.mohali@orange.com wrote: >>> Hello, >>> >>> Please find hereafter a new Internet-Draft "P-Served-User Header Field Parameter for Originating CDIV session case in Session Initiation Protocol (SIP)". >>> The purpose of the draft is to register a new SIP parameter for the P-Served-User header field defined as per RFC5502. >>> >>> Abstract: >>> This specification defines a new Session Initiation Protocol (SIP) P- >>> Served-User header field parameter, "orig-cdiv-param", which defines >>> the session case used by a proxy when handling an originating session >>> after Call Diversion (CDIV) services has been invoked for the served >>> user. The P-Served-User header field is defined in [RFC5502]. The >>> P-Served-User header field conveys the identity of the served user >>> and the session case that applies to this particular communication >>> session and application invocation. >>> This document updates [RFC5502] in order to add the originating after >>> CDIV session case. >>> >>> The draft can be found in : >>> URL:https://www.ietf.org/internet-drafts/draft-mohali-dispatch-origin >>> ating-cdiv-parameter-00.txt >>> Status:https://datatracker.ietf.org/doc/draft-mohali-dispatch-origina >>> ting-cdiv-parameter/ >>> Htmlized:https://tools.ietf.org/html/draft-mohali-dispatch-originatin >>> g-cdiv-parameter-00 >>> >>> Best 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. >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _________________________________________________________________________________________________________________________ > > 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. > From nobody Tue Mar 29 08:45:20 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C7A12D844 for ; Tue, 29 Mar 2016 08:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 x2igRDsMLYcJ for ; Tue, 29 Mar 2016 08:45:17 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 6E22412D94C for ; Tue, 29 Mar 2016 08:45:11 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by comcast with SMTP id kvoIadWoqP19gkvpOa4yoz; Tue, 29 Mar 2016 15:45:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459266310; bh=hnzlvtw0h6ATkL2VV7CoYI6iGrBod0z9HE7d2JTOYIs=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=GgS8XGd17p01nlFQXq+FU4y6EfX+XciNoyCAjYtA17uvo82MIxv6oNzvF0xQZYtzY kumq0IUqczLtZvWoTGmGIauLwSVyMEoxzaYaEMlCBBIYO/APJRzk+6SUdf7cr+zyGu ec8/gy20GgDnhxRSD7weWyeHbP1oh7fQbnm1xPcTN1fu+JdcnDExL+8WN0tOn9DFy7 9wlJrlgzVrKCv/xlR8+Ky+XIZumg2XgyXHwmX7Y1o94W4H16i/I2XVyRmbn7PjFOWV lwzs6eBnpXpRsHzKUAHlJmaJc2XCzWWH44ncm/IFWeAGCPjHtOP4YEaRuajoxTL1Oa /pOVmrbSsfukQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-02v.sys.comcast.net with comcast id brl91s00N1nMCLR01rlAzA; Tue, 29 Mar 2016 15:45:10 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u2TFj9CU006584; Tue, 29 Mar 2016 11:45:09 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u2TFj92L006577; Tue, 29 Mar 2016 11:45:09 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Sean Leonard In-Reply-To: <56F30A52.50305@seantek.com> (dev+ietf@seantek.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 29 Mar 2016 11:45:09 -0400 Message-ID: <8760w5xp8a.fsf@hobgoblin.ariadne.com> Archived-At: Cc: dispatch@ietf.org, ietf-smtp@ietf.org Subject: Re: [dispatch] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 15:45:18 -0000 Sean Leonard writes: > When I raised the classification issue during initial development, one > advisor said something to the effect of oh, so it's like a Real BCP, > where it actually prescribes actual Best Current Practices, unlike what > most of the BCPs these days are. (Whatever that means, just the messenger!) In re Dispatch, I knew that its scope had been broadened, but had forgotten that. In re "BCP", the reference is RFC 2026 section 5, "The Internet Standards Process -- Revision 3" ... which is itself a BCP. What it says is that BCPs are *standards* not for protocols but for *things that people do*. So in regard to your draft, the "thing that people do" is "write code that validates e-mail addresses for further processing". And the point of your draft is that people need to write correct code for validating e-mail addresses. Here's another ugly little bit of processing: On some systems, library routines that convert dotted-number IP address strings into four-octet format treat a component that starts with "0" as being written in octal. E.g., "010.010.010.010" is equivalent to "8.8.8.8". (Try executing "dig ietf.org @010.010.010.010" on a Linux system.) As far as I know, this isn't *specified* anywhere in the RFCs, and some RFCs (e.g., RFC 997) have leading zeros on numbers that contain "9". So it's worth warning people not to use leading zeros in IPv4 addresses. I can see a lot of value in cleaning up this mess. If it's possible to not make (many) systems stop working, it would be worth making the new version normatively update the existing specs. Dale From nobody Tue Mar 29 09:34:51 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CF112DC4B; Tue, 29 Mar 2016 09:34:46 -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 autolearn_force=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 IGLioiFPdRQe; Tue, 29 Mar 2016 09:34:39 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BA6812D9EC; Tue, 29 Mar 2016 09:28:26 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1akwV9-000Jpj-45; Tue, 29 Mar 2016 12:28:19 -0400 Date: Tue, 29 Mar 2016 12:28:14 -0400 From: John C Klensin To: "Dale R. Worley" , Sean Leonard Message-ID: <158468C8650CEFDE15AD3A0D@JcK-HP8200.jck.com> In-Reply-To: <8760w5xp8a.fsf@hobgoblin.ariadne.com> References: <8760w5xp8a.fsf@hobgoblin.ariadne.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: dispatch@ietf.org, ietf-smtp@ietf.org Subject: Re: [dispatch] [ietf-smtp] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 16:34:46 -0000 --On Tuesday, March 29, 2016 11:45 -0400 "Dale R. Worley" wrote: >... > Here's another ugly little bit of processing: On some > systems, library routines that convert dotted-number IP > address strings into four-octet format treat a component that > starts with "0" as being written in octal. E.g., > "010.010.010.010" is equivalent to "8.8.8.8". (Try executing > "dig ietf.org @010.010.010.010" on a Linux system.) As far as > I know, this isn't *specified* anywhere in the RFCs, and some > RFCs (e.g., RFC 997) have leading zeros on numbers that > contain "9". So it's worth warning people not to use leading > zeros in IPv4 addresses. And that comment identifies another ugly little issue. An email address of example-user@010.010.010.010 implies that "010.010.010.010" is a domain name and "010" (the rightmost label) is a TLD. Because there is no such TLD (nor is there one for "8."), such an address is an error, so, if a mail-related regular expression document pursues that question at all, it would allow something that violated 5321 no matter whether 010 is interpreted as "2", "8", "10", "16", STX, Backspace, DLE, or something else. I'm not suggesting Sean would do that, only emphasizing (again) the dangers of developing a second spec (or two specs more generally) that is inadvertently not quite consistent with the other one. john From nobody Tue Mar 29 11:40:28 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B5912DFFA; Tue, 29 Mar 2016 11:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 2qBaF6xuek2X; Tue, 29 Mar 2016 11:40:22 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 5353E12E0EC; Tue, 29 Mar 2016 11:10:35 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BE0CE509B6; Tue, 29 Mar 2016 14:10:33 -0400 (EDT) To: John C Klensin , dispatch@ietf.org, ietf-smtp References: <87a8lp10i2.fsf@hobgoblin.ariadne.com> <56F30A52.50305@seantek.com> <0AC7C26B5A969CA50015ACFB@JcK-HP8200.jck.com> From: Sean Leonard Message-ID: <56FAC574.1010503@seantek.com> Date: Tue, 29 Mar 2016 11:12:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <0AC7C26B5A969CA50015ACFB@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dispatch] [ietf-smtp] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 18:40:25 -0000 On 3/28/2016 6:18 AM, John C Klensin wrote: > > --On Sunday, March 27, 2016 22:41 -0700 "Murray S. Kucherawy" > wrote: > >> ... >> And if what you're really producing is regular expressions >> that match anything that the ABNFs in the mail RFCs will >> legitimately produce, you might want to do a standards track >> document that explicitly updates those documents where those >> ABNFs are listed. > Murray, > > That captures my concern about this effort. Based on prior > experience (including RFC RFC 3696 and even the effort to make > RFCs 2821 and 5321 internally consistent), it is _really_ easy > to express a requirement in two different ways and have them be > _almost_ the same. That is a problem because different people > will read different docs. > > It seems to me that it would be much better to either do this as > an Informational document that is clearly identified as Sean's > opinion about regular expressions that impose the same > requirements as 5321/5322 but that those continue to control or > to do a standards-track document that contains both the regular > expressions and ABNF, makes clear which one is primary, and > updates the syntax requirements of the base specs. As Dale expressed (thanks!), "BCPs are *standards* not for protocols but = for *things that people do*. So in regard to=20 [draft-seantek-mail-regexen], the "thing that people do" is "write code=20 that validates e-mail addresses for further processing". And the point=20 [...] is that people need to write correct code for validating e-mail=20 addresses." Sean's opinion about regular expressions for Mail Identifiers (email=20 addresses, Message-IDs) is not interesting. If my opinion were all that=20 interesting, I would just publish it on Stack Overflow and call it a day = (see SO Questions [46155] and [201323]). What is interesting is the=20 IETF's vetted and (rough)-consensus view on the topic. This topic is a favorite pet project of programmers. It tends to go: 1) "oh, I know what an email address is! It has dots and alphas and=20 maybe a hyphen" (WRONG), 2) "oh, I'll just read RFC 5322 and roll my own" (also wrong, but in=20 more subtle ways...for one, RFC 5322 has distinct syntax from RFC 5321), = or 3) "I'm lazy, let's just copy whatever regex shows up on Google first"=20 (pragmatic, usually not right). Wouldn't it be better if programmers could uniformly go: 4) "Given my email address recognition problem, I'll just copy the regex = from BCP xyz", rather than spending dozens if not hundreds of hours=20 pouring over email standards documents and testing them against millions = of arcane email address combinations. The current draft-seantek-mail-regexen is pretty clear (currently) that=20 it does not attempt to change the Mail standards. If folks want to=20 change those documents, may I suggest a separate Standards Track=20 document that does exactly that. Just because a document is labeled "BCP" (or, for that matter,=20 "Standards Track") does not mean that every last single statement in the = document is normative and error-free. Otherwise, the RFC 3280 and RFC=20 5280 PKIX standards that say that you are supposed to compare an entire=20 email address case-insensitively (Section 4.1.2.6 of RFC 3280, Section=20 4.2.1.6 of RFC 5280) would have overridden RFCs 5322, 5321, 2822, RFC=20 2821, etc. etc. We have an errata process. Basically if the regular expressions are wrong, they need to be made=20 right. One can complain about problems, or one can fix them. Turns out that regular expressions and ABNF are homomorphic under=20 certain conditions. As shown in draft-seantek-mail-regexen, "deliverable = email addresses" (RFC 5321 + RFC 6531) certainly fall in that=20 definition, as they can be expressed in a regular language (i.e.,=20 computed with a finite state automaton). Therefore, translating between=20 the two is basically computationally verifiable. The results may not=20 look pretty but they will work. Perhaps a bigger problem is one's view=20 as to how normative ABNF is in the context of IETF standards documents.=20 It is possible to have ABNF that says somename =3D *(ALPHA / DIGIT) but=20 then have normative text that says that is limited to 31=20 characters and MUST start with an alphabetic character. Moreover, some=20 ABNF (RFC 5321 / RFC 5322 in particular) have "obsolete syntax"; whether = to admit such syntax is a highly context-sensitive engineering decision. = Addressing all of these points requires rubbing more than two brain=20 cells together. [46155]:=20 http://stackoverflow.com/questions/46155/validate-email-address-in-javasc= ript [201323]:=20 http://stackoverflow.com/questions/201323/using-a-regular-expression-to-v= alidate-an-email-address > > Perhaps a BCP that recommends use of strings that are clearly a > proper subset of what the standard allows would be ok, but it > needs to be frightfully clear that it is a recommended subset, > not a requirement. I am not really interested in subsets, except those subsets driven by=20 the standards themselves. (ASCII-only vs. EAI is a reasonable subset,=20 provided that both expressions are provided. I would rather do EAI-only=20 but we can be pragmatic about that.) Best regards, Sean From nobody Tue Mar 29 12:05:37 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF7512DB8E; Tue, 29 Mar 2016 12:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 UHljU_BDWb6t; Tue, 29 Mar 2016 12:05:27 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 7D26512DFAA; Tue, 29 Mar 2016 11:30:08 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 91282509B5; Tue, 29 Mar 2016 14:30:06 -0400 (EDT) To: John C Klensin , "Dale R. Worley" References: <8760w5xp8a.fsf@hobgoblin.ariadne.com> <158468C8650CEFDE15AD3A0D@JcK-HP8200.jck.com> From: Sean Leonard Message-ID: <56FACA08.5000909@seantek.com> Date: Tue, 29 Mar 2016 11:31:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <158468C8650CEFDE15AD3A0D@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dispatch@ietf.org, ietf-smtp@ietf.org Subject: Re: [dispatch] [ietf-smtp] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 19:05:34 -0000 On 3/29/2016 9:28 AM, John C Klensin wrote: > > --On Tuesday, March 29, 2016 11:45 -0400 "Dale R. Worley" > wrote: > >> ... >> Here's another ugly little bit of processing: On some >> systems, library routines that convert dotted-number IP >> address strings into four-octet format treat a component that >> starts with "0" as being written in octal. E.g., >> "010.010.010.010" is equivalent to "8.8.8.8". (Try executing >> "dig ietf.org @010.010.010.010" on a Linux system.) As far as >> I know, this isn't *specified* anywhere in the RFCs, and some >> RFCs (e.g., RFC 997) have leading zeros on numbers that >> contain "9". So it's worth warning people not to use leading >> zeros in IPv4 addresses. > And that comment identifies another ugly little issue. An email > address of example-user@010.010.010.010 implies that > "010.010.010.010" is a domain name and "010" (the rightmost > label) is a TLD. Because there is no such TLD (nor is there > one for "8."), such an address is an error, so, if a > mail-related regular expression document pursues that question > at all, it would allow something that violated 5321 no matter > whether 010 is interpreted as "2", "8", "10", "16", STX, > Backspace, DLE, or something else. > > I'm not suggesting Sean would do that, Covered that already. ;-) See the pattern "restricts out all-numeric=20 labels [RFC1912]" in Section 3.1.3. I hope that this does go to show that raw/blind application of the ABNF=20 in RFC 5321/5322 is not sufficient. > only emphasizing (again) > the dangers of developing a second spec (or two specs more > generally) that is inadvertently not quite consistent with the > other one. The danger is real, and noting it is appreciated. It's worth considering = that we are not talking about one spec, but two families of specs (the=20 email specs and the DNS specs) that we need to summarize and put together= =2E It turns out that the domain part is 50% of an email address but=20 generates perhaps 85% of the complexity. The quoting rules for=20 local-part are arcane but at least are fairly systematic. There is a=20 question about how much it's the responsibility of an "email address=20 validator" to validate the domain part. I do not wish to answer this question in isolation. On the one hand,=20 it's usually a DNS library's "job" to answer that (not an email library=20 per-se); on the other hand, if it's not a good domain name, the email=20 address is literally pointing to an imaginary place. The answer is, I=20 suppose, "it depends" and the Best Current Practice is to document the=20 issue so qualified engineers can make sound judgments about what to do.=20 I would analogize this to a US Postal Service validator, validating=20 two-letter state-and-political-division abbreviations. Every=20 state-or-political-division has a two-character alphanumeric code:=20 enforcing the two-character requirement and the alphabetic requirement=20 in a validator would be separately reasonable if the relevant USPS=20 standards promise the same. However, avoiding repeated characters (AA,=20 BB, CC) seems to be more of a registration practice/requirement, so a=20 validator need not impose such a requirement if the relevant standards=20 do not call for it. Regards, Sean From nobody Tue Mar 29 13:14:20 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A446812DE7D; Tue, 29 Mar 2016 13:14:18 -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 autolearn_force=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 baoc8jDOXmQT; Tue, 29 Mar 2016 13:14:16 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F5812DDFA; Tue, 29 Mar 2016 12:39:06 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1akzTk-000KLq-Cr; Tue, 29 Mar 2016 15:39:04 -0400 Date: Tue, 29 Mar 2016 15:38:59 -0400 From: John C Klensin To: Sean Leonard , "Dale R. Worley" Message-ID: <1470E5C228A55B3E9D4AE851@JcK-HP8200.jck.com> In-Reply-To: <56FACA08.5000909@seantek.com> References: <8760w5xp8a.fsf@hobgoblin.ariadne.com> <158468C8650CEFDE15AD3A0D@JcK-HP8200.jck.com> <56FACA08.5000909@seantek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: dispatch@ietf.org, ietf-smtp@ietf.org Subject: Re: [dispatch] [ietf-smtp] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 20:14:18 -0000 --On Tuesday, March 29, 2016 11:31 -0700 Sean Leonard wrote: >... > I hope that this does go to show that raw/blind application of > the ABNF in RFC 5321/5322 is not sufficient. Sorry, but the ABNF in 5321/2821 and the BNF in 821 have _never_ been sufficient to define the grammar in complete and closed form. It sets some structure and bounds on the grammar, but the prose explanations and details are at least as important. If you don't think the RFC makes that clear, please file an erratum -- it might even motivate me to take 5321bis out of long-term storage (although that is definitely not a promise -- the aggravation costs are provably very high). >... > The danger is real, and noting it is appreciated. It's worth > considering that we are not talking about one spec, but two > families of specs (the email specs and the DNS specs) that we > need to summarize and put together. Actually five families if you want to do a comprehensive job: - 5321, possibly with nods to its predecessors - 5322 which, as you point out, is not the same as 5321 (and most, if not all, of the differences are intentional) - the EAI family - the base DNS spec family, as updated - the IDNA family (2003, 2008, and maybe assorted mapping and deviant (i.e., encouraging something that violates IDNA2008) > It turns out that the domain part is 50% of an email address > but generates perhaps 85% of the complexity. The quoting rules > for local-part are arcane but at least are fairly systematic. > There is a question about how much it's the responsibility of > an "email address validator" to validate the domain part. If one believes in IDNA2008 --which there is some obligation to do until it is replaced or deprecated-- then there are actually some very clear validation rules. > I do not wish to answer this question in isolation. On the one > hand, it's usually a DNS library's "job" to answer that (not > an email library per-se); on the other hand, if it's not a > good domain name, the email address is literally pointing to > an imaginary place. The answer is, I suppose, "it depends" and > the Best Current Practice is to document the issue so > qualified engineers can make sound judgments about what to do. > I would analogize this to a US Postal Service validator, > validating two-letter state-and-political-division > abbreviations. Every state-or-political-division has a > two-character alphanumeric code: enforcing the two-character > requirement and the alphabetic requirement in a validator > would be separately reasonable if the relevant USPS standards > promise the same. However, avoiding repeated characters (AA, > BB, CC) seems to be more of a registration > practice/requirement, so a validator need not impose such a > requirement if the relevant standards do not call for it. Right. And that isn't actually a common practice at the second or third level or below in most domains. There, within other constraints that are documented, the rule tends to be either "you get whatever you want and can pay for" or "you get whatever you can convince the zone admin is reasonable". best, john From nobody Wed Mar 30 03:07:59 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2087412D5F6; Wed, 30 Mar 2016 03:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com 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 cZEJ0lIOhrew; Wed, 30 Mar 2016 03:07:55 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0110.outbound.protection.outlook.com [104.47.125.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA9212D5A4; Wed, 30 Mar 2016 03:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sT8ZwIDn/nHnOC9bQXSi9E9rJwAGYFmQ0jpnvY2cZ60=; b=A055mowQke+icnGg+OQxo+h3oRKjZioGh5JZFSAtXGchSWMoBitVJHogBngnC2Vo/evq1jjwWSOyypToDYPglIdSF+yn5nOK7ALffiaErKKo6VFRnUSymxCDqJeA0cQCqguJI0nX7E2BWztpN+uFZm1Xw7/EGBpTH1vDB5Ebdbc= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0921.jpnprd01.prod.outlook.com (10.167.156.151) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 30 Mar 2016 10:07:49 +0000 To: Sean Leonard , "Murray S. Kucherawy" , ietf-smtp References: <87a8lp10i2.fsf@hobgoblin.ariadne.com> <56F30A52.50305@seantek.com> <56F9CA83.2030707@seantek.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56FBA574.3010909@it.aoyama.ac.jp> Date: Wed, 30 Mar 2016 19:07:48 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56F9CA83.2030707@seantek.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS1PR01CA0036.jpnprd01.prod.outlook.com (10.164.162.18) To TY1PR01MB0921.jpnprd01.prod.outlook.com (10.167.156.151) X-MS-Office365-Filtering-Correlation-Id: 552c1286-d5d4-4b65-c4cb-08d358832640 X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0921; 2:S7Wz9NAIZYL09fISK3o2CocoACOY/ISasovgA/jM876Ux4Pvw74Vhwf6EKBe4sN51GtWlnUamROheK/e074sUyT5akIyIotBIilMVAN4xiBiQJShuhEYcJbXABf9jnihw6QJ2KLMNsiTzyMhh1j0j57SqUvMnZukukoD82VYr1o5veJwGXE6pVzl7KDM2Q0T; 3:CQ8BGUaqd7Yz+6gZRoumglHv6gTz6fC15MzFaxZjDI3qfWGgwfJshAdXXBjOiK5pnDqhsoOGsmPRKEe+BJGG6Tqe2EMrrVm4PKolRtiQRMWiB6UMi8x+TiX+z25bdQLV X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0921; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0921; 25:r9o+wxj1VqCiC2vofi+eSXBkn/8fhlZdurcmvYjGt4z0ntvPMGcC0rPkbxT8RrcbzPu47ldovnSGZLwBaeOKr5Uzzc0ZBC+uHPzQYdrNXWJNBsK3hEXM5qHp0NjvSXKWAuKw3p562zhKfuGwPFcNtM6oPeIvw21nXI7VxDQ2I+nvBQHPOhMPbxZm1FgO3K0DB0cYIfGTeJ1mHR2RZzJ4PEYF4sfa1bzaAZN1EGXKo1BEu6NJ/It5uZ25NCAs3DehQ7Me3zML9wNUAsbNdK/aooRYIQISnADb0jL+ry6W1PZBUiY7hSaFln1Cqppqkggd34WrwIVlEHctDaaACMhywRJ5MXEx5tmObzL72CmOlQdg2TBHwnRf/QqNTEjM26F/CCq3oOJ0wjvF/o7u/TdtAYTk4t9Bj8LL3jYs0lRhkURiBa6ejU2Oc9fh1HtkdsT1dUEN1+EToiMTo2cYEGk4yOzAxfEscq/4LtLq+bfJKd3Wf+Ji+8XNr9NMx3CKDxECrN4l/QNmNcIL85jYKMgl/sbQgoFkZkkT9wZUdgov3Vee8p2nnX4qTljEdkqPoIWlsPhcuHLCHlA1bIfa2MZ99FTk4/pgP5xt7A61GPWoAYxUnzPICgWj8TNJHC+3YV5E2aQnQ+OFune6MqB8dXeMiXC7YWwu6918e623mGv7kIb9gIbqUMDpstclPrpxWaHKiIKoE83+ZQVXhVLJV2YHfw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040046)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041046)(6043046)(6042046); SRVR:TY1PR01MB0921; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0921; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0921; 4:GNlHesbVMDS54mWK/ZvAcMz7Sjs3fNKU3WgInVy9TEJJGVN8JYZ5IwAoEMRNNxxXbGUdSxTWdYS02cBxBV2iONrjtwxNb/IT5CImIDNVj2sTwuyoNAyWTeNp6oMsNlifN8c1HwUqQjK/mZGXdc5TUlGklYUoSOoZtMQx8uvykWRZfMMY3Z0USqlFQZZBHRcyf35uBkG8f6hs9DkpeFSCNJVtt7zk8/Z8JtyQTTZ3csv6eqt89LrCV+SeOT80g0Ny1P8Pw+u68quADMUAfPRKYO2ox2rCr8A0Tpyi6+mUj4jbsukcupuuHFoqV+nYAmwxc1A7DmftqpY80/bORlIGPk3I77rlkPMTk4K+dAVcMSVrz5LANNAH5p21JdovAq9QcwzSyv0TCXM7S9j/pDBsmbZdxwvvNPqzsorSk+4n+Ek= X-Forefront-PRVS: 08978A8F5C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(24454002)(23676002)(586003)(189998001)(3846002)(6116002)(83506001)(77096005)(86362001)(5004730100002)(230700001)(47776003)(93886004)(64126003)(50986999)(92566002)(80316001)(66066001)(2906002)(50466002)(2950100001)(33656002)(5008740100001)(19580395003)(54356999)(87266999)(65816999)(4001350100001)(76176999)(42186005)(4326007)(5001770100001)(81166005)(1096002)(15975445007)(74482002)(65956001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0921; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwOTIxOzIzOmQ3NDRBWU9Qb2liK1B5ZitUTUxEb1d0cFBv?= =?utf-8?B?Y0htNU1yeHJIVU13YUhHMERWWFFjd2lCL3JjUUV6d3RPODRUSjB4YTJ1b2tJ?= =?utf-8?B?Uml6am51Wjk3OWNuWnpSaXQ3SzZONk5Xd3duRldMNU1OZkNqTkZwQjJwS0VJ?= =?utf-8?B?NFk4R3gzbi8wTWhDalN4bkw4M3IzNUdLT29hSTVTY1RzamRGTXVrbHMvSjdl?= =?utf-8?B?R0NIc3p2QUxZVkdUTkV0NitjSkdNSE1XQWZHM0dxeUNuN0VVbmVBMEZyR2ZB?= =?utf-8?B?UDN6WjFqWG5BbHpISVV6eEJPQ1pSZDNBOVRKZXNpUEwyQ1dVUUhVdlBXaVRn?= =?utf-8?B?RVozQUJSS1V0TnovVEZMdWpacmxBeGUwRjVTL09QbExqeWhxUWw4U0JiazAz?= =?utf-8?B?SWlwWEUxalptQVVzT3hoekIxQTY1b1FtNGN5SEVldk9EMHRhSjloWEtiUkE5?= =?utf-8?B?aUtnazhObUtKOTNrZmNRVjJaVlVjNmVXMzFaRTlsZjRCWm9BN3JWbUI3eEw3?= =?utf-8?B?SDFTRStoVVFXbFJqY2Y0NytLdlRwSkZqMU5UYWk5OWRlNHpYVFYzZmV0STQ0?= =?utf-8?B?cW1xcU9RZmNhekRKb3hQUzZsSDBVUExaMy9RMVh0QS9uaGVMZXlyaFRES1hT?= =?utf-8?B?QXc1QjB5cEZXVXVhaUw3REJYMzVIck9rMmFPSlluY0Y5L1lHdjRlYXBrcjRz?= =?utf-8?B?Rmd2NjMwYUlJUFNrSldJRkJJeFJMMXlBSzFnT1BsMzBhWjlzaDB2di96WEpq?= =?utf-8?B?S1dBL1J3UDBuYnpKR0M2WHJiTE9EcGRuLzBKNm5VU1Zvd0Yxald1UEZVMWE5?= =?utf-8?B?dW5IZzNMdVlSc3pVWVJuS2RuSk9QeVNjdjJKbVRPampITFRHbWJjQkhGbTFm?= =?utf-8?B?aWZ2dy83WXMvamY4TzdreDdzTGp5ZE1HYmJVMmcyODZqbXVseXlyVTBkNzds?= =?utf-8?B?UXluVEF6L1BIKzZrQ25RemMyWDh4YXIxbFNPV1pyNVI3WmFuNnIzeTdxa0xo?= =?utf-8?B?cjIwYnBIemphL2hNUGtTTTdaM2ZSUUVhR3dSS0hSeVFpR1R2bExHcjlMVWlI?= =?utf-8?B?cmdNRkJ5TjY0UGR3ZWROOCtUbGU1WXZTeWVGb1A2SEhqUTQxMXJGL1VTVU8y?= =?utf-8?B?c2dzVkJTV1lwbFNveGdnTWp2OHhRUkwzeFFxVWJXWWt1cis0MlV6SVNidmZh?= =?utf-8?B?SC9PR2thei9vYkZWRnFBQWVFeFVjaWc0THlHOEo1Lyt1ZWhZMGdDTm81S2Jt?= =?utf-8?B?TE5wYkpSNlJHSWx3NURweVVFak9mNW8veWZiRmkzSk1UWC83eWFCV2h6dmpj?= =?utf-8?B?bjd4UnRtM3NDRkRCQStuQU4xOW9HM2lQMkR5UWJRUVMrUWNOaXdyTlNhVEN4?= =?utf-8?B?OEpOeWluZnNPcytNVWphNDRJeTkyMWxTRlo3QWI0WEdaNTAzWXdPNDM3aU5y?= =?utf-8?B?RlQ1a1hxMzhxRHpwTU1MdHN6bnZ2UENaUVpEK2ZJR1NWU005ZXRFRVcydEVl?= =?utf-8?B?bHM1dz09?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0921; 5:KIqsSk3Fu2Vj5Ky6rEYuK6CCxZ+0GMxiawmnkmGgPxqqLEJD/AfBn/CclqQfrhdXfhWKVP6fDxNoRo2oGG7W9BLX2cyJgt40rnvz+a5AKvRv+qcs9IsYKxZaXkH1kvBrSI/XTHfQJjeOHtc0tOzoOA==; 24:FB7ORZMdwk/Zlzfz8rvX0f8SvbPkpDEKP9EcXnCJV8TTXmhalDwfuOdS0Mxi0qhTF0Gx7qYYt9SnG3OSsEBq6py54KfpLPXeYm+PYaUWcaI= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2016 10:07:49.2923 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0921 Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 10:07:58 -0000 On 2016/03/29 09:21, Sean Leonard wrote: > I will make this easy: not going to pursue Informational status. I > foresee compliance language referring to these regular expressions: if > not in the IETF, then in other bodies. Any software library that has > Internet + regular expression capabilities, would be an example. > Consider, for example, the POSIX standard, and the C++ standard library > standards. It would be reasonable for web browers/ECMAScript/HTML/DOM to > offer e-mail address validation capabilities at some point in the > future, with polyfill to fill in older implementations. > > Oh wait, they already do that...and badly: > https://html.spec.whatwg.org/multipage/forms.html#e-mail-state-(type=email) Just to connect some dots, there's a discussion with respect to HTML and EAI addresses at https://www.w3.org/Bugs/Public/show_bug.cgi?id=15489. Regards, Martin. From nobody Thu Mar 31 04:49:33 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7399C12D098; Wed, 30 Mar 2016 21:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 QGRk0To9yT84; Wed, 30 Mar 2016 21:29:12 -0700 (PDT) Received: from omr2.cc.vt.edu (omr2.cc.ipv6.vt.edu [IPv6:2607:b400:92:8400:0:33:fb76:806e]) (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 C930C12D0B5; Wed, 30 Mar 2016 21:29:11 -0700 (PDT) Received: from mr4.cc.vt.edu (mr4.cc.ipv6.vt.edu [IPv6:2001:468:c80:2105:0:232:8670:19fe]) by omr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id u2V4T4Rq014596; Thu, 31 Mar 2016 00:29:04 -0400 Received: from auth1.smtp.vt.edu (auth1.smtp.vt.edu [198.82.161.152] (may be forged)) by mr4.cc.vt.edu (8.14.4/8.14.4) with ESMTP id u2V4SwP6016664; Thu, 31 Mar 2016 00:29:03 -0400 Received: from turing-police.cc.vt.edu ([IPv6:2601:5c0:c100:993:be85:56ff:fe1f:4f6d]) (authenticated bits=0) by auth1.smtp.vt.edu (8.14.4/8.14.4) with ESMTP id u2V4SvTE015540 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 31 Mar 2016 00:28:58 -0400 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6+dev To: John C Klensin From: Valdis.Kletnieks@vt.edu In-Reply-To: <1470E5C228A55B3E9D4AE851@JcK-HP8200.jck.com> References: <8760w5xp8a.fsf@hobgoblin.ariadne.com> <158468C8650CEFDE15AD3A0D@JcK-HP8200.jck.com> <56FACA08.5000909@seantek.com> <1470E5C228A55B3E9D4AE851@JcK-HP8200.jck.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1459398537_2440P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 31 Mar 2016 00:28:57 -0400 Message-ID: <13628.1459398537@turing-police.cc.vt.edu> Archived-At: X-Mailman-Approved-At: Thu, 31 Mar 2016 04:49:32 -0700 Cc: dispatch@ietf.org, ietf-smtp@ietf.org Subject: Re: [dispatch] [ietf-smtp] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 04:29:13 -0000 --==_Exmh_1459398537_2440P Content-Type: text/plain; charset=us-ascii On Tue, 29 Mar 2016 15:38:59 -0400, John C Klensin said: > Actually five families if you want to do a comprehensive job: > > - 5321, possibly with nods to its predecessors > - 5322 which, as you point out, is not the same as 5321 > (and most, if not all, of the differences are > intentional) > - the EAI family > - the base DNS spec family, as updated And the corner cases when they don't agree. Consider user@yoyo_dyne.com - how long did *that* wart get debated? :) Those of us who were around for RFC1341 can look at the following, and weep, and ponder what failure modes the authors of this would have managed if they had *both* an ABNF and a regexp provided to work from, *even if they were semantically the same*... % egrep 'X-Mail|alt' bad.mailfile X-Mailer: IBM Notes Release 9.0.1FP2 SHF37 August 25, 2014 Content-Type: multipart/alternative; boundary="=_alternative 002EDD9148257F79_=" --=_alternative 002EDD9148257F79_= --=_alternative 002EDD9148257F79_= --=_alternative 002EDD9148257F79_=-- --=_alternative % (Hint: You'll probably need a fixed-space font and a lot of pondering - the above cost me close to 10 days of aggravation trying to figure out why one vendor's support emails were consistently getting eaten by my procmail filters, before I finally spotted it...) This is why we can't have nice things.... Oh, and those who want to tempt the Lovecraftian regexp elder gods should ponder the following: http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html (If that doesn't make Sean reconsider, *nothing* will... :) --==_Exmh_1459398537_2440P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Exmh version 2.5 07/13/2001 iQIVAwUBVvyniQdmEQWDXROgAQLufg/+LBMex9ZS4iuN7IVdTrfOaeLBo6hHsd7g iDb9EyPqTs6RTWEIapxcpmW6VIqSa1tHJ33YrqnncqgTGlXq/kpirPuK9vHBn6wo 5e88omHXdgPr6p38lBoG0kq1ZEd3jSKgOM+KQsgaigp0KQjs4l/eZO0Id27FVSTk oWidWBvgthYX1fkMl0eeLfjjiyA/6IFKU2JmE6yWGp2tpzqDPGZ7joLQbf6RQ4V8 wHrg1tU9qWEjgQ8SXmZn6NUjIfcrUm2bbKD6mmiz48TOg0KMnjxNkfLXUCBAWv53 SyqWS8pQAU+gWxCUZA9ElPaXRfJT+wTO09XBckn2+jMmEtza2HEpJ9uvNW4p5Csi dub7GJORL8jpWYfz2amAW/uAkvjrzgTRz/53SN/eJyTOrYlqixx/PqpWezEexyIu iK8nzLrSAqdVnW/zTAILKF+6q5g5i8m8t59lQMeuKf0qu03qyebf+jvVJoEshc3i A8rAPPEQ0sHAN62iuXShRIPpD++sXERxlnnvzNMWm9em0BSTB7u2unOYRqtSilk1 6ValFVQQA5NQA2evP29Q3swynQCuHirg2vKuLkW0rwQP5NlTEDJhYee+qjs6Q8aP euj1TjxmlGOgr9L5w5gFjt34dyb0RmZQ0/gaSIpykCZJIQ0a7dzfzTSP3tKzW2Cf YL7v7l5nSFg= =wj8Y -----END PGP SIGNATURE----- --==_Exmh_1459398537_2440P-- From nobody Thu Mar 31 04:49:35 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC60E12D143; Thu, 31 Mar 2016 01:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 8md7u1KGYcOl; Thu, 31 Mar 2016 01:53:10 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E16312D11F; Thu, 31 Mar 2016 01:53:09 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3B87AFA006A; Thu, 31 Mar 2016 08:53:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1459414387; bh=YH6X5Vi10ZbzJUqWxpms30ckH5XZByYNMJHjYpXQMHY=; h=From:To:Subject:Date:References:From; b=hCNACdWp5/T1yYAwMVnM3fOnDUioKFu2+zOkEAjFkFEBmikHH4Uu8/FrRWnJRyabc kD1+FXl4ayeA7w+CgLyygtiVSsfEAHRpI4h/XTdUe3YiepM0rbf8IoCrX8NgSaAlFI QL9bB5/g2GvpjR/2+WnJkvzg6fiCafjDSwqj3AVE= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1459414386-20268-20263/12/22; Thu, 31 Mar 2016 08:53:06 +0000 From: Arnt Gulbrandsen To: ietf-smtp@ietf.org, dispatch@ietf.org Date: Wed, 30 Mar 2016 18:47:04 +0200 Message-Id: References: <8760w5xp8a.fsf@hobgoblin.ariadne.com> <158468C8650CEFDE15AD3A0D@JcK-HP8200.jck.com> <56FACA08.5000909@seantek.com> <1470E5C228A55B3E9D4AE851@JcK-HP8200.jck.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: X-Mailman-Approved-At: Thu, 31 Mar 2016 04:49:32 -0700 Subject: Re: [dispatch] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 08:53:11 -0000 A document does not need to define a syntax in order to be useful. For instance, a document containing sections such as this could be good and useful: "The following regexp allows all classic email addresses and disallows many common typing mistakes...", ditto EAI, and with descriptions of their shortcomings. I am not sure whether something that matches a subset of valid addresses could be useful. Perhaps. Arnt