From nobody Thu Dec 4 07:43:37 2014 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 780B91AD3FF for ; Thu, 4 Dec 2014 07:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1EIn-lCmtpd for ; Thu, 4 Dec 2014 07:43:32 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B422A1AD459 for ; Thu, 4 Dec 2014 07:43:25 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id DD47C32427D for ; Thu, 4 Dec 2014 16:43:23 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 9AB054C0BB for ; Thu, 4 Dec 2014 16:43:22 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Thu, 4 Dec 2014 16:43:22 +0100 From: To: "dispatch@ietf.org" Thread-Topic: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 Thread-Index: AdAP2C5BeDuYjLy8Qce0wuL96+hw6g== Date: Thu, 4 Dec 2014 15:43:21 +0000 Message-ID: <15139_1417707803_5480811A_15139_368_1_8B970F90C584EA4E97D5BAAC9172DBB8142C6B0F@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB8142C6B0FPEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.21.125720 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/j57thk8myZSLLAPgrR7-pLU_JO4 Subject: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 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, 04 Dec 2014 15:43:36 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB8142C6B0FPEXCVZYM12corpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I re-send my fist email with the correct draft title as subject. I already plan to improve the text of the draft by defining a clear definit= ion with a new wording to describe the scope of usage of the new cause URI = parameter value. This new vocabulary could be something like "service access number translat= ion" with a definition that will be somewhere between a retargeting while t= he target user remain the same and a redirection to a new target. Indeed, f= or premium/toll-free services users are trying to contact a service which i= s the target service and not a particular user behind a UA as a "target use= r" as defined in RFC7044. The service access number could be seen as a supe= r-alias pointing out to a set of UAs and a UAs could be pointed out by seve= ral service access numbers. Comments and review are still welcome. BR, Marianne ------ This draft defines a new value for the SIP URI parameter "cause", which can= be used to associate a SIP URI to a service access number that has been tr= anslated by a specific application. Abstract: RFC4458 defines a "cause" URI parameter as having predefined values for Red= irecting reasons as a mapping from ITU-T Q.732.2-5 Redirecting Reasons. Th= e "cause" URI parameter is to be used in SIP or SIPs URI. In particular, it= may appear in the History-Info header defined in RFC7044 that must be adde= d in retargeted requests. This specification creates a new predefined value= for cases when the retargeting is caused by a specific service action lead= ing to a called number translation. This document updates RFC4458. This draft is needed for 3GPP, but we've tried to write it in a way so that= it can also be applied to other environments. A first version of the draft can be seen under: http://www.ietf.org/internet-drafts/draft-mohali-dispatch-cause-for-service= -number-00.txt This version is a very first version and for sure needs improvement. Your comments are welcome. Regards, Marianne Mohali ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8B970F90C584EA4E97D5BAAC9172DBB8142C6B0FPEXCVZYM12corpo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I re-send my fist email with= the correct draft title as subject.

 

I already plan to improve th= e text of the draft by defining a clear definition with a new wording to de= scribe the scope of usage of the new cause URI parameter value.<= /span>

This new vocabulary could be= something like "service access number translation" with a defini= tion that will be somewhere between a retargeting while the target user rem= ain the same and a redirection to a new target. Indeed, for premium/toll-free services users are trying to contact a servi= ce which is the target service and not a particular user behind a UA as a &= quot;target user" as defined in RFC7044. The service access number cou= ld be seen as a super-alias pointing out to a set of UAs and a UAs could be pointed out by several service access numb= ers.

 

Comments and review are stil= l welcome.

 

BR,

Marianne

------

This draft defines a new val= ue for the SIP URI parameter "cause", which can be used to associ= ate a SIP URI to a service access number that has been translated by a spec= ific application.

 

Abstract: =

RFC4458 defines a "caus= e" URI parameter as having predefined values for Redirecting reasons a= s a mapping from ITU-T Q.732.2-5 Redirecting Reasons.  The "cause= " URI parameter is to be used in SIP or SIPs URI. In particular, it may appear in the History-Info header defined in RFC7044 that must be a= dded in retargeted requests. This specification creates a new predefined va= lue for cases when the retargeting is caused by a specific service action l= eading to a called number translation. This document updates RFC4458.

 

This draft is needed for 3GP= P, but we’ve tried to write it in a way so that it can also be applie= d to other environments.

 

A first version of the draft= can be seen under:

h= ttp://www.ietf.org/internet-drafts/draft-mohali-dispatch-cause-for-service-= number-00.txt

 

This version is a very first= version and for sure needs improvement.

Your comments are welcome.

 

Regards,

Marianne Mohali

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_8B970F90C584EA4E97D5BAAC9172DBB8142C6B0FPEXCVZYM12corpo_-- From nobody Thu Dec 4 07:45:24 2014 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 8AAA41AD473 for ; Thu, 4 Dec 2014 07:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcWWeG96YaFJ for ; Thu, 4 Dec 2014 07:45:20 -0800 (PST) Received: from hs8.name.com (hs8.name.com [173.193.131.170]) (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 A562A1AD47A for ; Thu, 4 Dec 2014 07:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ranjitvoip.com; s=default; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=fl2TkvjPfNQUK7rLTUfe0d0nM4RN3QzaVv69S4dfb24=; b=nmjz+3FNSXMRBu09Wl8m5+jcMNwVoRb8fvrgAqZFrsBYXKXKxtmD+L3RJIMBGbfeYlNkLP+BLlqSqb8NXlc+BuZZuqzNOVZiXSfechQPR6xwi1DTcLaVsiprdagUOzgbnZgRARW5iLoILNnanBiW7wqMZwLKkn+59IsgDRBSE0Y=; Received: from localhost.localdomain ([127.0.0.1]:50108 helo=webmail.ranjitvoip.com) by hs8.name.com with esmtpa (Exim 4.84) (envelope-from ) id 1XwYaN-000Rr5-3p for dispatch@ietf.org; Thu, 04 Dec 2014 09:44:55 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 04 Dec 2014 09:44:54 -0600 From: ranjit@ranjitvoip.com To: dispatch@ietf.org Message-ID: <10a08ffce1c8c8d7a27f7a77c80db4c6@ranjitvoip.com> X-Sender: ranjit@ranjitvoip.com User-Agent: Roundcube Webmail/1.0.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hs8.name.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ranjitvoip.com X-Get-Message-Sender-Via: hs8.name.com: authenticated_id: ranjit@ranjitvoip.com Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/BvSXHJuRyp5j3dnowhsIY9YlRCQ Subject: [dispatch] Fwd: Interest and need for Websocket subprotocol - JSEP over websockets 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, 04 Dec 2014 15:45:22 -0000 Hi With websockets as a de-facto transport protocol for WebRTC signaling and JSEP being the format of encoding information, there is a need for a defining a websocket sub-protocol : jsep. So I would like to know if there is any interest in the community and also the views from experts about the need for a websocket-sub protocol for JSEP. The main purpose of defining the sub protocol (jsep) is to make sure that the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving JSEP encoded messages. Note: I had initially posted this topic on rtcweb mailing list and there I was suggested that rtcweb is not the appropriate mailing list to discuss this topic. Thanks Ranjit From nobody Thu Dec 4 08:55:21 2014 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 993CD1AD4CA for ; Thu, 4 Dec 2014 08:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Py2D9Cizqzo8 for ; Thu, 4 Dec 2014 08:55:13 -0800 (PST) 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 9D8DE1AD4E0 for ; Thu, 4 Dec 2014 08:55:08 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-4c-548091eab451 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3F.87.04076.AE190845; Thu, 4 Dec 2014 17:55:06 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.148]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 17:55:05 +0100 From: Salvatore Loreto To: "ranjit@ranjitvoip.com" Thread-Topic: [dispatch] Interest and need for Websocket subprotocol - JSEP over websockets Thread-Index: AQHQD+MN38tgjozzME6Esoe4Jpl8JA== Date: Thu, 4 Dec 2014 16:55:05 +0000 Message-ID: <99AB7BF0-21FF-449C-9886-226C09CEB603@ericsson.com> References: <10a08ffce1c8c8d7a27f7a77c80db4c6@ranjitvoip.com> In-Reply-To: <10a08ffce1c8c8d7a27f7a77c80db4c6@ranjitvoip.com> 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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3RvfVxIYQgydrNCyWTlrAajHz90M2 ByaPJUt+MnnsW2IewBTFZZOSmpNZllqkb5fAlXHg/BG2gjmcFS8nfWZuYFzJ3sXIySEhYCIx +WgDG4QtJnHh3nogm4tDSOAIo8TCx53sEM5iRolP1+8zglSxCZhJPH+4hRnEFhEwltiweSdQ BwcHs4CuxMZPOiBhYYEYid1P37NClMRKTH0yAcrWk1g3cw/YGBYBFYnWDR1gcV4Be4nZTafB DhISsJX49u0EWA2ngJ3E62V3wOKMQMd9P7WGCcRmFhCXuPVkPhPE0QISS/acZ4awRSVePv7H CmErSTQuecIKUa8jsWD3JzYI21qif/IEdghbW2LZwtfMEDcISpyc+YRlAqP4LCQrZiFpn4Wk fRaS9llI2hcwsq5iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIy2g1t+W+1gPPjc8RCjAAej Eg+vwbn6ECHWxLLiytxDjNIcLErivAvPzQsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwJiT wrLxU5y5o5pAsaOGeNNa7XU+kUq+2+cdD7c6PiHuGM8zhj/XNvBoJH57VP07bd+9xrPfZSKW hMX18rOfuDfp6fY9hteN2D/8XMy3PSPB6KnE+vPuqTlbtEyelaiX796cEPTLtXENw3+Gk/eU +GZN09/4T9b3zPyDnF8vaztmVQW9sP/o3KDEUpyRaKjFXFScCADwpMhOlwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/iyOSXFCpayfgbt4ckRtTB0gOlOw Cc: "" Subject: Re: [dispatch] Interest and need for Websocket subprotocol - JSEP over websockets 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, 04 Dec 2014 16:55:16 -0000 Hi Ranjit On Dec 4, 2014, at 5:44 PM, ranjit@ranjitvoip.com wrote: > Hi >=20 > With websockets as a de-facto transport protocol for WebRTC signaling and= JSEP being the format of encoding information, there is a need for a defin= ing a websocket sub-protocol : jeep. actually this need is not completely clear to me yet! > So I would like to know if there is any interest in the community and als= o the views from experts about the need for a websocket-sub protocol for JS= EP. >=20 > The main purpose of defining the sub protocol (jsep) is to make sure that= the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving JSEP enco= ded messages. >=20 > Note: I had initially posted this topic on rtcweb mailing list and there = I was suggested that rtcweb is not the appropriate mailing list to discuss = this topic. is there any specific reason why you want to transfer directly JSEP ? i.e. any reason you cannot use SIP over WebSocket? br Salvatore >=20 > Thanks > Ranjit >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Dec 4 09:25:08 2014 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 252B01AD4AE for ; Thu, 4 Dec 2014 09:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLr_iXDOqr0N for ; Thu, 4 Dec 2014 09:24:59 -0800 (PST) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E34C1A6F0A for ; Thu, 4 Dec 2014 09:24:59 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id r5so13080225qcx.16 for ; Thu, 04 Dec 2014 09:24:58 -0800 (PST) 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:content-type:content-transfer-encoding; bh=nKcdVAJljZnlVZ1O1bxtP0aecsqP4IDCZfZ0ddmmDww=; b=D3h2Ahl14m9Tps6VWb/hxZOHaHxfiABBn03cQTRxXdGJZMeKk5Q3aYSzfAD48mMknJ 9jALTIKoqLMvB4S4U7faINfrhweTyIG3rX9yn1Gw2A1TkGDM5ia7TZsd51+K8KfTFulz lr/NHIOOY3zkoXCzFwhq+KeSFF0c94M7k4/XTYML+hPqPuzK9oNrvIypbrl7K57uFPEN mrW5UAZtExjNB+u2YwfFpzNQz2oT6GavKJ/QsuVeuQN8elPljO4Lm/7fY1mrVBFJ7tmy yyWHw82Gbx8/KaF4eWsuL2vLO0wgmEL20wBM6pYROHVzMHUONGigVqmrdm787sOyKmki krYg== X-Gm-Message-State: ALoCoQns5mP2LRyff0ZkNF/5NKj3flzjkyWoPOozQQgLSuicPwlRApuEn1BpmV+wVYZCELXh3Jch X-Received: by 10.229.209.136 with SMTP id gg8mr18341161qcb.16.1417713898321; Thu, 04 Dec 2014 09:24:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Thu, 4 Dec 2014 09:24:38 -0800 (PST) In-Reply-To: <10a08ffce1c8c8d7a27f7a77c80db4c6@ranjitvoip.com> References: <10a08ffce1c8c8d7a27f7a77c80db4c6@ranjitvoip.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 4 Dec 2014 18:24:38 +0100 Message-ID: To: ranjit@ranjitvoip.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/Extpu2tYD8RCE7gRFoORTykSSEE Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: Interest and need for Websocket subprotocol - JSEP over websockets 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, 04 Dec 2014 17:25:01 -0000 2014-12-04 16:44 GMT+01:00 : > With websockets as a de-facto transport protocol for WebRTC signaling and > JSEP being the format of encoding information, there is a need for a > defining a websocket sub-protocol : jsep. So I would like to know if ther= e > is any interest in the community and also the views from experts about th= e > need for a websocket-sub protocol for JSEP. > > The main purpose of defining the sub protocol (jsep) is to make sure that > the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving JSEP > encoded messages. > > Note: I had initially posted this topic on rtcweb mailing list and there = I > was suggested that rtcweb is not the appropriate mailing list to discuss > this topic. Yes, but what you ignore here is all the rationale already given to you in the rtcweb mailing list. Not sure if you don't understand the received feedback or you just prefer to ignore it because you still think that "JSEP over WebSocket" is a need. Link to your thread in rtcweb: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13602.html Summarizing: In contrast to what you suggest, JSEP is just about signaling SDPs between peers and between devices and the W3C WebSocket API. In the rtcweb thread you also request for "adding more info to JSEP messages in order to indicate caller, called and so on". OK, you could create a new signaling protocol with headers (similar to HTTP) and attach the SDP in the body. Then add some kind of "From" and "To" headers to identity parties. You can call it "SIP". Please, leave it. --=20 I=C3=B1aki Baz Castillo From nobody Thu Dec 4 11:57:10 2014 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 B36711A19F7 for ; Thu, 4 Dec 2014 11:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgypVyFGUERx for ; Thu, 4 Dec 2014 11:57:02 -0800 (PST) Received: from hs8.name.com (hs8.name.com [173.193.131.170]) (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 34BF41A026C for ; Thu, 4 Dec 2014 11:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ranjitvoip.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=t1fUJgrNiNOcMvVBSLofFce1zQkRdI9Kr+oUkDLiTDg=; b=ePALA5hz7MTtUbzR6GJZUEnsZl4EfYTVYB73IVLAj7pS2x4IMuonFtE56s4/cDEZXTvmNIWsLebsB5T/JYm/ZsBZuAvJ9h2gyekpXpHr89H+y1V3qYg/bLxYv5kALD22cOSlsQHV/juapYLHjj5MDCTATVhqBP2h3ZB8nFICM1I=; Received: from localhost.localdomain ([127.0.0.1]:52253 helo=webmail.ranjitvoip.com) by hs8.name.com with esmtpa (Exim 4.84) (envelope-from ) id 1XwcWL-001Z72-Bg; Thu, 04 Dec 2014 13:57:01 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 04 Dec 2014 13:57:01 -0600 From: ranjit@ranjitvoip.com To: Salvatore Loreto In-Reply-To: <99AB7BF0-21FF-449C-9886-226C09CEB603@ericsson.com> References: <10a08ffce1c8c8d7a27f7a77c80db4c6@ranjitvoip.com> <99AB7BF0-21FF-449C-9886-226C09CEB603@ericsson.com> Message-ID: <63a36208d93011394ba40da1c8dd0f5e@ranjitvoip.com> X-Sender: ranjit@ranjitvoip.com User-Agent: Roundcube Webmail/1.0.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hs8.name.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ranjitvoip.com X-Get-Message-Sender-Via: hs8.name.com: authenticated_id: ranjit@ranjitvoip.com Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/JLkBw5ZkHw16dzuwacs7nRtMOjU Cc: dispatch@ietf.org Subject: Re: [dispatch] Interest and need for Websocket subprotocol - JSEP over websockets 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, 04 Dec 2014 19:57:05 -0000 Hi Salvatore it is actually not practical to support a full fledged SIP stack in web browsers. SO there are implementations or proposals which say that a basic SIP stack with a small footprint is needed in web browsers. now it is really difficult to decide on what features of SIP are needed and which of them are not needed. so it boils down the issue of how much SIP do we support in web browsers. so it is ideally better not to support SIP in web browsers, and instead use Java script based notation i.e JSON format for exchanging signaling information. I am not proposing the term "JSEP" as it is misleading, but my intent to send the following required information like 1) call initiation with initial offer, 2) call acceptance, 3) call termination and 4) basic call features like hold / resume the above information would go as JSON messages over Websocket connection. now both the web browser client and web server understand websockets and have established the connection too. so now they can also exchange JSON messages - just like SIP or XMPP. so when we have websocket sub-protocol types for SIP and XMPP, it is ideal to have a sub-protocol type for JSON as well. some of the benefits of indicating the message type as JSON 1. the web server receiving the message would know the message type as JSON and redirect it to a particular converter - e.g JSON to SIP or JSON to XMPP 2. the state machine on client side would be lean and the parser / builder logic too would be small - unlike SIP parser / builder 3. JSON being a generic format is not tied to any specific protocol and hence web browsers too need not care about signaling protocols like SIP, H.323, etc. it will be the job of WebRTC GW to do the required conversion 4. JSON allows Use of Web identity which can be authenticated by any Auth server - unlike SIP where only a sip url needs to be used and public auth servers like Google, Linkedin, Facebook cannot authenticate. Note: my main intent is to ease the building / parsing logic on web browsers so that they remain lite while the GWs can take additional load of protocol conversion. comments welcome Regards Ranjit On 2014-12-04 10:55 am, Salvatore Loreto wrote: > Hi Ranjit > > On Dec 4, 2014, at 5:44 PM, ranjit@ranjitvoip.com wrote: > >> Hi >> >> With websockets as a de-facto transport protocol for WebRTC signaling >> and JSEP being the format of encoding information, there is a need for >> a defining a websocket sub-protocol : jeep. > > > actually this need is not completely clear to me yet! > > >> So I would like to know if there is any interest in the community and >> also the views from experts about the need for a websocket-sub >> protocol for JSEP. >> >> The main purpose of defining the sub protocol (jsep) is to make sure >> that the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving >> JSEP encoded messages. >> >> Note: I had initially posted this topic on rtcweb mailing list and >> there I was suggested that rtcweb is not the appropriate mailing list >> to discuss this topic. > > is there any specific reason why you want to transfer directly JSEP ? > i.e. any reason you cannot use SIP over WebSocket? > > br > Salvatore > >> >> Thanks >> Ranjit >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Dec 4 12:13:02 2014 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 6A2521A1A72 for ; Thu, 4 Dec 2014 12:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MIME_8BIT_HEADER=0.3, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iArbtY8unAG for ; Thu, 4 Dec 2014 12:12:54 -0800 (PST) Received: from hs8.name.com (hs8.name.com [173.193.131.170]) (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 247F51A1A7B for ; Thu, 4 Dec 2014 12:12:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ranjitvoip.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=j2XTxzTqJguUrDesFFsZ4sFZmTOjIxw6qYA1Hvyi52A=; b=Ib86xxsmjnyWFkf4X01obBUlKKf9REqsPsNFTR5Z3j1kQI+uJF3Yi8TEoR5/RfyT+ZRvC5700oh0ZOwq4bts3YdvKQZ80SEQBP1JJMgvIyiJNvAso+2aXGUaLWiOC1qhR5mU1APmcOW8KfgPF1v2GMlH4fFVIe/VkU8Hz18Lcmc=; Received: from localhost.localdomain ([127.0.0.1]:54005 helo=webmail.ranjitvoip.com) by hs8.name.com with esmtpa (Exim 4.84) (envelope-from ) id 1Xwclh-001cll-Ia; Thu, 04 Dec 2014 14:12:53 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 04 Dec 2014 14:12:53 -0600 From: ranjit@ranjitvoip.com To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= In-Reply-To: References: <10a08ffce1c8c8d7a27f7a77c80db4c6@ranjitvoip.com> Message-ID: <6faa3528ea6657e28d003b0212dbb765@ranjitvoip.com> X-Sender: ranjit@ranjitvoip.com User-Agent: Roundcube Webmail/1.0.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hs8.name.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ranjitvoip.com X-Get-Message-Sender-Via: hs8.name.com: authenticated_id: ranjit@ranjitvoip.com Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/sk-JrAGO78pc_J9yVJzsbB2UPRI Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: Interest and need for Websocket subprotocol - JSEP over websockets 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, 04 Dec 2014 20:12:56 -0000 Hi Inaki I understand your concern of using the word "JSEP". That is fine - the word can be changed to some other suitable name. but my intent is that using SIP over Websockets has several disadvantages. some of them are 1. to use SIP over Websockets, WICs which can also be web browsers need to support SIP stack. which I do not think any web browser vendor would do 2. if we use SIP, then we cannot use the standard web identities and cannot use standard auth servers for authentication. this defeats the purpose of using web identity. Ideally I should be able to use my web identity - e.g ranjit@gmail.com / ranjit@facebook.com / ranjit@linkedin.com , etc to make web calls and operators could use standard auth servers to authenticate and validate my identity. once authenticated and validated, the operators can do create a sip identity for me and use that subsequently. the format of messages would be JSON over a websocket connection. so the name of the protocol need not be JSEP as many have reservations with it, but a more suitable name would be better. Regards Ranjit On 2014-12-04 11:24 am, Iñaki Baz Castillo wrote: > 2014-12-04 16:44 GMT+01:00 : >> With websockets as a de-facto transport protocol for WebRTC signaling >> and >> JSEP being the format of encoding information, there is a need for a >> defining a websocket sub-protocol : jsep. So I would like to know if >> there >> is any interest in the community and also the views from experts about >> the >> need for a websocket-sub protocol for JSEP. >> >> The main purpose of defining the sub protocol (jsep) is to make sure >> that >> the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving JSEP >> encoded messages. >> >> Note: I had initially posted this topic on rtcweb mailing list and >> there I >> was suggested that rtcweb is not the appropriate mailing list to >> discuss >> this topic. > > > Yes, but what you ignore here is all the rationale already given to > you in the rtcweb mailing list. Not sure if you don't understand the > received feedback or you just prefer to ignore it because you still > think that "JSEP over WebSocket" is a need. > > Link to your thread in rtcweb: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg13602.html > > > Summarizing: In contrast to what you suggest, JSEP is just about > signaling SDPs between peers and between devices and the W3C WebSocket > API. In the rtcweb thread you also request for "adding more info to > JSEP messages in order to indicate caller, called and so on". OK, you > could create a new signaling protocol with headers (similar to HTTP) > and attach the SDP in the body. Then add some kind of "From" and "To" > headers to identity parties. You can call it "SIP". > > > Please, leave it. From nobody Thu Dec 4 12:27:53 2014 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 5DC9E1A1B1A for ; Thu, 4 Dec 2014 12:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 MbYjSr-_gBnO for ; Thu, 4 Dec 2014 12:27:47 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002-out2.apm-internet.net [85.119.248.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A341A1B07 for ; Thu, 4 Dec 2014 12:27:41 -0800 (PST) Received: (qmail 15376 invoked from network); 4 Dec 2014 20:27:39 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 14121 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 4 Dec 2014 20:27:39 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 5C26B18A0B49; Thu, 4 Dec 2014 20:27:33 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 430ED18A05BC; Thu, 4 Dec 2014 20:27:33 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_41D41F81-58CD-4971-AF32-F4B616D9F6FE" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Tim Panton new In-Reply-To: <6faa3528ea6657e28d003b0212dbb765@ranjitvoip.com> Date: Thu, 4 Dec 2014 20:27:32 +0000 Message-Id: References: <10a08ffce1c8c8d7a27f7a77c80db4c6@ranjitvoip.com> <6faa3528ea6657e28d003b0212dbb765@ranjitvoip.com> To: ranjit@ranjitvoip.com X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/ecriB-0zw_9YqIdoIMucxTiSRyI Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: Interest and need for Websocket subprotocol - JSEP over websockets 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, 04 Dec 2014 20:27:51 -0000 --Apple-Mail=_41D41F81-58CD-4971-AF32-F4B616D9F6FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4 Dec 2014, at 20:12, ranjit@ranjitvoip.com wrote: >=20 >=20 > Hi Inaki >=20 > I understand your concern of using the word "JSEP". That is fine - the = word can be changed to some other suitable name. but my intent is that = using SIP over Websockets has several disadvantages. some of them are > 1. to use SIP over Websockets, WICs which can also be web browsers = need to support SIP stack. which I do not think any web browser vendor = would do Have you taken a look at the following : http://jssip.net = , http://sipjs.com , = http://sipml5.org - all of which implement SIP in = the browser.=20 > 2. if we use SIP, then we cannot use the standard web identities and = cannot use standard auth servers for authentication. this defeats the = purpose of using web identity. Ideally I should be able to use my > web identity - e.g ranjit@gmail.com / ranjit@facebook.com / = ranjit@linkedin.com , etc to make web calls and operators could use = standard auth servers to authenticate and validate my identity. once > authenticated and validated, the operators can do create a sip = identity for me and use that subsequently. Yep - all of the above can do that, should you want to=E2=80=A6. >=20 > the format of messages would be JSON over a websocket connection. so = the name of the protocol need not be JSEP as many have reservations with = it, but a more suitable name would be better. In the spirit of the IETF (rough consensus and running code), you might like to write a little javascript library that implements the = protocol you feel you need and illustrate how it differs from = draft-ibc-sipcore-sip-websocket = . Tim. >=20 > Regards > Ranjit >=20 >=20 >=20 > On 2014-12-04 11:24 am, I=C3=B1aki Baz Castillo wrote: >> 2014-12-04 16:44 GMT+01:00 : >>> With websockets as a de-facto transport protocol for WebRTC = signaling and >>> JSEP being the format of encoding information, there is a need for a >>> defining a websocket sub-protocol : jsep. So I would like to know if = there >>> is any interest in the community and also the views from experts = about the >>> need for a websocket-sub protocol for JSEP. >>> The main purpose of defining the sub protocol (jsep) is to make sure = that >>> the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving = JSEP >>> encoded messages. >>> Note: I had initially posted this topic on rtcweb mailing list and = there I >>> was suggested that rtcweb is not the appropriate mailing list to = discuss >>> this topic. >> Yes, but what you ignore here is all the rationale already given to >> you in the rtcweb mailing list. Not sure if you don't understand the >> received feedback or you just prefer to ignore it because you still >> think that "JSEP over WebSocket" is a need. >> Link to your thread in rtcweb: >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg13602.html >> Summarizing: In contrast to what you suggest, JSEP is just about >> signaling SDPs between peers and between devices and the W3C = WebSocket >> API. In the rtcweb thread you also request for "adding more info to >> JSEP messages in order to indicate caller, called and so on". OK, you >> could create a new signaling protocol with headers (similar to HTTP) >> and attach the SDP in the body. Then add some kind of "From" and "To" >> headers to identity parties. You can call it "SIP". >> Please, leave it. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_41D41F81-58CD-4971-AF32-F4B616D9F6FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 4 Dec 2014, at 20:12, ranjit@ranjitvoip.com= wrote:


Hi Inaki

I understand your = concern of using the word "JSEP". That is fine - the word can be changed = to some other suitable name. but my intent is that using SIP over = Websockets has several disadvantages. some of them are
1. = to use SIP over Websockets, WICs which can also be web browsers need to = support SIP stack. which I do not think any web browser vendor would = do

Have = you taken a look at the following : http://jssip.net , http://sipjs.com , http://sipml5.org - all of which implement SIP in = the browser. 

2. if we use SIP, then we cannot use the = standard web identities and cannot use standard auth servers for = authentication. this defeats the purpose of using web identity. Ideally = I should be able to use my
  web identity - e.g = ranjit@gmail.com / ranjit@facebook.com / = ranjit@linkedin.com = , etc to make web calls and operators could use standard auth servers to = authenticate and validate my identity. once
=   authenticated and validated, the operators can do create a = sip identity for me and use that subsequently.

Yep - all = of the above can do that, should you want to=E2=80=A6.


the format of messages would be JSON over a websocket = connection. so the name of the protocol need not be JSEP as many have = reservations with it, but a more suitable name would be better.

In the = spirit of the IETF (rough consensus and running code),
you = might like to write a little javascript library that implements the = protocol you feel you need and illustrate how it differs from draft-ibc-sipcore-sip-websocket .

Tim.



Regards
Ranjit



On 2014-12-04 11:24 am, I=C3=B1aki Baz = Castillo wrote:
2014-12-04 16:44 GMT+01:00  <ranjit@ranjitvoip.com>:
With websockets as a de-facto transport = protocol for WebRTC signaling and
JSEP being the format of = encoding information, there is a need for a
defining a = websocket sub-protocol : jsep. So I would like to know if there
is any interest in the community and also the views from = experts about the
need for a websocket-sub protocol for = JSEP.
The main purpose of defining the sub protocol (jsep) = is to make sure that
the WebRTC client (WIC) and WebRTC = server (E-CSCF) are receiving JSEP
encoded messages.
Note: I had initially posted this topic on rtcweb mailing = list and there I
was suggested that rtcweb is not the = appropriate mailing list to discuss
this topic.
Yes, but what you ignore here is all the = rationale already given to
you in the rtcweb mailing list. = Not sure if you don't understand the
received feedback or = you just prefer to ignore it because you still
think that = "JSEP over WebSocket" is a need.
Link to your thread in = rtcweb:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg13602.ht= ml
Summarizing: In contrast to what you suggest, JSEP = is just about
signaling SDPs between peers and between = devices and the W3C WebSocket
API. In the rtcweb thread = you also request for "adding more info to
JSEP messages in = order to indicate caller, called and so on". OK, you
could = create a new signaling protocol with headers (similar to HTTP)
and attach the SDP in the body. Then add some kind of "From" = and "To"
headers to identity parties. You can call it = "SIP".
Please, leave it.

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

= --Apple-Mail=_41D41F81-58CD-4971-AF32-F4B616D9F6FE-- From nobody Thu Dec 4 12:38:37 2014 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 DF1CB1A1EFD for ; Thu, 4 Dec 2014 12:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHKv6L0B4eti for ; Thu, 4 Dec 2014 12:38:31 -0800 (PST) Received: from hs8.name.com (hs8.name.com [173.193.131.170]) (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 751241A1BE0 for ; Thu, 4 Dec 2014 12:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ranjitvoip.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=OZbb1DgA4qMDqvK2CKObchroh/vpYtquQZxuDvLzsw8=; b=WjzOyD9eTZXghBTXecEj/W06tm1PWmS1CmQCYx6hMMB94utOqfgAbJxaYIuW2/BTm3RYEl8vKBAn+P2wWuUFusq8mbQFI9C6wxiqBAQfwxwErJQPALGCdbkifB27c2xsWHLJvBADvoM13dku+QlWeFpFn4hL5IhM+3C+PLYqeN4=; Received: from localhost.localdomain ([127.0.0.1]:56585 helo=webmail.ranjitvoip.com) by hs8.name.com with esmtpa (Exim 4.84) (envelope-from ) id 1XwdA4-001jZZ-0F; Thu, 04 Dec 2014 14:38:04 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 04 Dec 2014 14:38:03 -0600 From: ranjit@ranjitvoip.com To: Tim Panton new In-Reply-To: References: <10a08ffce1c8c8d7a27f7a77c80db4c6@ranjitvoip.com> <6faa3528ea6657e28d003b0212dbb765@ranjitvoip.com> Message-ID: <06ff4b9da0c3c485b57661bd60589ec9@ranjitvoip.com> X-Sender: ranjit@ranjitvoip.com User-Agent: Roundcube Webmail/1.0.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hs8.name.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ranjitvoip.com X-Get-Message-Sender-Via: hs8.name.com: authenticated_id: ranjit@ranjitvoip.com Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/4I-3Jnubv1JMLv20RnzmDGEpqcI Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: Interest and need for Websocket subprotocol - JSEP over websockets 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, 04 Dec 2014 20:38:35 -0000 Hi Tim my point was implementing SIP natively in browser without the need to use additional JS libraries. so e.g. chrome or IE may not support SIP natively. so you need to install JS libraries. so the features you use depend on the JS library you use. Regards Ranjit On 2014-12-04 2:27 pm, Tim Panton new wrote: >> On 4 Dec 2014, at 20:12, ranjit@ranjitvoip.com wrote: >> >> Hi Inaki >> >> I understand your concern of using the word "JSEP". That is fine - >> the word can be changed to some other suitable name. but my intent >> is that using SIP over Websockets has several disadvantages. some of >> them are >> 1. to use SIP over Websockets, WICs which can also be web browsers >> need to support SIP stack. which I do not think any web browser >> vendor would do > > Have you taken a look at the following : http://jssip.net [2] , > http://sipjs.com [3] , http://sipml5.org [4] - all of which implement > SIP in the browser. > >> 2. if we use SIP, then we cannot use the standard web identities and >> cannot use standard auth servers for authentication. this defeats >> the purpose of using web identity. Ideally I should be able to use >> my >> web identity - e.g ranjit@gmail.com / ranjit@facebook.com / >> ranjit@linkedin.com , etc to make web calls and operators could use >> standard auth servers to authenticate and validate my identity. once >> authenticated and validated, the operators can do create a sip >> identity for me and use that subsequently. > > Yep - all of the above can do that, should you want to…. > >> the format of messages would be JSON over a websocket connection. so >> the name of the protocol need not be JSEP as many have reservations >> with it, but a more suitable name would be better. > > In the spirit of the IETF (rough consensus and running code), > you might like to write a little javascript library that implements > the protocol you feel you need and illustrate how it differs from > draft-ibc-sipcore-sip-websocket [5] . > > Tim. > >> Regards >> Ranjit >> >> On 2014-12-04 11:24 am, Iñaki Baz Castillo wrote: >> 2014-12-04 16:44 GMT+01:00 : >> With websockets as a de-facto transport protocol for WebRTC >> signaling and >> JSEP being the format of encoding information, there is a need for a Hi Tim >> defining a websocket sub-protocol : jsep. So I would like to know if >> there >> is any interest in the community and also the views from experts >> about the >> need for a websocket-sub protocol for JSEP. >> The main purpose of defining the sub protocol (jsep) is to make sure >> that >> the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving >> JSEP >> encoded messages. >> Note: I had initially posted this topic on rtcweb mailing list and >> there I >> was suggested that rtcweb is not the appropriate mailing list to >> discuss >> this topic. >> Yes, but what you ignore here is all the rationale already given to >> you in the rtcweb mailing list. Not sure if you don't understand the >> received feedback or you just prefer to ignore it because you still >> think that "JSEP over WebSocket" is a need. >> Link to your thread in rtcweb: >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg13602.html >> [1] >> Summarizing: In contrast to what you suggest, JSEP is just about >> signaling SDPs between peers and between devices and the W3C >> WebSocket >> API. In the rtcweb thread you also request for "adding more info to >> JSEP messages in order to indicate caller, called and so on". OK, >> you >> could create a new signaling protocol with headers (similar to HTTP) >> and attach the SDP in the body. Then add some kind of "From" and >> "To" >> headers to identity parties. You can call it "SIP". >> Please, leave it. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > Links: > ------ > [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13602.html > [2] http://jssip.net > [3] http://sipjs.com > [4] http://sipml5.org > [5] http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket From nobody Thu Dec 4 13:45:10 2014 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 BED471A6FA8 for ; Thu, 4 Dec 2014 13:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDe-zwlLDXuP for ; Thu, 4 Dec 2014 13:44:55 -0800 (PST) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4611A1AA0 for ; Thu, 4 Dec 2014 13:44:55 -0800 (PST) Received: by mail-qg0-f50.google.com with SMTP id i50so13530158qgf.9 for ; Thu, 04 Dec 2014 13:44:54 -0800 (PST) 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:content-type:content-transfer-encoding; bh=Wi7cq5n5+GljcfHWrF7DfQE53rNB96ptr7/sHYpEi08=; b=XkEUaQ4Sbp+BVeLkOF3FIL+o2x7xyvNPUVO6WmT5D3hanZ6Lz5BDYx5yBH17eulozG GPbCxMgoBQUzoHyZtUCUYHsmJWwQ8BO1gyJsVyJwLvhsPLJtjkLjBNRpB5mYgzNdCjmO OQN6BR8EHuazAhePLaenIR6i6/ObrxowqTajox99hkkBFEiIvJCO5FTEvKJj3XydmuXa 6Ju+ej1DTwzkGRI4+PN0Yr71dIGzvSe0e35QylZAz08mBUnFxf6CHbnNb5gsZEM5RqsA ENwIYav+8fYkmGiMrSoR5HGFdBw00UJLZzridx0c1xHPvlDQ7mGqcGY1WhDBh9ygueGe 2+vQ== X-Gm-Message-State: ALoCoQlYiwm/4j6pEKfNPRAiZwtoy8cziAGKfgYjN1WwtMoCjLjIl/KDdpcjG5bRHHsCVnLraue/ X-Received: by 10.140.19.9 with SMTP id 9mr19833609qgg.98.1417729494389; Thu, 04 Dec 2014 13:44:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Thu, 4 Dec 2014 13:44:34 -0800 (PST) In-Reply-To: <6faa3528ea6657e28d003b0212dbb765@ranjitvoip.com> References: <10a08ffce1c8c8d7a27f7a77c80db4c6@ranjitvoip.com> <6faa3528ea6657e28d003b0212dbb765@ranjitvoip.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 4 Dec 2014 22:44:34 +0100 Message-ID: To: ranjit@ranjitvoip.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/UfNBkeJrC9Bw3SdjyZqt0B6tSk0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: Interest and need for Websocket subprotocol - JSEP over websockets 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, 04 Dec 2014 21:45:00 -0000 2014-12-04 21:12 GMT+01:00 : > Hi Inaki > > I understand your concern of using the word "JSEP". That is fine - the wo= rd > can be changed to some other suitable name. but my intent is that using S= IP > over Websockets has several disadvantages. some of them are > 1. to use SIP over Websockets, WICs which can also be web browsers need t= o > support SIP stack. which I do not think any web browser vendor would do If those WICs are web browsers then they have WebSocket and can run JavaScript, so they can run a JavaScript SIP stack. > 2. if we use SIP, then we cannot use the standard web identities and cann= ot > use standard auth servers for authentication. this defeats the purpose of > using web identity. Ideally I should be able to use my > web identity - e.g ranjit@gmail.com / ranjit@facebook.com / > ranjit@linkedin.com , etc to make web calls and operators could use stand= ard > auth servers to authenticate and validate my identity. once > authenticated and validated, the operators can do create a sip identit= y > for me and use that subsequently. Sorry, but this is 100% wrong. I use JsSIP library (JavaScript SIP over WebSocket) and authenticate/authorize by using HTTP Cookies, OAuth, etc etc. In fact I usually avoid using SIP/HTTP Digest authentication. So I strongly contradict your bullet #2. > the format of messages would be JSON over a websocket connection. so the > name of the protocol need not be JSEP as many have reservations with it, = but > a more suitable name would be better. JSON is of course more suitable for browsers given that a JSON message is mapped into a JavaScript object and vice-versa. In contrast, in server side (the SIP server written in C, C+, Java, etc) using a HTTP-or-SIP like message format may be faster for parsing purposes. Said that, I run JsSIP even in Cordova apps with no performance problems at= all. Anyhow, feel free to design a new signaling protocol. But please note that if two protocols are compatible then they are the same protocol. So if your aim is to make such a new protocol 1-1 mappable to SIP then it will be SIP (regardless it uses a JSON format instead of HTTP like headers). --=20 I=C3=B1aki Baz Castillo From nobody Thu Dec 4 13:48:43 2014 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 59DD41A6FAC for ; Thu, 4 Dec 2014 13:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWMXH7Ls2DrV for ; Thu, 4 Dec 2014 13:48:37 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55BB21A6FB1 for ; Thu, 4 Dec 2014 13:48:08 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id m20so13653617qcx.12 for ; Thu, 04 Dec 2014 13:48:07 -0800 (PST) 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:content-type:content-transfer-encoding; bh=4zP+Lw9uDkA/w40LsVeOl8feVjUjeyJbxhntKYcBPOw=; b=cGLObq18sti9EHc1ERJrM1aiECYduONuXh/vVrpQVCmr7BqkatPm4EPiaobrWJ5R0d Gu+7HBFBE/nCQ9xWyWjeWsNK8ZOB4zhqrn7rxU5L3d+HMhKd6bOO7s3GOZlQ8IEAAZon RHfaaejnMuEEi1NtXPW/kZfdTppjXiGOAr3c6rl1RBqfRKZ6sCM8YWOxh2h7ZcYG2ttD CjIgfZzYcmqG8pr8ACsLczPWx4XSbcBPeGppE+tGJlmG646TtoZAJPwYEB3JMLiL0U/M L5HVrjboA4aAc99pBghQArLFl/jsqHYoPuX1IQBSo/v+DkZf4SEasASgKFTq7UO0hCJC qAeg== X-Gm-Message-State: ALoCoQkL0G+ZaGp7B8JTRjnf1Effc2Ioigv5VhiSw1qggWdYZ/TGsLDj4f92zmcBf3BOTwoIdnXG X-Received: by 10.140.80.136 with SMTP id c8mr19501881qgd.86.1417729687537; Thu, 04 Dec 2014 13:48:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Thu, 4 Dec 2014 13:47:47 -0800 (PST) In-Reply-To: <06ff4b9da0c3c485b57661bd60589ec9@ranjitvoip.com> References: <10a08ffce1c8c8d7a27f7a77c80db4c6@ranjitvoip.com> <6faa3528ea6657e28d003b0212dbb765@ranjitvoip.com> <06ff4b9da0c3c485b57661bd60589ec9@ranjitvoip.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 4 Dec 2014 22:47:47 +0100 Message-ID: To: ranjit@ranjitvoip.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/lK2Yfi3nHaGQseSHzXMShBuscxo Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: Interest and need for Websocket subprotocol - JSEP over websockets 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, 04 Dec 2014 21:48:39 -0000 2014-12-04 21:38 GMT+01:00 : > my point was implementing SIP natively in browser without the need to use > additional JS libraries. so e.g. chrome or IE may not support SIP nativel= y. > so you need to install JS libraries. so the features you use depend on th= e > JS library you use. Sorry, I don't fully understand this point. Do you mean that you want SIP (or something 1-1 mappable to SIP) natively built in browsers so you don't "need" JavaScript libraries? If so: 1. Browsers are not phones. 2. Browsers run JavaScript. Use it. 3. No browser vendor will do that NEVER. --=20 I=C3=B1aki Baz Castillo From nobody Thu Dec 4 18:57:19 2014 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 011231A8835 for ; Thu, 4 Dec 2014 18:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MIME_8BIT_HEADER=0.3, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCy6AYEoOMbz for ; Thu, 4 Dec 2014 18:57:14 -0800 (PST) Received: from hs8.name.com (hs8.name.com [173.193.131.170]) (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 B4F031A6F8C for ; Thu, 4 Dec 2014 18:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ranjitvoip.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=hrKW0ro70qyQB/b6phASoiSBqsMZ/y8/R0PWAvojBAY=; b=OeqQ2KVEWprCVKl32X7Px7Ea10IqJkgbajN2xhygaw+P2E3+hHJK/JStHewZonEgB+/HvSTbgmlBvtsk6snm9IKbLap2T8Uk5jr+j+Zk9Ktx+ug65amoES/Pajn75hSsSrFfqx0FWFzrwgLw2bVr3fbYu0IMK91xQu0KyxCBoxo=; Received: from localhost.localdomain ([127.0.0.1]:37235 helo=webmail.ranjitvoip.com) by hs8.name.com with esmtpa (Exim 4.84) (envelope-from ) id 1Xwj4z-00346B-Ts; Thu, 04 Dec 2014 20:57:13 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 04 Dec 2014 20:57:13 -0600 From: ranjit@ranjitvoip.com To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= In-Reply-To: References: <10a08ffce1c8c8d7a27f7a77c80db4c6@ranjitvoip.com> <6faa3528ea6657e28d003b0212dbb765@ranjitvoip.com> Message-ID: <07efb2a0e1db55ef870b8613b6384928@ranjitvoip.com> X-Sender: ranjit@ranjitvoip.com User-Agent: Roundcube Webmail/1.0.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hs8.name.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ranjitvoip.com X-Get-Message-Sender-Via: hs8.name.com: authenticated_id: ranjit@ranjitvoip.com Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/C_wtdqsGgFpVccQezwTQn5oW6YQ Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: Interest and need for Websocket subprotocol - JSEP over websockets 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, 05 Dec 2014 02:57:16 -0000 Hi Inaki It is not that I want to develop a new protocol and map it to SIP, that is of no use, I too agree. All I am trying to say is that since JSON messages are already used for exchanging information, why can't we have the sub-protocol type as "JSON". This will simplify things both on client and server side. What we send in JSON can be SIP messages - but they do not go as SIP, but as JSON. Regards Ranjit On 2014-12-04 3:44 pm, Iñaki Baz Castillo wrote: > 2014-12-04 21:12 GMT+01:00 : >> Hi Inaki >> >> I understand your concern of using the word "JSEP". That is fine - the >> word >> can be changed to some other suitable name. but my intent is that >> using SIP >> over Websockets has several disadvantages. some of them are > >> 1. to use SIP over Websockets, WICs which can also be web browsers >> need to >> support SIP stack. which I do not think any web browser vendor would >> do > > If those WICs are web browsers then they have WebSocket and can run > JavaScript, so they can run a JavaScript SIP stack. > > > >> 2. if we use SIP, then we cannot use the standard web identities and >> cannot >> use standard auth servers for authentication. this defeats the purpose >> of >> using web identity. Ideally I should be able to use my >> web identity - e.g ranjit@gmail.com / ranjit@facebook.com / >> ranjit@linkedin.com , etc to make web calls and operators could use >> standard >> auth servers to authenticate and validate my identity. once >> authenticated and validated, the operators can do create a sip >> identity >> for me and use that subsequently. > > Sorry, but this is 100% wrong. I use JsSIP library (JavaScript SIP > over WebSocket) and authenticate/authorize by using HTTP Cookies, > OAuth, etc etc. In fact I usually avoid using SIP/HTTP Digest > authentication. > > So I strongly contradict your bullet #2. > > > >> the format of messages would be JSON over a websocket connection. so >> the >> name of the protocol need not be JSEP as many have reservations with >> it, but >> a more suitable name would be better. > > JSON is of course more suitable for browsers given that a JSON message > is mapped into a JavaScript object and vice-versa. In contrast, in > server side (the SIP server written in C, C+, Java, etc) using a > HTTP-or-SIP like message format may be faster for parsing purposes. > > Said that, I run JsSIP even in Cordova apps with no performance > problems at all. > > > Anyhow, feel free to design a new signaling protocol. But please note > that if two protocols are compatible then they are the same protocol. > So if your aim is to make such a new protocol 1-1 mappable to SIP then > it will be SIP (regardless it uses a JSON format instead of HTTP like > headers). From nobody Fri Dec 5 06:05:24 2014 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 BA4791A1A19 for ; Fri, 5 Dec 2014 06:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iksP1uvFIAwL for ; Fri, 5 Dec 2014 06:05:10 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDC41A1A0F for ; Fri, 5 Dec 2014 06:05:09 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 0BE7A2DC3AA; Fri, 5 Dec 2014 15:05:08 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id DB77A238078; Fri, 5 Dec 2014 15:05:07 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Fri, 5 Dec 2014 15:05:07 +0100 From: To: "VAN GEEL Jan (SPC/CSP)" , "dispatch@ietf.org" Thread-Topic: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 Thread-Index: AdAP2C5BeDuYjLy8Qce0wuL96+hw6gAfumQAAA9KhDA= Date: Fri, 5 Dec 2014 14:05:06 +0000 Message-ID: <14147_1417788307_5481BB93_14147_9260_1_8B970F90C584EA4E97D5BAAC9172DBB8142C7104@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <15139_1417707803_5480811A_15139_368_1_8B970F90C584EA4E97D5BAAC9172DBB8142C6B0F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <1E97FFD1485F1142BC075FF145A53A1E043D532D@A04067.BGC.NET> In-Reply-To: <1E97FFD1485F1142BC075FF145A53A1E043D532D@A04067.BGC.NET> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB8142C7104PEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.5.101818 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/nWX42HniU8Ysii1mZ5eZUWNu43U Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 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, 05 Dec 2014 14:05:17 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB8142C7104PEXCVZYM12corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jan, It is right, I saw it after submitted the draft. I will correct it for the next version. Thank you, Kind Regards, Marianne De : VAN GEEL Jan (SPC/CSP) [mailto:jan.van.geel@proximus.com] Envoy=E9 : vendredi 5 d=E9cembre 2014 07:47 =C0 : MOHALI Marianne IMT/OLN; dispatch@ietf.org Objet : RE: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 Marianne, My only comment is an editorial one: "tool free service" should be "toll fr= ee service" Kind regards Jan Van Geel IT and Network Specialist Belgacom CIS/SCC/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of marianne.moh= ali@orange.com Sent: Thursday 4 December 2014 16:43 To: dispatch@ietf.org Subject: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 Hi, I re-send my fist email with the correct draft title as subject. I already plan to improve the text of the draft by defining a clear definit= ion with a new wording to describe the scope of usage of the new cause URI = parameter value. This new vocabulary could be something like "service access number translat= ion" with a definition that will be somewhere between a retargeting while t= he target user remain the same and a redirection to a new target. Indeed, f= or premium/toll-free services users are trying to contact a service which i= s the target service and not a particular user behind a UA as a "target use= r" as defined in RFC7044. The service access number could be seen as a supe= r-alias pointing out to a set of UAs and a UAs could be pointed out by seve= ral service access numbers. Comments and review are still welcome. BR, Marianne ------ This draft defines a new value for the SIP URI parameter "cause", which can= be used to associate a SIP URI to a service access number that has been tr= anslated by a specific application. Abstract: RFC4458 defines a "cause" URI parameter as having predefined values for Red= irecting reasons as a mapping from ITU-T Q.732.2-5 Redirecting Reasons. Th= e "cause" URI parameter is to be used in SIP or SIPs URI. In particular, it= may appear in the History-Info header defined in RFC7044 that must be adde= d in retargeted requests. This specification creates a new predefined value= for cases when the retargeting is caused by a specific service action lead= ing to a called number translation. This document updates RFC4458. This draft is needed for 3GPP, but we've tried to write it in a way so that= it can also be applied to other environments. A first version of the draft can be seen under: http://www.ietf.org/internet-drafts/draft-mohali-dispatch-cause-for-service= -number-00.txt This version is a very first version and for sure needs improvement. Your comments are welcome. Regards, Marianne Mohali ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ________________________________ ***** Disclaimer ***** http://www.proximus.be/maildisclaimer ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8B970F90C584EA4E97D5BAAC9172DBB8142C7104PEXCVZYM12corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jan,

 

It is right, I= saw it after submitted the draft.

I will correct= it for the next version.

 

Thank you,

 

Kind Regards,<= o:p>

Marianne<= /o:p>

 

De : VAN GEEL Jan (SPC/CSP) [mailto:= jan.van.geel@proximus.com]
Envoy=E9 : vendredi 5 d=E9cembre 2014 07:47
=C0 : MOHALI Marianne IMT/OLN; dispatch@ietf.org
Objet : RE: [dispatch] New draft-mohali-dispatch-cause-for-serv= ice-number-00

 

Mariann= e,

&n= bsp;

My only= comment is an editorial one: “tool free service” should be = 220;toll free service”

&n= bsp;

Kind re= gards

&n= bsp;

Jan Van Geel
IT a= nd Network Specialist
Belg= acom CIS/SCC/FVC
Tel:= +32 2 202 1035
Tel:= +32 2 207 9032
Emai= l : jan.van.geel@belgacom.be

&n= bsp;

From:= dispatch [mailto:dispatch-bounces@ietf= .org] On Behalf Of marianne.= mohali@orange.com
Sent: Thursday 4 December 2014 16:43
To: dispatch@ietf.org
Subject: [dispatch] New draft-mohali-dispatch-cause-for-service-numb= er-00

 

Hi,

 =

I re-send m= y fist email with the correct draft title as subject.

 =

I already p= lan to improve the text of the draft by defining a clear definition with a = new wording to describe the scope of usage of the new cause URI parameter value.

This new vo= cabulary could be something like "service access number translation&qu= ot; with a definition that will be somewhere between a retargeting while the target user remain the same and a redirection to a new target. Indeed,= for premium/toll-free services users are trying to contact a service which= is the target service and not a particular user behind a UA as a "tar= get user" as defined in RFC7044. The service access number could be seen as a super-alias pointing out to a set= of UAs and a UAs could be pointed out by several service access numbers.

 =

Comments an= d review are still welcome.

 =

BR,

Marianne

------=

This draft = defines a new value for the SIP URI parameter "cause", which can = be used to associate a SIP URI to a service access number that has been translated by a specific application.

 =

Abstract:

RFC4458 def= ines a "cause" URI parameter as having predefined values for Redi= recting reasons as a mapping from ITU-T Q.732.2-5 Redirecting Reasons.  The "cause" URI parameter is to be used in SIP or SIPs URI. In p= articular, it may appear in the History-Info header defined in RFC7044 that= must be added in retargeted requests. This specification creates a new pre= defined value for cases when the retargeting is caused by a specific service action leading to a called number translat= ion. This document updates RFC4458.

 =

This draft = is needed for 3GPP, but we’ve tried to write it in a way so that it c= an also be applied to other environments.

 =

A first ver= sion of the draft can be seen under:

http://www.ietf.org/internet-drafts/draft-mohali-disp= atch-cause-for-service-number-00.txt

 =

This versio= n is a very first version and for sure needs improvement.=

Your commen= ts are welcome.

 =

Regards,

Marianne Mo= hali

______________________________________________________________________=
___________________________________________________
 
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.<=
o:p>
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.

 


***** Disclaimer *****
http://www.proximus.be/ma= ildisclaimer

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_8B970F90C584EA4E97D5BAAC9172DBB8142C7104PEXCVZYM12corpo_-- From nobody Mon Dec 8 09:57:53 2014 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 494F01ACD3A for ; Mon, 8 Dec 2014 09:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvHP0nQfzJLP for ; Mon, 8 Dec 2014 09:57:50 -0800 (PST) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A461ACD5D for ; Mon, 8 Dec 2014 09:57:48 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id s7so3649321qap.22 for ; Mon, 08 Dec 2014 09:57:47 -0800 (PST) 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:content-type:content-transfer-encoding; bh=wgsnr2cFU4IdQ4wW7ErVtKtwmhAdRUtQqp9kPvE4vjo=; b=btXG/esGNGrkcqJnqaN+VS1CYyFKESe+1ckTv+c1Nwq45j671ISt+gkD4EUIL15GMq KuWcsC7ACHTlqmN+lpywFS5DTkFyPsHjPjViN5It7KB18NqMQuUEobumPQ/mIViIDz1N +cRDrvzlhu0F5TYNDr2oXzGocDrH2fEwbMaDyOJQUhcKNPc0gGuVnyVTfdNfkrh1vGVx XFBrKhwKHYdCIuLFtppf+7CfRoCieOnjVN3KGU4/TkM2+Diaait3wspdgEoLNG/JNl2z tSMGiOmxVXHiDgS/Cw1NrNGmBXqT82f9K71Pv56E/VIfcMv9sbqRRRKP2nZikNsPs3Jp Xq1w== X-Gm-Message-State: ALoCoQn7TySKnFpidkiz4rGs6IQqohCgpgHk10HjZW9veOegNPf7rTOh/++pm6Q41Zjfy2wMD0P0 X-Received: by 10.140.21.106 with SMTP id 97mr53579829qgk.61.1418061467450; Mon, 08 Dec 2014 09:57:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Mon, 8 Dec 2014 09:57:26 -0800 (PST) In-Reply-To: <07efb2a0e1db55ef870b8613b6384928@ranjitvoip.com> References: <10a08ffce1c8c8d7a27f7a77c80db4c6@ranjitvoip.com> <6faa3528ea6657e28d003b0212dbb765@ranjitvoip.com> <07efb2a0e1db55ef870b8613b6384928@ranjitvoip.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 8 Dec 2014 18:57:26 +0100 Message-ID: To: ranjit@ranjitvoip.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/FHMubggG_4DvksdOmPz4bvSyDCk Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: Interest and need for Websocket subprotocol - JSEP over websockets 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, 08 Dec 2014 17:57:51 -0000 2014-12-05 3:57 GMT+01:00 : > It is not that I want to develop a new protocol and map it to SIP, that i= s > of no use, I too agree. All I am trying to say is that since JSON message= s > are already used for exchanging information, why can't we have the > sub-protocol type as "JSON". JSON is NOT a protocol, but a message format. There is no protocol called XML, YAML, INI, so nor JSON. > This will simplify things both on client and > server side. What we send in JSON can be SIP messages - but they do not = go > as SIP, but as JSON. I do not see any value in that proposal, but again, feel free to write a draft and implementations. --=20 I=C3=B1aki Baz Castillo From nobody Tue Dec 9 13:29:38 2014 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 D6AF51A8A47 for ; Tue, 9 Dec 2014 13:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psdNu1zStW1W for ; Tue, 9 Dec 2014 13:29:36 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75631A700C for ; Tue, 9 Dec 2014 13:29:35 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-02v.sys.comcast.net with comcast id RZVJ1p0072Qkjl901ZVaxw; Tue, 09 Dec 2014 21:29:34 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-15v.sys.comcast.net with comcast id RZVZ1p00J1KKtkw01ZVZuV; Tue, 09 Dec 2014 21:29:34 +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 sB9LT8hU015650; Tue, 9 Dec 2014 16:29:08 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sB9LSwEI015608; Tue, 9 Dec 2014 16:28:58 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: ranjit@ranjitvoip.com, dispatch@ietf.org In-Reply-To: (ibc@aliax.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 09 Dec 2014 16:28:57 -0500 Message-ID: <878uig8qcm.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418160574; bh=Y6Qb46Mw3VpX3C4u4BNqXQKIZC1U+u24ng974By6KdM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:MIME-Version:Content-Type; b=UKbZQhKguG000gd8Xt73QgUGh8RGW9Q7TJXbvljWZYoh7bUtNK1nYNR8bWyC6Heh8 QOUQM+jL5r1WddUQS/MFK6ehFPC0V+sezk9eu9+x5h6swWgeXezZzmPxS7eEn8wiAX rHTvRSoM1ZRVkx4+iwjAzFWOagYXQFDVYeKt7hj5GlOQ8bLSBkvzfSlh0k7aGFjRvQ EjGh3hK5QTSIInZ3kFaiDOH9ZQIB+ZnFFO9sP6f1h0bT/yvpOYCSaXfmj8TU0L97hk 3SPRVxn0PSKrvAJ7MUSS4/xsOzZ+0pEqbiLMxh7KhY7y3SEiiiRNXOAku2jiIHbX4h OCcbJHu7sLhig== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/Dfk8-JAZ61j6NRFHvqgdX5eQ_BQ Subject: Re: [dispatch] Fwd: Interest and need for Websocket subprotocol - JSEP over websockets 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, 09 Dec 2014 21:29:37 -0000 I=C3=B1aki Baz Castillo writes: >> This will simplify things both on client and server side. What we >> send in JSON can be SIP messages - but they do not go as SIP, but as >> JSON. > > I do not see any value in that proposal, but again, feel free to write > a draft and implementations. This is true: The proper test is to write a proposal (that explains the protocol and why it is useful) and see how many people express support of it. Dale From nobody Thu Dec 11 07:33:25 2014 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 203821A1BB3 for ; Thu, 11 Dec 2014 07:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 w1kfU5CLLHks for ; Thu, 11 Dec 2014 07:33:18 -0800 (PST) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D651A1B44 for ; Thu, 11 Dec 2014 07:33:17 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id kv19so873994vcb.18 for ; Thu, 11 Dec 2014 07:33:17 -0800 (PST) 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 :content-type; bh=SJpGzdj4HtwyKY9hZ7Ly5Wnvq1Jk3o86//y5/63ZHv0=; b=aiEe1o4E7CJm2e2ehqpoNyzsCGu2sTi5xpcvVt/TzQZhOktPSeTdiKcgEpWT1VAOVE 6vijD5+/96N2EXWXqB/bJcvpy8EWwoaOgAb0N/2uZ1ZbKTlu38BuiGW9QUT1gIko5B1n IAYPXhYT9GEhGrjfIt5MUJ+CybhaS5st4tvYHxiCVb6Rq5lpREvqBm26AWvrG0GCFKd8 qt53Hf3qZYB9zykkIPJ1UkoLOKdn1HP9LTGiiL/ONzGB0Y4s4K+1NGlYRnAbJXx+8xqf WKsMaWUFaVsi2BLD9xN710A0sneRHvXEsPKVt4cb1NCCng8FRYJ5Ppops0K4Pt/N6BgX ONUA== X-Gm-Message-State: ALoCoQma6qbFIs/JaXWlSF8VIY6s3otXQFdR3r1h8V98bIT/nz8/55xYXa5VDcyZG5+9kaJPQn3G MIME-Version: 1.0 X-Received: by 10.52.10.198 with SMTP id k6mr6141782vdb.38.1418311997168; Thu, 11 Dec 2014 07:33:17 -0800 (PST) Received: by 10.31.139.9 with HTTP; Thu, 11 Dec 2014 07:33:17 -0800 (PST) Date: Thu, 11 Dec 2014 10:33:17 -0500 Message-ID: From: Richard Barnes To: DISPATCH , draft-holmberg-dispatch-iotl@tools.ietf.org Content-Type: multipart/alternative; boundary=20cf30334e25c5b17f0509f27e4a Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/XOmhEAW12gOowj_0XEPr9X2AmCs Subject: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 11 Dec 2014 15:33:24 -0000 --20cf30334e25c5b17f0509f27e4a Content-Type: text/plain; charset=UTF-8 I have reviewed this document in preparation for IETF LC. Overall, it's in pretty good shape, and I have requested last call, but there are a few comments below that I would like addressed before it goes to the IESG. Thanks, --Richard The document says clearly how to indicate a traffic leg, but never really states *why* a network element would care what type of traffic leg a message is part of. Is there an example that could be given? It seems like Section 5.2.1 could just be included directly under Section 5.2. Section 5.2.1 needs to include a normative reference to a 3GPP spec defining "home" and "visited". The Security Considerations is basically saying, "Be careful making decisions based on this parameter, because anyone could change it". The RFC 2119 language is helpful, because it refers to undefined concepts. It would be better to refer to documents that have a defined concept of trust boundaries, e.g., RFC 3325 for the notion of Spec(T). """ This document defines a new SIP URI parameter, 'iotl', which can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs). """ This sentence is really long, and I don't think it's grammatical. At least my internal brain couldn't parse it. Likewise the corresponding sentence in Section 1. """ The 'iotl' parameter is defined in order to fulfil requirements from the 3GPP. """ This doesn't really seem necessary, and seems like something other ADs are likely to get hung up on. Unless you mean to explicitly disclaim its applicability to other networks. In that case, it would be helpful to be more explicit, "... and may not be applicable to other types of network." "an end user can be attached" Don't you mean "an end user *device*"? The idea of end users being attached to the network calls to mind scenes from the Matrix :) http://matrixcommunity.org/wordpress/wp-content/uploads/2014/04/Neo-and-the-pods.jpg "If, within an initial request for a dialog...identifies the type of traffic leg" * This section on choosing which 'iotl' parameter to use is useful. Editorially, it would be a little clearer to pull it out into bullet points, and preface with "A SIP entity determines the type of traffic leg in the following way". I would also suggest considering whether putting a MUST here would be appropriate, e.g., "SIP entities that understand the 'iotl' parameter MUST use the following rules to determine the type of traffic leg..." """ uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / iotl-param / other-param """ You should check with someone more knowledgeable about ABNF than me, but I understand the better thing to do than redefining the uri-parameter production is to update it, e.g. "uri-parameter =/ iotl-param" --20cf30334e25c5b17f0509f27e4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document in preparation for IETF LC.= =C2=A0 Overall, it's in pretty good shape, and I have requested last ca= ll, but there are a few comments below that I would like addressed before i= t goes to the IESG.

Thanks,
--Richard



The document says clear= ly how to indicate a traffic leg, but never really states *why* a network e= lement would care what type of traffic leg a message is part of.=C2=A0 Is t= here an example that could be given?

It seems like= Section 5.2.1 could just be included directly under Section 5.2.

Section 5.2.1 needs to include a normative reference to a 3= GPP spec defining "home" and "visited".

<= /div>
The Security Considerations is basically saying, "Be careful= making decisions based on this parameter, because anyone could change it&q= uot;.=C2=A0 The RFC 2119 language is helpful, because it refers to undefine= d concepts.=C2=A0 It would be better to refer to documents that have a defi= ned concept of trust boundaries, e.g., RFC 3325 for the notion of Spec(T).<= /div>


"""
=C2=A0= =C2=A0This document defines a new SIP URI parameter, 'iotl', which= can be
=C2=A0 =C2=A0used in a SIP URI to indicate that the entit= y associated with the
=C2=A0 =C2=A0address, or an entity responsi= ble for the host part of the address,
=C2=A0 =C2=A0represents the= end of a specific traffic leg (or multiple traffic
=C2=A0 =C2=A0= legs).
"""
This sentence is really long,= and I don't think it's grammatical.=C2=A0 At least my internal bra= in couldn't parse it.=C2=A0 Likewise the corresponding sentence in Sect= ion 1.


"""
=C2=A0 =C2=A0The 'iotl' parameter is defined in order to fulfil re= quirements from
=C2=A0 =C2=A0the 3GPP.
""&quo= t;
This doesn't really seem necessary, and seems like somethi= ng other ADs are likely to get hung up on.=C2=A0 Unless you mean to explici= tly disclaim its applicability to other networks.=C2=A0 In that case, it wo= uld be helpful to be more explicit, "... and may not be applicable to = other types of network."


"= ;an end user can be attached"
Don't you mean "an en= d user *device*"?=C2=A0 The idea of end users being attached to the ne= twork calls to mind scenes from the Matrix :) =C2=A0h= ttp://matrixcommunity.org/wordpress/wp-content/uploads/2014/04/Neo-and-the-= pods.jpg


"If, within an in= itial request for a dialog...identifies the type of traffic leg"
=
* This section on choosing which 'iotl' parameter to use is us= eful.=C2=A0 Editorially, it would be a little clearer to pull it out into b= ullet points, and preface with "A SIP entity determines the type of tr= affic leg in the following way".=C2=A0 I would also suggest considerin= g whether putting a MUST here would be appropriate, e.g., "SIP entitie= s that understand the 'iotl' parameter MUST use the following rules= to determine the type of traffic leg..."

"""
=C2=A0uri-parameter =3D transport-= param / user-param / method-param / ttl-param
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ maddr-param / lr-param / iot= l-param / other-param
"""
You should che= ck with someone more knowledgeable about ABNF than me, but I understand the= better thing to do than redefining the uri-parameter production is to upda= te it, e.g. "uri-parameter =3D/ iotl-param"

<= div>

--20cf30334e25c5b17f0509f27e4a-- From nobody Thu Dec 11 07:47:06 2014 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 433151ACECC for ; Thu, 11 Dec 2014 07:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwrtCD6x95NV for ; Thu, 11 Dec 2014 07:46:59 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [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 3E48E1ACE97 for ; Thu, 11 Dec 2014 07:46:59 -0800 (PST) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-12v.sys.comcast.net with comcast id SFm61p00B2AWL2D01FmxWQ; Thu, 11 Dec 2014 15:46:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-04v.sys.comcast.net with comcast id SFmx1p00T3Ge9ey01Fmxnq; Thu, 11 Dec 2014 15:46:57 +0000 Message-ID: <5489BC71.4010703@alum.mit.edu> Date: Thu, 11 Dec 2014 10:46:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418312817; bh=SM5LG6imbVyGbHPIVy/dnt7pTECGZeD/doIJlrHLd1U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=vqLg+UbqXELWbCl5ZNZ6mkfw/vBoCuVXDykNHWy7aegdDs9X6c6sBjPIJlmdPZ9Zr PNDc9aIXFTqgcoJ21HcIO8TBTtqw/SmCxZKreuY9CCkI0f4NlyNsg6KU0P4Bg+0b3Y q4cLACCazWktF1Vx5fvfjTc71RONW0i80xcd4rV5ZxwrA2FpaQHurntnOzwQDVxpCZ L6PZbX+tt/nYF54x3ccJLN9/4TQqKW1NjCVa7FRv7I+Wxy10tE9uiuVGDu/P5pSPhE Yl7gINAWxC3yho7sRo4ZRNfthX0UOUOW/vuf4cfAowO3f+Ws7/SRFKOiCIgduq+WYi g9faXXVhVwpOQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/I_BrSuCBmPgWTRD8ez7Ctp2vLbQ Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 11 Dec 2014 15:47:05 -0000 On 12/11/14 10:33 AM, Richard Barnes wrote: > """ > The 'iotl' parameter is defined in order to fulfil requirements from > the 3GPP. > """ > This doesn't really seem necessary, and seems like something other ADs > are likely to get hung up on. Unless you mean to explicitly disclaim > its applicability to other networks. In that case, it would be helpful > to be more explicit, "... and may not be applicable to other types of > network." Christer and I had some long discussions on how to generalize this beyond the 3GPP scope. To make it general it would have been necessary to formalize the notion of "traffic leg" in the sip environment, and how such legs could be classified. And it would have required a registry for traffic leg types, and possibly state models for how legs are grouped. It wasn't evident how to do this, or that anybody other than 3GPP would want the result. So I suggested narrowing the scope to just 3GPP. > """ > uri-parameter = transport-param / user-param / method-param / ttl-param > / maddr-param / lr-param / iotl-param / other-param > """ > You should check with someone more knowledgeable about ABNF than me, but > I understand the better thing to do than redefining the uri-parameter > production is to update it, e.g. "uri-parameter =/ iotl-param" Yes! Thanks, Paul From nobody Thu Dec 11 08:26:13 2014 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 CB3941A6FBB for ; Thu, 11 Dec 2014 08:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 ZvSaGFFb269f for ; Thu, 11 Dec 2014 08:26:11 -0800 (PST) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30931A1AF8 for ; Thu, 11 Dec 2014 08:26:10 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id hq12so2608597vcb.21 for ; Thu, 11 Dec 2014 08:26:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Mej2feY2XFKbzkYnuiB4MagdoLHcJnBY953CIJOM7aI=; b=H73hm7wKMpMvPATHzFe4z6X2XGqOKBmnm5K9pINOjOhmWgZgAdXGHtRJaYvXLXGHkD dpkqO3bMjgAboFTd0Ppupc/lEGd34PY32Y5DOvI3kyAJJcAF8IXcHOm3c5avLe7/249X 8aBjdcXm8bxxps0FmFCPJDLfzerIl7zrRdrUyufHYGfXgoFWd/AnK/RetNFWkUlBRTyS 87ue6K+wUfJ3oGufSmThQpPbH1o0e18iwImpo0ViP22x2A5Dksao4b2z06Jez8Ve74qO +P+p5leBlh7ww/ebkBfU4gwWtGkPAl3CFVg9C2pLRuEDrm0oJxzCbXPlxrCyXyYxrAix yjtQ== X-Gm-Message-State: ALoCoQnVduW9++c6y7COP2JQ5VQgU5vU/zjESdG0hEyYZOQ14rqBkIbVe2pY7a9aJjaywFu92PpO MIME-Version: 1.0 X-Received: by 10.220.118.194 with SMTP id w2mr7549865vcq.24.1418315170152; Thu, 11 Dec 2014 08:26:10 -0800 (PST) Received: by 10.31.139.9 with HTTP; Thu, 11 Dec 2014 08:26:10 -0800 (PST) In-Reply-To: <5489BC71.4010703@alum.mit.edu> References: <5489BC71.4010703@alum.mit.edu> Date: Thu, 11 Dec 2014 11:26:10 -0500 Message-ID: From: Richard Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1132f4bae59c520509f33bbd Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/ID4tdFvpTtGsEpsSZ0uXJ_5POwE Cc: DISPATCH Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 11 Dec 2014 16:26:13 -0000 --001a1132f4bae59c520509f33bbd Content-Type: text/plain; charset=UTF-8 On Thu, Dec 11, 2014 at 10:46 AM, Paul Kyzivat wrote: > On 12/11/14 10:33 AM, Richard Barnes wrote: > > """ >> The 'iotl' parameter is defined in order to fulfil requirements from >> the 3GPP. >> """ >> This doesn't really seem necessary, and seems like something other ADs >> are likely to get hung up on. Unless you mean to explicitly disclaim >> its applicability to other networks. In that case, it would be helpful >> to be more explicit, "... and may not be applicable to other types of >> network." >> > > Christer and I had some long discussions on how to generalize this beyond > the 3GPP scope. > > To make it general it would have been necessary to formalize the notion of > "traffic leg" in the sip environment, and how such legs could be > classified. And it would have required a registry for traffic leg types, > and possibly state models for how legs are grouped. > > It wasn't evident how to do this, or that anybody other than 3GPP would > want the result. So I suggested narrowing the scope to just 3GPP. I certainly didn't mean that the document should be generalized beyond 3GPP. I'm totally fine with that restriction, and the text in the body captures it well. I just don't think it needs mentioning in the abstract, or if it does, it should use the phrasing from the body: "The SIP URI 'iotl' parameter defined in this document is only applicable to 3GPP networks. The usage of the parameter within other types of networks is undefined." --Richard > > > """ >> uri-parameter = transport-param / user-param / method-param / ttl-param >> / maddr-param / lr-param / iotl-param / other-param >> """ >> You should check with someone more knowledgeable about ABNF than me, but >> I understand the better thing to do than redefining the uri-parameter >> production is to update it, e.g. "uri-parameter =/ iotl-param" >> > > Yes! > > Thanks, > Paul > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --001a1132f4bae59c520509f33bbd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 11, 2014 at 10:46 AM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
On 12/11/14 = 10:33 AM, Richard Barnes wrote:

"""
=C2=A0 =C2=A0 The 'iotl' parameter is defined in order to fulfil re= quirements from
=C2=A0 =C2=A0 the 3GPP.
"""
This doesn't really seem necessary, and seems like something other ADs<= br> are likely to get hung up on.=C2=A0 Unless you mean to explicitly disclaim<= br> its applicability to other networks.=C2=A0 In that case, it would be helpfu= l
to be more explicit, "... and may not be applicable to other types of<= br> network."

 Christer and I had some long discussions on how to generalize this beyond t= he 3GPP scope.

To make it general it would have been necessary to formalize the notion of = "traffic leg" in the sip environment, and how such legs could be = classified. And it would have required a registry for traffic leg types, an= d possibly state models for how legs are grouped.

It wasn't evident how to do this, or that anybody other than 3GPP would= want the result. So I suggested narrowing the scope to just 3GPP.

I certainly didn't mean that the document shoul= d be generalized beyond 3GPP.=C2=A0 I'm totally fine with that restrict= ion, and the text in the body captures it well.=C2=A0 I just don't thin= k it needs mentioning in the abstract, or if it does, it should use the phr= asing from the body: "The SIP URI 'iotl' parameter defined in = this document is only applicable to 3GPP networks.=C2=A0 The usage of the p= arameter within other types of networks is undefined."

<= /div>
--Richard

=C2=A0
=

"""
=C2=A0 uri-parameter =3D transport-param / user-param / method-param / ttl-= param
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 / maddr-para= m / lr-param / iotl-param / other-param
"""
You should check with someone more knowledgeable about ABNF than me, but I understand the better thing to do than redefining the uri-parameter
production is to update it, e.g. "uri-parameter =3D/ iotl-param"<= br>

Yes!

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

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

--001a1132f4bae59c520509f33bbd-- From nobody Thu Dec 11 11:11:09 2014 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 3A6961A894E for ; Thu, 11 Dec 2014 11:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH6C9dRE8m7f for ; Thu, 11 Dec 2014 11:10:56 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B5C1A879F for ; Thu, 11 Dec 2014 11:10:55 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-7a-5489ec3de188 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 89.F9.29772.D3CE9845; Thu, 11 Dec 2014 20:10:53 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 20:10:53 +0100 From: Christer Holmberg To: Richard Barnes , Paul Kyzivat Thread-Topic: [dispatch] AD review of draft-holmberg-dispatch-iotl Thread-Index: AQHQFVfPZr5NpOwNi02y+0ZPv/YmtpyKd/CAgAAK9QCAAD0skA== Date: Thu, 11 Dec 2014 19:10:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D58FA7D@ESESSMB209.ericsson.se> References: <5489BC71.4010703@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D58FA7DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGfG3Rtf2TWeIwc7lVhZLJy1gtVix4QCr xdQ+Wwdmj7/vPzB5LFnyk8lj8sZZLAHMUVw2Kak5mWWpRfp2CVwZMx9IFXzoZKzYv/I3SwPj jDbGLkZODgkBE4l7e86xQthiEhfurWfrYuTiEBI4wijRu20XC4SzhFHi89FNQFUcHGwCFhLd /7RBGkQEXCU+n3vCDhJmFlCQWLOeEyQsLOAocbVjMTNEiZPE3i8/4exTt/vZQGwWAVWJexNu g+3lFfCV+LBkAVhcSGAno0T71hAQm1MgUGLHkqlgNYxAt30/tYYJxGYWEJe49WQ+E8TNAhJL 9pxnhrBFJV4+/gf1i5LE2sPbWSBOy5f4sCweYpWgxMmZT1gmMIrOQjJpFkLVLCRVEGFNifW7 9CGqFSWmdD9kh7A1JFrnzGVHFl/AyL6KUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzD2Dm75 bbCD8eVzx0OMAhyMSjy8BpWdIUKsiWXFlbmHGKU5WJTEeReemxcsJJCeWJKanZpakFoUX1Sa k1p8iJGJg1OqgZHdQzo+UHnjpnqhvGdFEmFOj/dHfZc6yty6TCDWovprrVTD1tKsmiu8E+tl /H6ZqMaJdD/72GVxZ7X47i3HDspNs/bb1sx7Ltqu25TLy/Med0JS9ub72uZ7v++6xW6aXzmz /M3Kgi25puLmrNsOxdT7/m3gvHS7bInuxsz0tcv/8X71687wUmIpzkg01GIuKk4EAAtZDMie AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/esAd6g8nSmK9UCyqCjNs6dwP3bQ Cc: DISPATCH Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 11 Dec 2014 19:11:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D58FA7DESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYW0gZmluZSByZXBsYWNpbmcgdGhlIOKAnHJlcXVpcmVtZW504oCdIHN0YXRlbWVu dCBpbiB0aGUgQWJzdHJhY3QgYXMgc3VnZ2VzdGVkIGJ5IFJpY2hhcmQgKGJ5IGNvcHlpbmcgdGhl IHRleHQgZnJvbSB0aGUgQXBwbGljYWJpbGl0eSBzZWN0aW9uKToNCg0KIlRoZSBTSVAgVVJJICdp b3RsJyBwYXJhbWV0ZXIgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGlzIG9ubHkgYXBwbGljYWJs ZSB0byAzR1BQIG5ldHdvcmtzLiAgVGhlIHVzYWdlIG9mIHRoZSBwYXJhbWV0ZXIgd2l0aGluIG90 aGVyIHR5cGVzIG9mIG5ldHdvcmtzIGlzIHVuZGVmaW5lZC4iDQoNCk5vdGUgdGhhdCBzaW1pbGFy IHRleHQgZXhpc3RzIGFsc28gaW4gdGhlIEludHJvZHVjdGlvbiBzZWN0aW9uOg0KDQogICDigJxU aGUgJ2lvdGwnIHBhcmFtZXRlciBpcyBkZWZpbmVkIGluIG9yZGVyIHRvIGZ1bGZpbCByZXF1aXJl bWVudHMgZnJvbQ0KICAgdGhlIDNyZC1HZW5lcmF0aW9uIFBhcnRuZXJzaGlwIFByb2plY3QgKDNH UFApLCBidXQgaXQgY2FuIGFsc28gYmUNCiAgIHVzZWQgaW4gb3RoZXIgbmV0d29yayBlbnZpcm9u bWVudHMu4oCdDQoNCkkgZ3Vlc3MgSSBjb3VsZCByZW1vdmUgdGhhdCBjb21wbGV0ZWx5LCBhcyB3 ZSBoYXZlIHRoZSBvdGhlciBzZW50ZW5jZSBib3RoIGluIHRoZSBBYnN0cmFjdCBhbmQgaW4gdGhl IEFwcGxpY2FiaWxpdHkgc2VjdGlvbi4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0K DQpPbiBUaHUsIERlYyAxMSwgMjAxNCBhdCAxMDo0NiBBTSwgUGF1bCBLeXppdmF0IDxwa3l6aXZh dEBhbHVtLm1pdC5lZHU8bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdT4+IHdyb3RlOg0KT24g MTIvMTEvMTQgMTA6MzMgQU0sIFJpY2hhcmQgQmFybmVzIHdyb3RlOg0KIiIiDQogICAgVGhlICdp b3RsJyBwYXJhbWV0ZXIgaXMgZGVmaW5lZCBpbiBvcmRlciB0byBmdWxmaWwgcmVxdWlyZW1lbnRz IGZyb20NCiAgICB0aGUgM0dQUC4NCiIiIg0KVGhpcyBkb2Vzbid0IHJlYWxseSBzZWVtIG5lY2Vz c2FyeSwgYW5kIHNlZW1zIGxpa2Ugc29tZXRoaW5nIG90aGVyIEFEcw0KYXJlIGxpa2VseSB0byBn ZXQgaHVuZyB1cCBvbi4gIFVubGVzcyB5b3UgbWVhbiB0byBleHBsaWNpdGx5IGRpc2NsYWltDQpp dHMgYXBwbGljYWJpbGl0eSB0byBvdGhlciBuZXR3b3Jrcy4gIEluIHRoYXQgY2FzZSwgaXQgd291 bGQgYmUgaGVscGZ1bA0KdG8gYmUgbW9yZSBleHBsaWNpdCwgIi4uLiBhbmQgbWF5IG5vdCBiZSBh cHBsaWNhYmxlIHRvIG90aGVyIHR5cGVzIG9mDQpuZXR3b3JrLiINCg0KQ2hyaXN0ZXIgYW5kIEkg aGFkIHNvbWUgbG9uZyBkaXNjdXNzaW9ucyBvbiBob3cgdG8gZ2VuZXJhbGl6ZSB0aGlzIGJleW9u ZCB0aGUgM0dQUCBzY29wZS4NCg0KVG8gbWFrZSBpdCBnZW5lcmFsIGl0IHdvdWxkIGhhdmUgYmVl biBuZWNlc3NhcnkgdG8gZm9ybWFsaXplIHRoZSBub3Rpb24gb2YgInRyYWZmaWMgbGVnIiBpbiB0 aGUgc2lwIGVudmlyb25tZW50LCBhbmQgaG93IHN1Y2ggbGVncyBjb3VsZCBiZSBjbGFzc2lmaWVk LiBBbmQgaXQgd291bGQgaGF2ZSByZXF1aXJlZCBhIHJlZ2lzdHJ5IGZvciB0cmFmZmljIGxlZyB0 eXBlcywgYW5kIHBvc3NpYmx5IHN0YXRlIG1vZGVscyBmb3IgaG93IGxlZ3MgYXJlIGdyb3VwZWQu DQoNCkl0IHdhc24ndCBldmlkZW50IGhvdyB0byBkbyB0aGlzLCBvciB0aGF0IGFueWJvZHkgb3Ro ZXIgdGhhbiAzR1BQIHdvdWxkIHdhbnQgdGhlIHJlc3VsdC4gU28gSSBzdWdnZXN0ZWQgbmFycm93 aW5nIHRoZSBzY29wZSB0byBqdXN0IDNHUFAuDQoNCkkgY2VydGFpbmx5IGRpZG4ndCBtZWFuIHRo YXQgdGhlIGRvY3VtZW50IHNob3VsZCBiZSBnZW5lcmFsaXplZCBiZXlvbmQgM0dQUC4gIEknbSB0 b3RhbGx5IGZpbmUgd2l0aCB0aGF0IHJlc3RyaWN0aW9uLCBhbmQgdGhlIHRleHQgaW4gdGhlIGJv ZHkgY2FwdHVyZXMgaXQgd2VsbC4gIEkganVzdCBkb24ndCB0aGluayBpdCBuZWVkcyBtZW50aW9u aW5nIGluIHRoZSBhYnN0cmFjdCwgb3IgaWYgaXQgZG9lcywgaXQgc2hvdWxkIHVzZSB0aGUgcGhy YXNpbmcgZnJvbSB0aGUgYm9keTogIlRoZSBTSVAgVVJJICdpb3RsJyBwYXJhbWV0ZXIgZGVmaW5l ZCBpbiB0aGlzIGRvY3VtZW50IGlzIG9ubHkgYXBwbGljYWJsZSB0byAzR1BQIG5ldHdvcmtzLiAg VGhlIHVzYWdlIG9mIHRoZSBwYXJhbWV0ZXIgd2l0aGluIG90aGVyIHR5cGVzIG9mIG5ldHdvcmtz IGlzIHVuZGVmaW5lZC4iDQoNCi0tUmljaGFyZA0KDQoNCg0KIiIiDQogIHVyaS1wYXJhbWV0ZXIg PSB0cmFuc3BvcnQtcGFyYW0gLyB1c2VyLXBhcmFtIC8gbWV0aG9kLXBhcmFtIC8gdHRsLXBhcmFt DQogICAgICAgICAgICAgICAgICAvIG1hZGRyLXBhcmFtIC8gbHItcGFyYW0gLyBpb3RsLXBhcmFt IC8gb3RoZXItcGFyYW0NCiIiIg0KWW91IHNob3VsZCBjaGVjayB3aXRoIHNvbWVvbmUgbW9yZSBr bm93bGVkZ2VhYmxlIGFib3V0IEFCTkYgdGhhbiBtZSwgYnV0DQpJIHVuZGVyc3RhbmQgdGhlIGJl dHRlciB0aGluZyB0byBkbyB0aGFuIHJlZGVmaW5pbmcgdGhlIHVyaS1wYXJhbWV0ZXINCnByb2R1 Y3Rpb24gaXMgdG8gdXBkYXRlIGl0LCBlLmcuICJ1cmktcGFyYW1ldGVyID0vIGlvdGwtcGFyYW0i DQoNClllcyENCg0KICAgICAgICBUaGFua3MsDQogICAgICAgIFBhdWwNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRpc3BhdGNoIG1haWxpbmcgbGlz dA0KZGlzcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B1D58FA7DESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBhbSBmaW5lIHJl cGxhY2luZyB0aGUg4oCccmVxdWlyZW1lbnTigJ0gc3RhdGVtZW50IGluIHRoZSBBYnN0cmFjdCBh cyBzdWdnZXN0ZWQgYnkgUmljaGFyZCAoYnkgY29weWluZyB0aGUgdGV4dCBmcm9tIHRoZSBBcHBs aWNhYmlsaXR5DQogc2VjdGlvbik6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mcXVvdDtUaGUgU0lQIFVSSSAnaW90bCcg cGFyYW1ldGVyIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBvbmx5IGFwcGxpY2FibGUgdG8g M0dQUCBuZXR3b3Jrcy4mbmJzcDsgVGhlIHVzYWdlIG9mDQogdGhlIHBhcmFtZXRlciB3aXRoaW4g b3RoZXIgdHlwZXMgb2YgbmV0d29ya3MgaXMgdW5kZWZpbmVkLiZxdW90OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Tm90 ZSB0aGF0IHNpbWlsYXIgdGV4dCBleGlzdHMgYWxzbyBpbiB0aGUgSW50cm9kdWN0aW9uIHNlY3Rp b246PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsg4oCcVGhlICdpb3RsJyBwYXJhbWV0ZXIgaXMgZGVm aW5lZCBpbiBvcmRlciB0byBmdWxmaWwgcmVxdWlyZW1lbnRzIGZyb208bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ Jm5ic3A7Jm5ic3A7IHRoZSAzcmQtR2VuZXJhdGlvbiBQYXJ0bmVyc2hpcCBQcm9qZWN0ICgzR1BQ KSwgYnV0IGl0IGNhbiBhbHNvIGJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyB1c2VkIGlu IG90aGVyIG5ldHdvcmsgZW52aXJvbm1lbnRzLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+SSBndWVzcyBJIGNvdWxkIHJlbW92ZSB0aGF0IGNvbXBsZXRlbHksIGFz IHdlIGhhdmUgdGhlIG90aGVyIHNlbnRlbmNlIGJvdGggaW4gdGhlIEFic3RyYWN0IGFuZCBpbiB0 aGUgQXBwbGljYWJpbGl0eSBzZWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIERlYyAxMSwgMjAxNCBhdCAxMDo0NiBB TSwgUGF1bCBLeXppdmF0ICZsdDs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1 IiB0YXJnZXQ9Il9ibGFuayI+cGt5eml2YXRAYWx1bS5taXQuZWR1PC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ T24gMTIvMTEvMTQgMTA6MzMgQU0sIFJpY2hhcmQgQmFybmVzIHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mcXVvdDsmcXVvdDsmcXVvdDs8YnI+DQombmJzcDsgJm5ic3A7IFRo ZSAnaW90bCcgcGFyYW1ldGVyIGlzIGRlZmluZWQgaW4gb3JkZXIgdG8gZnVsZmlsIHJlcXVpcmVt ZW50cyBmcm9tPGJyPg0KJm5ic3A7ICZuYnNwOyB0aGUgM0dQUC48YnI+DQomcXVvdDsmcXVvdDsm cXVvdDs8YnI+DQpUaGlzIGRvZXNuJ3QgcmVhbGx5IHNlZW0gbmVjZXNzYXJ5LCBhbmQgc2VlbXMg bGlrZSBzb21ldGhpbmcgb3RoZXIgQURzPGJyPg0KYXJlIGxpa2VseSB0byBnZXQgaHVuZyB1cCBv bi4mbmJzcDsgVW5sZXNzIHlvdSBtZWFuIHRvIGV4cGxpY2l0bHkgZGlzY2xhaW08YnI+DQppdHMg YXBwbGljYWJpbGl0eSB0byBvdGhlciBuZXR3b3Jrcy4mbmJzcDsgSW4gdGhhdCBjYXNlLCBpdCB3 b3VsZCBiZSBoZWxwZnVsPGJyPg0KdG8gYmUgbW9yZSBleHBsaWNpdCwgJnF1b3Q7Li4uIGFuZCBt YXkgbm90IGJlIGFwcGxpY2FibGUgdG8gb3RoZXIgdHlwZXMgb2Y8YnI+DQpuZXR3b3JrLiZxdW90 OzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KQ2hyaXN0ZXIgYW5kIEkgaGFkIHNvbWUgbG9uZyBkaXNjdXNzaW9ucyBvbiBob3cgdG8gZ2Vu ZXJhbGl6ZSB0aGlzIGJleW9uZCB0aGUgM0dQUCBzY29wZS48YnI+DQo8YnI+DQpUbyBtYWtlIGl0 IGdlbmVyYWwgaXQgd291bGQgaGF2ZSBiZWVuIG5lY2Vzc2FyeSB0byBmb3JtYWxpemUgdGhlIG5v dGlvbiBvZiAmcXVvdDt0cmFmZmljIGxlZyZxdW90OyBpbiB0aGUgc2lwIGVudmlyb25tZW50LCBh bmQgaG93IHN1Y2ggbGVncyBjb3VsZCBiZSBjbGFzc2lmaWVkLiBBbmQgaXQgd291bGQgaGF2ZSBy ZXF1aXJlZCBhIHJlZ2lzdHJ5IGZvciB0cmFmZmljIGxlZyB0eXBlcywgYW5kIHBvc3NpYmx5IHN0 YXRlIG1vZGVscyBmb3IgaG93IGxlZ3MgYXJlIGdyb3VwZWQuPGJyPg0KPGJyPg0KSXQgd2Fzbid0 IGV2aWRlbnQgaG93IHRvIGRvIHRoaXMsIG9yIHRoYXQgYW55Ym9keSBvdGhlciB0aGFuIDNHUFAg d291bGQgd2FudCB0aGUgcmVzdWx0LiBTbyBJIHN1Z2dlc3RlZCBuYXJyb3dpbmcgdGhlIHNjb3Bl IHRvIGp1c3QgM0dQUC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgY2VydGFpbmx5IGRpZG4ndCBtZWFuIHRoYXQgdGhlIGRvY3Vt ZW50IHNob3VsZCBiZSBnZW5lcmFsaXplZCBiZXlvbmQgM0dQUC4mbmJzcDsgSSdtIHRvdGFsbHkg ZmluZSB3aXRoIHRoYXQgcmVzdHJpY3Rpb24sIGFuZCB0aGUgdGV4dCBpbiB0aGUgYm9keSBjYXB0 dXJlcyBpdCB3ZWxsLiZuYnNwOyBJIGp1c3QgZG9uJ3QgdGhpbmsgaXQgbmVlZHMgbWVudGlvbmlu ZyBpbiB0aGUgYWJzdHJhY3QsIG9yIGlmIGl0IGRvZXMsIGl0DQogc2hvdWxkIHVzZSB0aGUgcGhy YXNpbmcgZnJvbSB0aGUgYm9keTogJnF1b3Q7VGhlIFNJUCBVUkkgJ2lvdGwnIHBhcmFtZXRlciBk ZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgb25seSBhcHBsaWNhYmxlIHRvIDNHUFAgbmV0d29y a3MuJm5ic3A7IFRoZSB1c2FnZSBvZiB0aGUgcGFyYW1ldGVyIHdpdGhpbiBvdGhlciB0eXBlcyBv ZiBuZXR3b3JrcyBpcyB1bmRlZmluZWQuJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tUmljaGFyZDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDsmcXVvdDsmcXVvdDs8YnI+DQom bmJzcDsgdXJpLXBhcmFtZXRlciA9IHRyYW5zcG9ydC1wYXJhbSAvIHVzZXItcGFyYW0gLyBtZXRo b2QtcGFyYW0gLyB0dGwtcGFyYW08YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvIG1hZGRyLXBhcmFtIC8gbHItcGFyYW0g LyBpb3RsLXBhcmFtIC8gb3RoZXItcGFyYW08YnI+DQomcXVvdDsmcXVvdDsmcXVvdDs8YnI+DQpZ b3Ugc2hvdWxkIGNoZWNrIHdpdGggc29tZW9uZSBtb3JlIGtub3dsZWRnZWFibGUgYWJvdXQgQUJO RiB0aGFuIG1lLCBidXQ8YnI+DQpJIHVuZGVyc3RhbmQgdGhlIGJldHRlciB0aGluZyB0byBkbyB0 aGFuIHJlZGVmaW5pbmcgdGhlIHVyaS1wYXJhbWV0ZXI8YnI+DQpwcm9kdWN0aW9uIGlzIHRvIHVw ZGF0ZSBpdCwgZS5nLiAmcXVvdDt1cmktcGFyYW1ldGVyID0vIGlvdGwtcGFyYW0mcXVvdDs8bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClll cyE8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhhbmtzLDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYXVsPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkaXNwYXRjaCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5kaXNwYXRjaEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D58FA7DESESSMB209erics_-- From nobody Thu Dec 11 14:24:35 2014 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 365591A86F4 for ; Thu, 11 Dec 2014 14:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoFDEgEKA8fs for ; Thu, 11 Dec 2014 14:24:32 -0800 (PST) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348391A0385 for ; Thu, 11 Dec 2014 14:24:32 -0800 (PST) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-10v.sys.comcast.net with comcast id SNP91p0094yXVJQ01NQXy2; Thu, 11 Dec 2014 22:24:31 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-po-06v.sys.comcast.net with comcast id SNQW1p00D1KKtkw01NQW5A; Thu, 11 Dec 2014 22:24:31 +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 sBBMOTGb001458; Thu, 11 Dec 2014 17:24:29 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sBBMOTFL001456; Thu, 11 Dec 2014 17:24:29 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Richard Barnes In-Reply-To: (rlb@ipv.sx) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 11 Dec 2014 17:24:29 -0500 Message-ID: <87k31x6d0i.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/cZjI7ygf-J8MWJa8R-ZUw7u6pYE Cc: draft-holmberg-dispatch-iotl@tools.ietf.org, dispatch@ietf.org Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 11 Dec 2014 22:24:33 -0000 Richard Barnes writes: > """ > uri-parameter = transport-param / user-param / method-param / ttl-param > / maddr-param / lr-param / iotl-param / other-param > """ > You should check with someone more knowledgeable about ABNF than me, but I > understand the better thing to do than redefining the uri-parameter > production is to update it, e.g. "uri-parameter =/ iotl-param" Yes, that would be much clearer. > """ > The 'iotl' parameter is defined in order to fulfil requirements from > the 3GPP. > """ There are three occurrences of statements like this: Abstract The 'iotl' parameter is defined in order to fulfil requirements from the 3GPP. 1. Introduction The 'iotl' parameter is defined in order to fulfil requirements from the 3rd-Generation Partnership Project (3GPP), but it can also be used in other network environments. 2. Applicability The SIP URI 'iotl' parameter defined in this document is only applicable to 3GPP networks. The usage of the parameter within other types of networks is undefined. All of these are appropriate, given the purposes of these sections. I think it would help if the wording of all three was aligned. The typical phrasing in RFCs is "... is outside the scope of this specification." How about the following wording, which does not exclude iotl from being used in non-3GPP networks, but makes it clear that this draft does not define its usage there: The 'iotl' parameter is defined in order to fulfil requirements from the 3rd-Generation Partnership Project (3GPP). The parameter may be used within other types of networks, but that usage is outside the scope of this specification. (In the Abstract, "3rd-Generation Partnership Project (3GPP)" can be abbreviated as "3GPP" because that acronym has been defined in the abstract previously.) Dale From nobody Thu Dec 11 14:59:55 2014 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 C9B331A899B for ; Thu, 11 Dec 2014 14:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXty1_471Dry for ; Thu, 11 Dec 2014 14:59:51 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52441A877B for ; Thu, 11 Dec 2014 14:59:50 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-fb-548a21e4d9b2 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9C.D0.04231.4E12A845; Thu, 11 Dec 2014 23:59:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 23:59:48 +0100 From: Christer Holmberg To: "Dale R. Worley" , Richard Barnes , "pkyzivat@alum.mit.edu" Thread-Topic: [dispatch] AD review of draft-holmberg-dispatch-iotl Thread-Index: AQHQFZE6Zr5NpOwNi02y+0ZPv/YmtpyK/89A Date: Thu, 11 Dec 2014 22:59:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D590336@ESESSMB209.ericsson.se> References: (rlb@ipv.sx) <87k31x6d0i.fsf@hobgoblin.ariadne.com> In-Reply-To: <87k31x6d0i.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGfG3RveJYleIwf2zmhZLJy1gtdi/cwar xYoNB1gtpvbZWrw8UebA6vH3/Qcmj8n7vzJ7LFnyE8jaOIvF48vlz2wBrFFcNimpOZllqUX6 dglcGet/9LIW7BauaJzg08A4hb+LkZNDQsBE4tnPiWwQtpjEhXvrgWwuDiGBI4wS51t3MUM4 SxglXh58y9jFyMHBJmAh0f1PG6RBRKBSYsGPjewgNcwCPYwSXxb/ZwdJCAs4SlztWMwMUeQk sffLTyjbSGL7kWtgNouAqkTr1LesIDavgK/E3bt7GEFsIYE2RonT26pAbE4BY4lP15vBrmME uu77qTVMIDazgLjErSfzmSCuFpBYsuc8M4QtKvHy8T9WCFtJYtHtz1D1OhILdn9ig7C1JZYt fM0MsVdQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBkWcUoWpxaXJybbmSsl1qUmVxcnJ+nl5da sokRGHcHt/zW3cG4+rXjIUYBDkYlHl6Dys4QIdbEsuLK3EOM0hwsSuK8i87NCxYSSE8sSc1O TS1ILYovKs1JLT7EyMTBKdXA2Mttuv+8+v5bvelVbe7NKfpL1m93dvRz013fp1GuzCY088y3 8LQTWSfU4ide6LYrsJlS+/+yL3+MU5K9nJvEtePv23e9FQpz2/NR93XVjNIkz2+yWcaJ5y36 ZWZm2kxJ8pUNvfvGUKhl34xS+38XZvVfXfbs7OQTc2d942O5Nn/bjfoTN582KLEUZyQaajEX FScCABYzT9ycAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/18aBEClxAwsOTm_83oZ2bfrbRng Cc: "draft-holmberg-dispatch-iotl@tools.ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 11 Dec 2014 22:59:53 -0000 Hi, >> """ >> uri-parameter =3D transport-param / user-param / method-param / ttl-par= am >> / maddr-param / lr-param / iotl-param / other-param=20 >> """ >> You should check with someone more knowledgeable about ABNF than me,=20 >> but I understand the better thing to do than redefining the=20 >> uri-parameter production is to update it, e.g. "uri-parameter =3D/ iotl-= param" > > Yes, that would be much clearer. AFAIK, that way of extending parameters have been deprecated, and one is (a= gain) supposed to re-define the whole parameter. But, Paul can correct me if I'm wrong :) ----------- >> """ >> The 'iotl' parameter is defined in order to fulfil requirements from >> the 3GPP. >> """ > > There are three occurrences of statements like this: > > Abstract > > The 'iotl' parameter is defined in order to fulfil requirements from > the 3GPP. > > 1. Introduction > > The 'iotl' parameter is defined in order to fulfil requirements from > the 3rd-Generation Partnership Project (3GPP), but it can also be > used in other network environments. > > 2. Applicability > > The SIP URI 'iotl' parameter defined in this document is only > applicable to 3GPP networks. The usage of the parameter within other > types of networks is undefined. > > All of these are appropriate, given the purposes of these sections. I th= ink it would help if the wording of all=20 > three was aligned. The typical phrasing in RFCs is "... is outside the s= cope of this specification." How about=20 > the following wording, which does not exclude iotl from being used in non= -3GPP networks, but makes it clear=20 > that this draft does not define its usage there: > > The 'iotl' parameter is defined in order to fulfil requirements from > the 3rd-Generation Partnership Project (3GPP). The parameter may be > used within other types of networks, but that usage is outside the > scope of this specification. > > (In the Abstract, "3rd-Generation Partnership Project (3GPP)" can be abbr= eviated as "3GPP" because that acronym has been defined in the abstract pre= viously.) Richard indicated that he wants to remove the requirements sentence, and su= ggested the following: "The SIP URI 'iotl' parameter defined in this document is only applicable = to 3GPP networks. The usage of the=20 parameter within other types of networks is undefined." Regards, Christer From nobody Thu Dec 11 15:15:00 2014 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 B0CAB1A887B for ; Thu, 11 Dec 2014 15:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rA_AvF4p6FLS for ; Thu, 11 Dec 2014 15:14:57 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84271A1B78 for ; Thu, 11 Dec 2014 15:14:57 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-07v.sys.comcast.net with comcast id SPEX1p0022JGN3p01PEwrX; Thu, 11 Dec 2014 23:14:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-10v.sys.comcast.net with comcast id SPEv1p00R3Ge9ey01PEvHn; Thu, 11 Dec 2014 23:14:56 +0000 Message-ID: <548A256F.1010801@alum.mit.edu> Date: Thu, 11 Dec 2014 18:14:55 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "Dale R. Worley" , Richard Barnes References: (rlb@ipv.sx) <87k31x6d0i.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D590336@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D590336@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418339696; bh=Ay1UDhQrtAYE/ho/V/HpkULvj7UgcpIbtEjyF3b/ae0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Dkrow7HAPv4bafLWAjilsx7ARS28A8b4gCy5JU+aX9CRekrhOFYfItyrEZ3UEfJSZ 5vVL4Qzsr/SXoBdjHm6fF8IyG4m2J38Mkk1y/FgQMGMmLkMj20DbzESGHiMIIvxGOf zDxnTQkeoMYwPRvUM8Pp58XtShOEFH1ygxXV5lUvmhQI3ICAuuQdfqR+UZxDoTdt7b 9yp8YzoK0Q5vCcueUesj10MIyB8iAX24ZiWypL+s3HdXyzYD/82gwmSyLbBKxGvn5A /p5pxDbPc2C+QUQc70oF79X7juk4ZKEdaFTCRr2Bw2ueGvqlgCIkbYWsg41SE7HY8A GutunkLwhVL/w== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/KQyT7EkPHQ1d6CkTXey1vsp26Z8 Cc: "draft-holmberg-dispatch-iotl@tools.ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 11 Dec 2014 23:14:58 -0000 On 12/11/14 5:59 PM, Christer Holmberg wrote: > Hi, > >>> """ >>> uri-parameter = transport-param / user-param / method-param / ttl-param >>> / maddr-param / lr-param / iotl-param / other-param >>> """ >>> You should check with someone more knowledgeable about ABNF than me, >>> but I understand the better thing to do than redefining the >>> uri-parameter production is to update it, e.g. "uri-parameter =/ iotl-param" >> >> Yes, that would be much clearer. > > AFAIK, that way of extending parameters have been deprecated, and one is (again) supposed to re-define the whole parameter. > > But, Paul can correct me if I'm wrong :) What made you think that? I know of no such change, *in general*. There has been some discussion about whether such a change (using =/) constitutes a revision to the base draft. (IMO it does, some people don't think so.) If you actually do the change as you did then I think there is no question - it clearly is a revision! IMO, if you want to avoid such changes causing an update to the base document then you should do things such that the ABNF in the base document isn't modified. If there is a registry, then that really should serve as an alternative to listing values in ABNF. So then this issue doesn't come up. In this particular case, there now *is* a registry of URI parameters, and your draft *is* asking for it to be updated. So I was wrong in suggesting that /= was better - I should have said that there should not be any change to the uri-parameter ABNF. Thanks, Paul From nobody Thu Dec 11 23:17:18 2014 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 0A4B11A6F47 for ; Thu, 11 Dec 2014 23:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn-VeVu07glr for ; Thu, 11 Dec 2014 23:17:14 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215C71A001C for ; Thu, 11 Dec 2014 23:17:13 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-ab-548a96786b3c Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 09.DE.04231.8769A845; Fri, 12 Dec 2014 08:17:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 08:17:11 +0100 From: Christer Holmberg To: Paul Kyzivat , "Dale R. Worley" , Richard Barnes Thread-Topic: [dispatch] AD review of draft-holmberg-dispatch-iotl Thread-Index: AQHQFZE6Zr5NpOwNi02y+0ZPv/YmtpyK/89A///014CAAJb/YA== Date: Fri, 12 Dec 2014 07:17:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D590C7B@ESESSMB209.ericsson.se> References: (rlb@ipv.sx) <87k31x6d0i.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D590336@ESESSMB209.ericsson.se> <548A256F.1010801@alum.mit.edu> In-Reply-To: <548A256F.1010801@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGfG3RrdiWleIQcM3AYulkxawWuzfOYPV YsWGA6wWU/tsLV6eKHNg9fj7/gOTx+T9X5k9liz5CWRtnMXi8eXyZ7YA1igum5TUnMyy1CJ9 uwSujM6288wFp3kr5s0/w9LAeJari5GDQ0LARGLrOp0uRk4gU0ziwr31bF2MXBxCAkcYJR62 TWMFSQgJLGGU2LTYCqSeTcBCovufNkhYRCBPomPDRCaQemaBHkaJL4v/s4MkhAUcJa52LGaG KHKS2PvlJ5z98MEMNhCbRUBV4nT3FbD5vAK+Eo9XXWSEWPyGUeLV1o1ggzgFdCTmnnkAZjMC Xff91BomEJtZQFzi1pP5TBBXC0gs2XOeGcIWlXj5+B8rxGOKEsv75SDKdSQW7P7EBmFrSyxb +JoZYq+gxMmZT1gmMIrNQjJ1FpKWWUhaZiFpWcDIsopRtDi1uDg33chYL7UoM7m4OD9PLy+1 ZBMjMOoObvmtu4Nx9WvHQ4wCHIxKPLwFk7pChFgTy4orcw8xSnOwKInzLjo3L1hIID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QDYwdP+5ytEnx933flczhzJIV1dPplt+yaG3qqwevktF1Va/6+ U1vJecr1AYeNafADdsccuVNB7GGtddOiN358aVxmViq6YtadxNuXXnyp5rQ5GX3GNqLVw2LT AT/elY+TvinOdoq47zGpe27Nev5VHyTXnb9y1fBA6He1k3vnG0yZw11zxOvEJSWW4oxEQy3m ouJEAKHcxZubAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/qwGbVXFzVSxcESwSfCynQ4gN3lo Cc: "draft-holmberg-dispatch-iotl@tools.ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 12 Dec 2014 07:17:16 -0000 Hi, >>>> """ >>>> uri-parameter =3D transport-param / user-param / method-param / ttl-= param >>>> / maddr-param / lr-param / iotl-param /=20 >>>> other-param """ >>>> You should check with someone more knowledgeable about ABNF than me,=20 >>>> but I understand the better thing to do than redefining the=20 >>>> uri-parameter production is to update it, e.g. "uri-parameter =3D/ iot= l-param" >>> >>> Yes, that would be much clearer. >> >> AFAIK, that way of extending parameters have been deprecated, and one is= (again) supposed to re-define the whole parameter. >> >> But, Paul can correct me if I'm wrong :) > > What made you think that? I know of no such change, *in general*. Maybe I have misunderstood something, then - or I remember wrong. > There has been some discussion about whether such a change (using =3D/) c= onstitutes a revision to the base draft. (IMO it does, some=20 > people don't think so.) If you actually do the change as you did then I t= hink there is no question - it clearly is a revision! > > IMO, if you want to avoid such changes causing an update to the base docu= ment then you should do things such that the ABNF in the base document isn'= t modified. > > If there is a registry, then that really should serve as an alternative t= o listing values in ABNF. So then this issue doesn't come up. > > In this particular case, there now *is* a registry of URI parameters, and= your draft *is* asking for it to be updated. So I was wrong in=20 > suggesting that /=3D was better - I should have said that there should no= t be any change to the uri-parameter ABNF. Ok. So, what shall I do in this particular case? :) Regards, Christer From nobody Fri Dec 12 06:24:01 2014 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 72A171A1A81 for ; Fri, 12 Dec 2014 06:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Djo225kwKeMR for ; Fri, 12 Dec 2014 06:23:59 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6781A1A7E for ; Fri, 12 Dec 2014 06:23:59 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-07v.sys.comcast.net with comcast id SePb1p0072Qkjl901ePyqM; Fri, 12 Dec 2014 14:23:58 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-15v.sys.comcast.net with comcast id SePx1p00b1KKtkw01ePyu0; Fri, 12 Dec 2014 14:23:58 +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 sBCENueg030410 for ; Fri, 12 Dec 2014 09:23:56 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sBCENtbt030405; Fri, 12 Dec 2014 09:23:55 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-Reply-To: <548A256F.1010801@alum.mit.edu> (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 12 Dec 2014 09:23:54 -0500 Message-ID: <874mt154lh.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418394238; bh=Zn/mo69vFfqK3hZmsW/qk2auKXoO04Svh57titxNAvA=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:MIME-Version:Content-Type; b=fqsM0f1lVtSHztFNIlxBRFR1Hxse6hQoGx0VrqX19ZWH5LBVO3sK2QmN9ghg3ePhb JfRKsoCVnOYpCC34d2O2kNzMzLA6Ihn0Ot1D2JNyPLqXFUmujWqA90CmZLy2P6YS6r qoRB+NW84Ox95U04E054MSXXVKTfufJaiNdO/JMYzRNJ8wE7eaBtys5+22yhvfj5kl PpZKTbF8f8vWeUyb0YgFmB7UX70ch39gakG7Yq68zqdFLkIHDh1qx8BbD2gNs/gf1f CosQ5b4z80UyRMICyqQndQQWmUJZee6Jc27xQIz37TjOOhNbjJxLDt1CUTcsmBCH7O RKqyeA+tnAnkw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/XIzo2UuzRR0qoN8JXsP4JiwFBis Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 12 Dec 2014 14:24:00 -0000 Paul Kyzivat writes: > There has been some discussion about whether such a change (using =/) > constitutes a revision to the base draft. (IMO it does, some people > don't think so.) If you actually do the change as you did then I think > there is no question - it clearly is a revision! It could be argued both ways, I think. Strictly speaking, the change doesn't extend the set of strings that are generated by , so I could argue that the draft only extends the base RFC by providing additional interpretation to strings that are already valid. Dale From nobody Fri Dec 12 08:57:51 2014 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 AAD9A1ACF1D for ; Fri, 12 Dec 2014 08:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIPil5_C11Ek for ; Fri, 12 Dec 2014 08:57:44 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9131ACF13 for ; Fri, 12 Dec 2014 08:57:44 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-a3-548b1e86eb64 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 67.68.29772.68E1B845; Fri, 12 Dec 2014 17:57:42 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 17:57:42 +0100 From: Christer Holmberg To: "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] AD review of draft-holmberg-dispatch-iotl Thread-Index: AQHQFhdBZr5NpOwNi02y+0ZPv/YmtpyMLQZQ Date: Fri, 12 Dec 2014 16:57:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> References: <548A256F.1010801@alum.mit.edu> (pkyzivat@alum.mit.edu) <874mt154lh.fsf@hobgoblin.ariadne.com> In-Reply-To: <874mt154lh.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjW6bXHeIwe0pmhZLJy1gtXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgyjjx/zpLwQHWiqVrjjA3MK5g6WLk5JAQMJG4 cvw4I4QtJnHh3nq2LkYuDiGBI4wSb9fsZYJwljBKrPg2CSjDwcEmYCHR/U8bpEFEIETi87RO sGZhAUeJqx2LmSHiThJ7v/yEso0k/l3fAWazCKhK7F8whQ3E5hXwldi79zvYEUICORL/Ni1i B7E5BYwl9s/+CBZnBDro+6k1TCA2s4C4xK0n85kgDhWQWLLnPDOELSrx8vE/VghbSWLR7c9Q 9ToSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKFqcWpyUm25k pJdalJlcXJyfp5eXWrKJERglB7f8NtjB+PK54yFGAQ5GJR7egkldIUKsiWXFlbmHGKU5WJTE eReemxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXHq79/vpNnO3uxdOa1Pf5brYoW9j46U /DGO/fZT9nFK1/yfzY6LHPe2m+64u1bq3a7N69POVZ+dEP6n6CPf4UNh0qy1b5mfFHT8V+Uo i3P8s9XNwIH/r7tzW9wFFo453vK51wrKu7d4Kj+9oeRztzTqyv8J7SeCLjcLB7fNvVxWuk6j ePrnHjklluKMREMt5qLiRADmdEQgcwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/ztLakJtgGdfKG0_qeFf71S1jJEQ Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 12 Dec 2014 16:57:48 -0000 Hi, >> There has been some discussion about whether such a change (using =3D/)= =20 >> constitutes a revision to the base draft. (IMO it does, some people=20 >> don't think so.) If you actually do the change as you did then I think=20 >> there is no question - it clearly is a revision! > > It could be argued both ways, I think. Strictly speaking, the change doe= sn't extend=20 > the set of strings that are generated by , so I could argu= e that the=20 > draft only extends the base RFC by providing additional interpretation to= strings that > are already valid. My fingers are ready, waiting on the keyboard. Just tell me what to type :) Regards, Christer From nobody Fri Dec 12 09:06:39 2014 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 BEB501A1BC4 for ; Fri, 12 Dec 2014 09:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 3gY8ysMSZWvV for ; Fri, 12 Dec 2014 09:06:36 -0800 (PST) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E601A1BED for ; Fri, 12 Dec 2014 09:06:36 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id hy10so3791408vcb.28 for ; Fri, 12 Dec 2014 09:06:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HIYqayb43gKBlWIS1AEFLZyHLaqfe9LjlCcTWEl5bPo=; b=ZN+gdsmVezZM6Xc0r5N5fNbunX0LxW3CBQA0nIaE9PuU3OgpHDfbJBnLbGq29ExMu3 1PdtOTawIhw/Qh8hjtX8tUKovNABNNgpW8TRre4N54kpv+XLzOvAxJnB0KSY65RvnRfg AOdgSwzNVlj8AemZK7P61SYFy7E7rQn/CpajLPlp3pJanrdCXWcr85oYrjKqkoyEMiI8 ID+hMPwBfCe4RV5xu/zfg6tTbUDAdz/pbmkZQCV6ozdCdTyjAJo/K0CUYegSwkrRnpRo 99FgqMrnlOdUVGY2m87/ht3nDqubuFqoqTsk+Wl/dXlayynhjSYTG+0oTm0I1j0vNlVz 9tmQ== X-Gm-Message-State: ALoCoQniXwKn94HrIYMlruaS5wP3YsJoedP21P1wHRbUQrKUbbqwb7s1wNJeGm6m2juSe55uwGQJ MIME-Version: 1.0 X-Received: by 10.52.117.161 with SMTP id kf1mr9182569vdb.65.1418403995332; Fri, 12 Dec 2014 09:06:35 -0800 (PST) Received: by 10.31.139.9 with HTTP; Fri, 12 Dec 2014 09:06:35 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> References: <548A256F.1010801@alum.mit.edu> <874mt154lh.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> Date: Fri, 12 Dec 2014 12:06:35 -0500 Message-ID: From: Richard Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec547cbdd4a44ce050a07eac1 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/oTGXpXGVhhc4XgkXAq3gg6z3qvs Cc: "dispatch@ietf.org" Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 12 Dec 2014 17:06:38 -0000 --bcaec547cbdd4a44ce050a07eac1 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 12, 2014 at 11:57 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >> There has been some discussion about whether such a change (using =/) > >> constitutes a revision to the base draft. (IMO it does, some people > >> don't think so.) If you actually do the change as you did then I think > >> there is no question - it clearly is a revision! > > > > It could be argued both ways, I think. Strictly speaking, the change > doesn't extend > > the set of strings that are generated by , so I could > argue that the > > draft only extends the base RFC by providing additional interpretation > to strings that > are already valid. > > My fingers are ready, waiting on the keyboard. Just tell me what to type :) > My vote is for "=/", FWIW. Note that there's about a 45% chance that someone will express a preference during LC / IESG eval as well. So maybe hold off for now? --Richard > > Regards, > > Christer > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --bcaec547cbdd4a44ce050a07eac1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 12, 2014 at 11:57 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
Hi,

>> There has been some discussion about whether such a change (using = =3D/)
>> constitutes a revision to the base draft. (IMO it does, some peopl= e
>> don't think so.) If you actually do the change as you did then= I think
>> there is no question - it clearly is a revision!
>
> It could be argued both ways, I think.=C2=A0 Strictly speaking, the ch= ange doesn't extend
> the set of strings that are generated by <uri-parameter>, so I c= ould argue that the
> draft only extends the base RFC by providing additional interpretation= to strings that > are already valid.

My fingers are ready, waiting on the keyboard. Just tell me what to = type :)

My vote is for "=3D/"= , FWIW.

Note that there's about a 45% chance t= hat someone will express a preference during LC / IESG eval as well.=C2=A0 = So maybe hold off for now?

--Richard
=C2=A0

Regards,

Christer

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

--bcaec547cbdd4a44ce050a07eac1-- From nobody Fri Dec 12 09:12:27 2014 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 BE0EB1A6FC7 for ; Fri, 12 Dec 2014 09:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_6O58wotD-v for ; Fri, 12 Dec 2014 09:12:22 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01BE1A009E for ; Fri, 12 Dec 2014 09:12:20 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-21-548b21f2bf05 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7C.0C.24955.2F12B845; Fri, 12 Dec 2014 18:12:18 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 18:12:18 +0100 From: Christer Holmberg To: Richard Barnes , DISPATCH , "draft-holmberg-dispatch-iotl@tools.ietf.org" Thread-Topic: AD review of draft-holmberg-dispatch-iotl - Richard's comments Thread-Index: AdAWLtEw1A0azC12SzihW51ibclWYA== Date: Fri, 12 Dec 2014 17:12:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D59252D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvje4nxe4QgwNdlhZLJy1gtdi/cwar xdQ+WwdmjyVLfjJ5TN44i8Xjy+XPbAHMUVw2Kak5mWWpRfp2CVwZH95MYyv4pFLxp3UVewPj D+UuRg4OCQETib27UrsYOYFMMYkL99azdTFycQgJHGGUWLW8DcpZwijRtOAKC0gDm4CFRPc/ bZC4iMA8Ronnv3YygnQLC3hLrN+5gxXEFhHwkWhtb2KDsPUknry4yARiswioSpw88R4szivg K3H/Th87iM0ItPn7qTVgNcwC4hK3nsxngrhIQGLJnvPMELaoxMvH/1ghbCWJRbc/M4Hcwyyg KbF+lz5Eq6LElO6H7BDjBSVOznzCMoFReBaSqbMQOmYh6ZiFpGMBI8sqRtHi1OKk3HQjY73U oszk4uL8PL281JJNjMAoOLjlt+oOxstvHA8xCnAwKvHwFkzqChFiTSwrrsw9xCjNwaIkzrvw 3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwm8rll936/WvVV/dCCJf7bziTlGtk/uXTA nHvS6fb8iQdZT7Pq9y5kvsj83fDlu9pXXy8wHGo5J55opbfziU1WZ3nupg+8NR8DDjp8ufzx 3ZFvq5OeFt5+Vi+Q5LZX6XGITYToL5NnRtWfIxPTpvS9uPiqYt7faTsz1TUuyBR9rFs7s0Fb V1FDiaU4I9FQi7moOBEA6tGYBWMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/Vh5Uu98JYqe4NFYtD-B_FWH4q3M Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl - Richard's comments 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, 12 Dec 2014 17:12:24 -0000 SGkgUmljaGFyZCwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzISBTZWUgaW5saW5lLg0KDQoo SSBoYXZlIHJlbW92ZWQgdGhlIGNvbW1lbnRzIHRoYXQgYXJlIGNvdmVyZWQgaW4gc2VwYXJhdGUg dGhyZWFkcykNCg0KPiBUaGUgZG9jdW1lbnQgc2F5cyBjbGVhcmx5IGhvdyB0byBpbmRpY2F0ZSBh IHRyYWZmaWMgbGVnLCBidXQgbmV2ZXIgcmVhbGx5IHN0YXRlcyAqd2h5KiBhIG5ldHdvcmsgZWxl bWVudCB3b3VsZCANCj4gY2FyZSB3aGF0IHR5cGUgb2YgdHJhZmZpYyBsZWcgYSBtZXNzYWdlIGlz IHBhcnQgb2YuwqAgSXMgdGhlcmUgYW4gZXhhbXBsZSB0aGF0IGNvdWxkIGJlIGdpdmVuPw0KDQpU aGUgSW50cm9kdWN0aW9uIHNlY3Rpb24gY29udGFpbnMgdGhlIGZvbGxvd2luZzoNCg0KCSJUaGUg dHJhZmZpYyBsZWcgaW5mb3JtYXRpb24gY2FuIGJlIHVzZWQgYnkgaW50ZXJtZWRpYXJ5IGVudGl0 aWVzIHRvDQogICAJbWFrZSBwb2xpY3kgZGVjaXNpb25zLCByZWxhdGVkIHRvIGUuZy4gbWVkaWEg YW5jaG9yaW5nLCBzaWduYWxsaW5nDQogICAJcG9saWN5LCBpbnNlcnRpb24gb2YgbWVkaWEgZnVu Y3Rpb25zIChlLmcuIHRyYW5zY29kZXIpIGFuZCBjaGFyZ2luZy4iDQoNCg0KLS0tLS0tLS0tLS0t LS0tLQ0KDQoNCj4gSXQgc2VlbXMgbGlrZSBTZWN0aW9uIDUuMi4xIGNvdWxkIGp1c3QgYmUgaW5j bHVkZWQgZGlyZWN0bHkgdW5kZXIgU2VjdGlvbiA1LjIuDQoNCkkgYW0gc3VyZSBLZWl0aCBjYW4g dGVsbCB5b3Ugd2h5IHRoYXQgaXMgYSBiYWQgaWRlYSA6KQ0KDQpJIGhhdmUgYmVlbiB1c2luZyB0 aGlzIHN0cnVjdHVyZSBpbiBvdGhlciBkcmFmdHMgdG9vLCBzbyBJJ2QgbGlrZSB0byBrZWVwIGl0 Lg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0NCg0KDQo+IFNlY3Rpb24gNS4yLjEgbmVlZHMgdG8gaW5j bHVkZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gYSAzR1BQIHNwZWMgZGVmaW5pbmcgImhvbWUi IGFuZCAidmlzaXRlZCIuDQoNCkknbGwgdGFrZSBhIGxvb2sgYXQgdGhhdC4NCg0KDQotLS0tLS0t LS0tLS0tLS0tDQoNCj4gVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGlzIGJhc2ljYWxseSBz YXlpbmcsICJCZSBjYXJlZnVsIG1ha2luZyBkZWNpc2lvbnMgYmFzZWQgb24gdGhpcyANCj4gcGFy YW1ldGVyLCBiZWNhdXNlIGFueW9uZSBjb3VsZCBjaGFuZ2UgaXQiLsKgIFRoZSBSRkMgMjExOSBs YW5ndWFnZSBpcyBoZWxwZnVsLCBiZWNhdXNlIGl0IA0KPiByZWZlcnMgdG8gdW5kZWZpbmVkIGNv bmNlcHRzLsKgIEl0IHdvdWxkIGJlIGJldHRlciB0byByZWZlciB0byBkb2N1bWVudHMgdGhhdCBo YXZlIGEgZGVmaW5lZCANCj4gY29uY2VwdCBvZiB0cnVzdCBib3VuZGFyaWVzLCBlLmcuLCBSRkMg MzMyNSBmb3IgdGhlIG5vdGlvbiBvZiBTcGVjKFQpLg0KDQpJIGFtIG5vdCBzdXJlIEkgdW5kZXJz dGFuZCB3aGF0IHlvdSBtZWFuLg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0NCg0KDQo+IiIiDQo+wqAg wqBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgU0lQIFVSSSBwYXJhbWV0ZXIsICdpb3RsJywg d2hpY2ggY2FuIGJlDQo+wqAgwqB1c2VkIGluIGEgU0lQIFVSSSB0byBpbmRpY2F0ZSB0aGF0IHRo ZSBlbnRpdHkgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KPsKgIMKgYWRkcmVzcywgb3IgYW4gZW50aXR5 IHJlc3BvbnNpYmxlIGZvciB0aGUgaG9zdCBwYXJ0IG9mIHRoZSBhZGRyZXNzLA0KPsKgIMKgcmVw cmVzZW50cyB0aGUgZW5kIG9mIGEgc3BlY2lmaWMgdHJhZmZpYyBsZWcgKG9yIG11bHRpcGxlIHRy YWZmaWMNCj7CoCDCoGxlZ3MpLg0KPiIiIg0KPiBUaGlzIHNlbnRlbmNlIGlzIHJlYWxseSBsb25n LCBhbmQgSSBkb24ndCB0aGluayBpdCdzIGdyYW1tYXRpY2FsLsKgIEF0IGxlYXN0IG15IGludGVy bmFsIGJyYWluIGNvdWxkbid0IHBhcnNlIGl0LsKgIA0KPiBMaWtld2lzZSB0aGUgY29ycmVzcG9u ZGluZyBzZW50ZW5jZSBpbiBTZWN0aW9uIDEuDQoNCkkgY291bGQgc3BsaXQgaXQgaW50byB0d28g c2VudGVuY2VzOg0KDQoJIlRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBTSVAgVVJJIHBhcmFt ZXRlciwgJ2lvdGwnLiBUaGUgcGFyYW1ldGVyIA0KCWNhbiBiZSB1c2VkIGluIGEgU0lQIFVSSSB0 byBpbmRpY2F0ZSB0aGF0IHRoZSBlbnRpdHkgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KICAgCWFkZHJl c3MsIG9yIGFuIGVudGl0eSByZXNwb25zaWJsZSBmb3IgdGhlIGhvc3QgcGFydCBvZiB0aGUgYWRk cmVzcywNCiAgIAlyZXByZXNlbnRzIHRoZSBlbmQgb2YgYSBzcGVjaWZpYyB0cmFmZmljIGxlZyAo b3IgbXVsdGlwbGUgdHJhZmZpYyBsZWdzKS4iDQoNCg0KLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCj4g ImFuIGVuZCB1c2VyIGNhbiBiZSBhdHRhY2hlZCINCj4gRG9uJ3QgeW91IG1lYW4gImFuIGVuZCB1 c2VyICpkZXZpY2UqIj/CoCBUaGUgaWRlYSBvZiBlbmQgdXNlcnMgYmVpbmcgYXR0YWNoZWQgdG8g dGhlIG5ldHdvcmsgY2FsbHMgdG8gbWluZCBzY2VuZXMgZnJvbSB0aGUgTWF0cml4IA0KPiA6KSDC oGh0dHA6Ly9tYXRyaXhjb21tdW5pdHkub3JnL3dvcmRwcmVzcy93cC1jb250ZW50L3VwbG9hZHMv MjAxNC8wNC9OZW8tYW5kLXRoZS1wb2RzLmpwZw0KDQpXaGlsZSBiZWluZyBhYmxlIHRvIGFzc29j aWF0ZSB0aGUgZHJhZnQgd2l0aCBNYXRyaXggd291bGQgYmUgc29vb29vbyBjb29sLCBJJ2xsIGFk ZCB0aGUgZGV2aWNlIHBhcnQgOikNCg0KDQotLS0tLS0tLS0tLS0tLS0tDQoNCg0KPiAiSWYsIHdp dGhpbiBhbiBpbml0aWFsIHJlcXVlc3QgZm9yIGEgZGlhbG9nLi4uaWRlbnRpZmllcyB0aGUgdHlw ZSBvZiB0cmFmZmljIGxlZyINCj4gKiBUaGlzIHNlY3Rpb24gb24gY2hvb3Npbmcgd2hpY2ggJ2lv dGwnIHBhcmFtZXRlciB0byB1c2UgaXMgdXNlZnVsLsKgIEVkaXRvcmlhbGx5LCBpdCB3b3VsZCBi ZSBhIA0KPiBsaXR0bGUgY2xlYXJlciB0byBwdWxsIGl0IG91dCBpbnRvIGJ1bGxldCBwb2ludHMs IGFuZCBwcmVmYWNlIHdpdGggIkEgU0lQIGVudGl0eSBkZXRlcm1pbmVzIHRoZSANCj4gdHlwZSBv ZiB0cmFmZmljIGxlZyBpbiB0aGUgZm9sbG93aW5nIHdheSIuwqAgSSB3b3VsZCBhbHNvIHN1Z2dl c3QgY29uc2lkZXJpbmcgd2hldGhlciBwdXR0aW5nIA0KPiBhIE1VU1QgaGVyZSB3b3VsZCBiZSBh cHByb3ByaWF0ZSwgZS5nLiwgIlNJUCBlbnRpdGllcyB0aGF0IHVuZGVyc3RhbmQgdGhlICdpb3Rs JyBwYXJhbWV0ZXIgDQo+IE1VU1QgdXNlIHRoZSBmb2xsb3dpbmcgcnVsZXMgdG8gZGV0ZXJtaW5l IHRoZSB0eXBlIG9mIHRyYWZmaWMgbGVnLi4uIg0KDQpJIGluaXRpYWxseSB0cmllZCB0byBwdXQg ZXZlcnl0aGluZyBpbnRvIGJ1bGxldCBwb2ludHMsIGJ1dCBkaWRuJ3QgZmlndXJlIG91dCBob3cg dG8gZG8gaXQgaW4gYSBnb29kIHdheS4NCg0KQnV0LCBJIGNhbiBnaXZlIGl0IGFub3RoZXIgdHJ5 Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Fri Dec 12 13:07:31 2014 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 2ECDE1A1BC0 for ; Fri, 12 Dec 2014 13:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUVZCaUILt1l for ; Fri, 12 Dec 2014 13:07:29 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85821A1A37 for ; Fri, 12 Dec 2014 13:07:28 -0800 (PST) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-10v.sys.comcast.net with comcast id Sl721p0072N9P4d01l7Tm6; Fri, 12 Dec 2014 21:07:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-13v.sys.comcast.net with comcast id Sl7T1p00K3Ge9ey01l7T0m; Fri, 12 Dec 2014 21:07:27 +0000 Message-ID: <548B590F.2090709@alum.mit.edu> Date: Fri, 12 Dec 2014 16:07:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <548A256F.1010801@alum.mit.edu> (pkyzivat@alum.mit.edu) <874mt154lh.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418418447; bh=E+ZZvyMUrlup2HDGU94mw+lRbqjL4bHAzgrlcXSbGLQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OV3z/Gh1EqMXrVsoTxZoshY2CDCCHm5xHWrM+/crS/7exfT9qx0BnIqEZFYJM12Oc BeGC2TmSRREu9E8hPAf5cFtZuYSIC2FPJSqIrIl0SMXJNx2fa/z6AJCtT7c0gtdpZR kaeT07vw4n10wR64m32OhJuWtDOXQwcAzotwWWWuwEbh5BvZhbm3qINpXmhxJV8Cvl tGm59dLlLi0fB/FUNaKXBZuBbwQevpq+i9uwqwWvVZb30qMAGpyimm95IJ2uxCc7+p MR3GaHKxggSbXTGdW0a+ZzIk9x08Oj+oihRhPDDCXelXi92e4Zh1VAxr0vZYDqQknq W25Q865mfQWRg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/aAWLJNdvf95lvddQw-HfNEuh0Uo Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 12 Dec 2014 21:07:30 -0000 On 12/12/14 11:57 AM, Christer Holmberg wrote: > Hi, > >>> There has been some discussion about whether such a change (using =/) >>> constitutes a revision to the base draft. (IMO it does, some people >>> don't think so.) If you actually do the change as you did then I think >>> there is no question - it clearly is a revision! >> >> It could be argued both ways, I think. Strictly speaking, the change doesn't extend >> the set of strings that are generated by , so I could argue that the >> draft only extends the base RFC by providing additional interpretation to strings that > are already valid. > > My fingers are ready, waiting on the keyboard. Just tell me what to type :) My preference is that you not provide any ABNF extending the values for uri-parameter. The IANA considerations section are sufficient. Obviously we have a difference of opinion here. Thanks, Paul From nobody Fri Dec 12 13:32:52 2014 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 181C61A1A37 for ; Fri, 12 Dec 2014 13:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9T2dvpLCuVI for ; Fri, 12 Dec 2014 13:32:50 -0800 (PST) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337811A0397 for ; Fri, 12 Dec 2014 13:32:50 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-01v.sys.comcast.net with comcast id SlYE1p00B57bBgG01lYpzb; Fri, 12 Dec 2014 21:32:49 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-po-13v.sys.comcast.net with comcast id SlYo1p00B1KKtkw01lYpug; Fri, 12 Dec 2014 21:32:49 +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 sBCLWm4D031143; Fri, 12 Dec 2014 16:32:48 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sBCLWlXV031142; Fri, 12 Dec 2014 16:32:47 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 12 Dec 2014 16:32:47 -0500 Message-ID: <87iohgtuyo.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418419969; bh=yaFkquxQTc4eGx7jsOO9JLCfePQjuDs/vzj7UvaQ7Ew=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:MIME-Version:Content-Type; b=q6hxIl5WMxYbgoPnAm/UYPxXw7tnkG6kN0akhdVuUKepgli+tKU3F4GxbiQZ9c3Qd zwm0QyUm9I2N6auoAkq6Nlmq7KEuKeEIAHKespFT7AnkALsa5mXNN0m+ReWcfaJ73E zetJy+fWeDe7wnBPeXfNOSq/6o0Zl61UNkUAx0xjNAqno6LybdycOycDXekXh/r9KQ cmxtFSalRecbKof24zQtz06i9rLdWQo52vKE01jmYzVoebDO8qDhJtnVhQRxsuYEG8 DWT2Y6l9wOPQQ+VLdGBxB1yfMnuKRxgAMgS1fnCAQCJPRjMJdt2Rco1M4+WsP5pD6K K8EgBEOSKoqPg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/nL1tzwr2M2DSfk5JgT0OGyKLMOU Cc: dispatch@ietf.org Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 12 Dec 2014 21:32:51 -0000 Christer Holmberg writes: >> It could be argued both ways, I think. Strictly speaking, the change >> doesn't extend the set of strings that are generated by >> , so I could argue that the draft only extends the >> base RFC by providing additional interpretation to strings that > are >> already valid. > > My fingers are ready, waiting on the keyboard. Just tell me what to type :) Personally, I'd ask the AD what the right way to treat it is. Dale From nobody Sun Dec 14 09:32:05 2014 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 3668A1A0113 for ; Sun, 14 Dec 2014 09:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-bJEy-tLMGc for ; Sun, 14 Dec 2014 09:32:02 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 301E11A010C for ; Sun, 14 Dec 2014 09:32:01 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id CD00EEFC01355; Sun, 14 Dec 2014 17:31:56 +0000 (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 sBEHVxIG028806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Dec 2014 18:31:59 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sun, 14 Dec 2014 18:31:59 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] AD review of draft-holmberg-dispatch-iotl Thread-Index: AQHQFk+oWDyZe1mldUGUh5XqNnd/XZyPWSFw Date: Sun, 14 Dec 2014 17:31:59 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B294A17@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <548A256F.1010801@alum.mit.edu> (pkyzivat@alum.mit.edu) <874mt154lh.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> <548B590F.2090709@alum.mit.edu> In-Reply-To: <548B590F.2090709@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/1LmgZ0jvVOThtdJCjtMLODHMhU0 Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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: Sun, 14 Dec 2014 17:32:04 -0000 The IANA considerations section extends nothing - it is merely a set of ins= tructions to IANA on how to update the registration tables. Therefore what you propose is not a practical solution to the documentation= . Regards Keith=20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: 12 December 2014 21:07 > To: dispatch@ietf.org > Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl >=20 > On 12/12/14 11:57 AM, Christer Holmberg wrote: > > Hi, > > > >>> There has been some discussion about whether such a change (using=20 > >>> =3D/) constitutes a revision to the base draft. (IMO it does, some=20 > >>> people don't think so.) If you actually do the change as you did=20 > >>> then I think there is no question - it clearly is a revision! > >> > >> It could be argued both ways, I think. Strictly speaking,=20 > the change=20 > >> doesn't extend the set of strings that are generated by=20 > >> , so I could argue that the draft only=20 > extends the base RFC by providing additional interpretation=20 > to strings that > are already valid. > > > > My fingers are ready, waiting on the keyboard. Just tell me what to=20 > > type :) >=20 > My preference is that you not provide any ABNF extending the=20 > values for uri-parameter. The IANA considerations section are=20 > sufficient. >=20 > Obviously we have a difference of opinion here. >=20 > Thanks, > Paul >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From nobody Sun Dec 14 12:29:07 2014 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 2D8FB1A0183 for ; Sun, 14 Dec 2014 12:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pp3t4Q1xHg-n for ; Sun, 14 Dec 2014 12:29:04 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338CC1A0181 for ; Sun, 14 Dec 2014 12:29:03 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-69-548df30da3db Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8E.51.24955.D03FD845; Sun, 14 Dec 2014 21:29:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0195.001; Sun, 14 Dec 2014 21:29:01 +0100 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] AD review of draft-holmberg-dispatch-iotl Thread-Index: AQHQFhdBZr5NpOwNi02y+0ZPv/YmtpyMLQZQgAA1S4CAAuh3gIAAQT7g Date: Sun, 14 Dec 2014 20:29:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5B4C9F@ESESSMB209.ericsson.se> References: <548A256F.1010801@alum.mit.edu> (pkyzivat@alum.mit.edu) <874mt154lh.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> <548B590F.2090709@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B294A17@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B294A17@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvjS7f594Qg743zBZLJy1gtXjaeJbR YsWGA6wOzB6tz/ayevx9/4HJY8mSn0wBzFFcNimpOZllqUX6dglcGV9ftLMWrBGs2Dr3KWsD YzdfFyMnh4SAiUTfgh+sELaYxIV769m6GLk4hASOMEosmdPBDuEsZpRo+NTH1MXIwcEmYCHR /U8bJC4i0MMo8fniCrBuYQFHiasdi5lBbBEBJ4m9X35C2W4Sjcf2gtksAqoSD06/ZQOZwyvg K/FvCjdIGGg+k8Slh2AHcQpES+y6/RtsJCPQQd9PrWECsZkFxCVuPZnPBHGogMSSPeeZIWxR iZeP/0E9oCSx9vB2Foh6HYkFuz+xQdjaEssWvgar5xUQlDg58wnLBEbRWUjGzkLSMgtJyywk LQsYWVYxihanFiflphsZ66UWZSYXF+fn6eWllmxiBMbOwS2/VXcwXn7jeIhRgINRiYd3Q25v iBBrYllxZe4hRmkOFiVx3oXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYPR+zeYisYn5 /r6fmfp+33/8WfZKeAdLIHvcE7tHPrvO9SelW+YyMzsyMPVV792yM9RJvOP21iPy//m4xW9t +JG/zPVfrOMBba//XPJZTCvmlmuapR66G/jytsCaw2osTJOmf5UtNVEO2m/xNkWWO7idzf+N +svVX7/Vf9zjVH327EuN+MZqESWW4oxEQy3mouJEAKhyWOx+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/-KegZkAkL9PUnhOVZrc2Al71ahE Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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: Sun, 14 Dec 2014 20:29:06 -0000 Hi, I suggest to keep the text as it is. I am sure the wise men and women of th= e IESG will guide me in the right direction, to get it right. Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith= (Keith) Sent: 14 December 2014 19:32 To: Paul Kyzivat; dispatch@ietf.org Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl The IANA considerations section extends nothing - it is merely a set of ins= tructions to IANA on how to update the registration tables. Therefore what you propose is not a practical solution to the documentation= . Regards Keith=20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul=20 > Kyzivat > Sent: 12 December 2014 21:07 > To: dispatch@ietf.org > Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl >=20 > On 12/12/14 11:57 AM, Christer Holmberg wrote: > > Hi, > > > >>> There has been some discussion about whether such a change (using > >>> =3D/) constitutes a revision to the base draft. (IMO it does, some=20 > >>> people don't think so.) If you actually do the change as you did=20 > >>> then I think there is no question - it clearly is a revision! > >> > >> It could be argued both ways, I think. Strictly speaking, > the change > >> doesn't extend the set of strings that are generated by=20 > >> , so I could argue that the draft only > extends the base RFC by providing additional interpretation to strings=20 > that > are already valid. > > > > My fingers are ready, waiting on the keyboard. Just tell me what to=20 > > type :) >=20 > My preference is that you not provide any ABNF extending the values=20 > for uri-parameter. The IANA considerations section are sufficient. >=20 > Obviously we have a difference of opinion here. >=20 > Thanks, > Paul >=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 Mon Dec 15 00:26:45 2014 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 390FC1A1A28 for ; Mon, 15 Dec 2014 00:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnDyh6XZQXOq for ; Mon, 15 Dec 2014 00:26:40 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205071A1A3A for ; Mon, 15 Dec 2014 00:26:39 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-44-548e9b3d6d81 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 29.B2.29772.D3B9E845; Mon, 15 Dec 2014 09:26:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 09:26:37 +0100 From: Christer Holmberg To: Richard Barnes , DISPATCH , "draft-holmberg-dispatch-iotl@tools.ietf.org" Thread-Topic: AD review of draft-holmberg-dispatch-iotl - Richard's comment on terminology Thread-Index: AdAYQIxABVRvlYeuShWaaRI1fI0KvA== Date: Mon, 15 Dec 2014 08:26:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5B6BED@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvja7d7L4Qg+/L2SyWTlrAarF/5wxW i6l9tg7MHkuW/GTymLxxFovHl8uf2QKYo7hsUlJzMstSi/TtErgyLj24z1bwiKnidMNvlgbG G0xdjJwcEgImEgvO/GKEsMUkLtxbz9bFyMUhJHCEUWLGh9tMEM5iRomzv28BORwcbAIWEt3/ tEHiIgLzGCWe/9oJ1i0sEC2xed0tsKkiAjESp9fPZoGw9SRu7dnFBmKzCKhKzNyxiB3E5hXw lbj16ykziM0ItPn7qTVgvcwC4hK3nsyHuk5AYsme88wQtqjEy8f/WCFsRYmr05eD3cMsoCmx fpc+RKuixJTuh1DjBSVOznzCMoFReBaSqbMQOmYh6ZiFpGMBI8sqRtHi1OKk3HQjI73Uoszk 4uL8PL281JJNjMA4OLjlt8EOxpfPHQ8xCnAwKvHwFoj1hQixJpYVV+YeYpTmYFES5114bl6w kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYlGelFrHZTQqK1PbguXDr+r7l1ubsXz4zW9obf /5NbjjxjddBXMizx7wyLnHDoM9+SolaOwC7HDPXbny7++9HeGK9yPPbZ/n/cJ44r+249d2rT 3uzkfLGcnSmuXt6PD972tQ80erLhmjh73LyOb78U2cOLOYyzZmW5m8VX2Gm9nNrOtvPIRSWW 4oxEQy3mouJEAArZkxNkAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/0l4YIY63NXZZ0X85GjPd_j-6iGA Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl - Richard's comment on terminology 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, 15 Dec 2014 08:26:42 -0000 SGksDQoNCj4gU2VjdGlvbiA1LjIuMSBuZWVkcyB0byBpbmNsdWRlIGEgbm9ybWF0aXZlIHJlZmVy ZW5jZSB0byBhIDNHUFAgc3BlYyBkZWZpbmluZyAiaG9tZSIgYW5kICJ2aXNpdGVkIi4NCg0KSSds bCBhZGQgYSByZWZlcmVuY2UgdG8gM0dQUCBUUyAyMS45MDUsIHdoaWNoIGlzIHRoZSAzR1BQIHRl cm1pbm9sb2d5IHNwZWNpZmljYXRpb24sIHdoaWNoIGRlZmluZXMgImhvbWUiIGFuZCAidmlzaXRl ZCIuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From nobody Mon Dec 15 05:10:31 2014 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 E51791A1BB5 for ; Mon, 15 Dec 2014 05:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZ8GuSL-NugJ for ; Mon, 15 Dec 2014 05:10:27 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7661A1AC3 for ; Mon, 15 Dec 2014 05:10:26 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-8d-548eddc0bc51 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 71.3E.29772.0CDDE845; Mon, 15 Dec 2014 14:10:25 +0100 (CET) Received: from ESESSMB208.ericsson.se ([169.254.8.173]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 14:10:24 +0100 From: Christer Holmberg To: Richard Barnes , DISPATCH , "draft-holmberg-dispatch-iotl@tools.ietf.org" Thread-Topic: AD review of draft-holmberg-dispatch-iotl - Richard's comment on 'iotl' parameter selection Thread-Index: AdAYaALHbjZKm7XnTVOaj9K99kW6VQ== Date: Mon, 15 Dec 2014 13:10:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5C4A1D@ESESSMB208.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvje7Bu30hBo/nM1osnbSA1WL/zhms FlP7bB2YPZYs+cnkMXnjLBaPL5c/swUwR3HZpKTmZJalFunbJXBl3HjaxVgwS7DiZt9plgbG BwJdjJwcEgImEkuu7WKBsMUkLtxbz9bFyMUhJHCEUWJT7x4WCGcJo8T/lhNADgcHm4CFRPc/ bZC4iMA8Ronnv3YygnQLC2RJrFh2C6xGRCBb4tsPIZCwiICexLr+F+wgNouAqsSslm/MIDav gK/E0R2XmEBsRqDF30+tAbOZBcQlbj2ZzwRxkIDEkj3nmSFsUYmXj/+xQthKEj82XAJbxSyg KbF+lz5Eq6LElO6H7BDjBSVOznzCMoFReBaSqbMQOmYh6ZiFpGMBI8sqRtHi1OKk3HQjI73U oszk4uL8PL281JJNjMAoOLjlt8EOxpfPHQ8xCnAwKvHwFoj1hQixJpYVV+YeYpTmYFES5114 bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkb9C5XTv+d7qAZFxor06F08znjfqoxpeXZ2 y7b8pr0XS9svbW3tPyjW8ml2yfsZmy1cRPhzEpc23A0/92TPp7m3lvR4vi5gSWGNfut6RLf8 fqk6t8zbvG+X51yO/Bt29s56b2e5BNYfT7fZzih89V7u+qPlquH2J+Xa+VzTY9h5XN7cnGxQ LK/EUpyRaKjFXFScCACwmYdpYwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/lu8IzX_1Bn-RvDTMBSJz1bujpIE Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl - Richard's comment on 'iotl' parameter selection 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, 15 Dec 2014 13:10:29 -0000 SGkgUmljaGFyZCwNCg0KPiAiSWYsIHdpdGhpbiBhbiBpbml0aWFsIHJlcXVlc3QgZm9yIGEgZGlh bG9nLi4uaWRlbnRpZmllcyB0aGUgdHlwZSBvZiB0cmFmZmljIGxlZyINCj4gKiBUaGlzIHNlY3Rp b24gb24gY2hvb3Npbmcgd2hpY2ggJ2lvdGwnIHBhcmFtZXRlciB0byB1c2UgaXMgdXNlZnVsLsKg IEVkaXRvcmlhbGx5LCBpdCB3b3VsZCANCj4gYmUgYSBsaXR0bGUgY2xlYXJlciB0byBwdWxsIGl0 IG91dCBpbnRvIGJ1bGxldCBwb2ludHMsIGFuZCBwcmVmYWNlIHdpdGggIkEgU0lQIGVudGl0eSBk ZXRlcm1pbmVzIA0KPiB0aGUgdHlwZSBvZiB0cmFmZmljIGxlZyBpbiB0aGUgZm9sbG93aW5nIHdh eSIuwqAgSSB3b3VsZCBhbHNvIHN1Z2dlc3QgY29uc2lkZXJpbmcgd2hldGhlciANCj4gcHV0dGlu ZyBhIE1VU1QgaGVyZSB3b3VsZCBiZSBhcHByb3ByaWF0ZSwgZS5nLiwgIlNJUCBlbnRpdGllcyB0 aGF0IHVuZGVyc3RhbmQgdGhlICdpb3RsJyANCj4gcGFyYW1ldGVyIE1VU1QgdXNlIHRoZSBmb2xs b3dpbmcgcnVsZXMgdG8gZGV0ZXJtaW5lIHRoZSB0eXBlIG9mIHRyYWZmaWMgbGVnLi4uIg0KDQpX aGF0IGFib3V0IHRoZSBmb2xsb3dpbmc6DQoNCiAgICJXaGVuIGEgU0lQIGVudGl0eSByZWNlaXZl cyBhbiBpbml0aWFsIHJlcXVlc3QgZm9yIGEgZGlhbG9nLCBvciBhDQogICBzdGFuZC1hbG9uZSBy ZXF1ZXN0LCB3aGljaCBjb250YWlucyBvbmUgb3IgbW9yZSBTSVAgVVJJICdpb3RsJw0KICAgcGFy YW1ldGVycywgaXQgaWRlbnRpZmllcyB0aGUgdHlwZSBvZiB0cmFmZmljIGxlZyBpbiB0aGUgZm9s bG93aW5nDQogICB3YXk6DQoNCiAgIG8gIElmIHRoZSBTSVAgcmVxdWVzdCBjb250YWlucyBhIHNp bmdsZSBSb3V0ZSBoZWFkZXIgZmllbGQgY29udGFpbmluZw0KICAgICAgYSBTSVAgVVJJIHdpdGgg YW4gJ2lvdGwnIHBhcmFtdGVyLCB0aGF0IHBhcmFtZXRlciBpZGVudGlmaWVzIHRoZQ0KICAgICAg dHlwZSBvZiB0cmFmZmljIGxlZzsNCg0KICAgbyAgSWYgdGhlIFNJUCByZXF1ZXN0IGNvbnRhaW5z IG11bHRpcGxlIFJvdXRlIGhlYWRlciBmaWVsZHMNCiAgICAgIGNvbnRhaW5pbmcgYSBTSVAgVVJJ IHdpdGggYW4gJ2lvdGwnIHBhcmFtZXRlciwgdGhlICdpb3RsJw0KICAgICAgcGFyYW1ldGVyIGFz c29jaWF0ZWQgd2l0aCB0aGUgU0lQIFVSSSBvZiB0aGUgdG9wbW9zdCBSb3V0ZSBoZWFkZXINCiAg ICAgIGZpZWxkIChvciwgaWYgdGhlIFNJUCBVUkkgb2YgdGhlIHRvcG1vc3QgUm91dGUgaGVhZGVy IGZpZWxkIGRvZXMNCiAgICAgIG5vdCBjb250YWluIGFuICdpb3RsJyBwYXJhbWV0ZXIsIHRoZSBT SVAgVVJJIG9mIHRoZSBSb3V0ZSBoZWFkZXINCiAgICAgIGZpZWxkIGNsb3Nlc3QgdG8gdGhlIHRv cG1vc3QpIGlkZW50aWZpZXMgdGhlIHR5cGUgb2YgdHJhZmZpYyBsZWc7DQogICAgICBvcg0KDQog ICBvICBJZiBhIFNJUCByZXF1ZXN0IGNvbnRhaW5zIGFuICdpb3RsJyBwYXJhbWV0ZXIgb25seSBp biB0aGUgUmVxdWVzdC0NCiAgICAgIFVSSSBTSVAgVVJJLCB0aGUgJ2lvdGwnIHBhcmFtZXRlciBp ZGVudGlmaWVzIHRoZSB0eXBlIG9mIHRyYWZmaWMNCiAgICAgIGxlZy4iDQoNClJlZ2FyZHMsDQoN CkNocmlzdGVyDQo= From nobody Mon Dec 15 05:36:57 2014 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 5640A1A6F03 for ; Mon, 15 Dec 2014 05:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B41dAyI0rrcj for ; Mon, 15 Dec 2014 05:36:54 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A7B1A6EFE for ; Mon, 15 Dec 2014 05:36:45 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-51-548ee3ea04a5 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 63.A4.24955.AE3EE845; Mon, 15 Dec 2014 14:36:42 +0100 (CET) Received: from ESESSMB208.ericsson.se ([169.254.8.173]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 14:36:42 +0100 From: Christer Holmberg To: Richard Barnes , DISPATCH , "draft-holmberg-dispatch-iotl@tools.ietf.org" Thread-Topic: AD review of draft-holmberg-dispatch-iotl - Richard's comment on security considerations Thread-Index: AdAYbADhrFLy81JnQR60T2aNZk6gqA== Date: Mon, 15 Dec 2014 13:36:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5C9BA0@ESESSMB208.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvje6rx30hBqcOm1osnbSA1WL/zhms FlP7bB2YPZYs+cnkMXnjLBaPL5c/swUwR3HZpKTmZJalFunbJXBlzOiZw1pwib3i8Nn5jA2M O9i7GDk5JARMJLrePGCCsMUkLtxbz9bFyMUhJHCEUeLu1l5WCGcJo0TL/atAHRwcbAIWEt3/ tEHiIgLzGCWe/9rJCNItLJAucax/C5gtIpAhsXfmaXYIW09i4qXVLCA2i4CqxMLf+1hBbF4B X4ljm1vAahiBNn8/tQbsCmYBcYlbT+ZDXSQgsWTPeWYIW1Ti5eN/rBC2ksSPDZdYQO5hFtCU WL9LH6JVUWJK90N2iPGCEidnPmGZwCg8C8nUWQgds5B0zELSsYCRZRWjaHFqcVJuupGxXmpR ZnJxcX6eXl5qySZGYBwc3PJbdQfj5TeOhxgFOBiVeHgLxfpChFgTy4orcw8xSnOwKInzLjw3 L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY/bPqYYznxgs4v2Wcyaa07bok2rYkVXm8Q4+ t5T/7Lo7/2TtYwX5z4c5Lm6866TH3S8hsCEvM+LoOWv+Rzr6zmGsupu2aK7OLlW74ym0Z2Xv 3T+774ct1mI5eGK5aRtXsWB0zbF0G/lCx5drRVluq7k2vTpmmhYk9s95lsCfaUcDEtw2c/UX KrEUZyQaajEXFScCALEfqvpkAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/-YY3SwB3QhxLeHul7r0GZmfOhaw Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl - Richard's comment on security considerations 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, 15 Dec 2014 13:36:56 -0000 SGksDQoNCj4gVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGlzIGJhc2ljYWxseSBzYXlpbmcs ICJCZSBjYXJlZnVsIG1ha2luZyBkZWNpc2lvbnMgYmFzZWQgb24gdGhpcyBwYXJhbWV0ZXIsIGJl Y2F1c2UgDQo+IGFueW9uZSBjb3VsZCBjaGFuZ2UgaXQiLsKgIFRoZSBSRkMgMjExOSBsYW5ndWFn ZSBpcyBoZWxwZnVsLCBiZWNhdXNlIGl0IHJlZmVycyB0byB1bmRlZmluZWQgY29uY2VwdHMuwqAg SXQgd291bGQgYmUgDQo+IGJldHRlciB0byByZWZlciB0byBkb2N1bWVudHMgdGhhdCBoYXZlIGEg ZGVmaW5lZCBjb25jZXB0IG9mIHRydXN0IGJvdW5kYXJpZXMsIGUuZy4sIFJGQyAzMzI1IGZvciB0 aGUgbm90aW9uIG9mIFNwZWMoVCkuDQoNCkkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nOg0KDQoiNy4g IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZSBpbmZvcm1hdGlvbiBTSE9VTEQgb25s eSBiZSB1c2VkIGZvciBtYWtpbmcgcG9saWN5IGRlY2lzaW9ucyBiYXNlZA0KICAgb24gdGhlIHJv bGUgYnkgbm9kZXMgd2l0aGluIHRoZSBzYW1lIHRydXN0IGRvbWFpbiBbUkZDMzMyNV0uICBJbg0K ICAgYWRkaXRpb24sIHRoZXJlIE1VU1QgZXhpc3QgYW4gYWdyZWVtZW50IGJldHdlZW4gdGhlIG9w ZXJhdG9ycyBmb3INCiAgIHVzYWdlIG9mIHRoZSByb2FtaW5nIHJvbGUgaW5mb3JtYXRpb24uIg0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg== From nobody Mon Dec 15 07:03:16 2014 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 B367C1A6FDE for ; Mon, 15 Dec 2014 07:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c64euQwNz_iB for ; Mon, 15 Dec 2014 07:03:13 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FBE1A6FE6 for ; Mon, 15 Dec 2014 07:03:12 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-01v.sys.comcast.net with comcast id Tr2u1p0012GyhjZ01r3Btf; Mon, 15 Dec 2014 15:03:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-09v.sys.comcast.net with comcast id Tr3B1p0043Ge9ey01r3BbW; Mon, 15 Dec 2014 15:03:11 +0000 Message-ID: <548EF82E.3090503@alum.mit.edu> Date: Mon, 15 Dec 2014 10:03:10 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "DRAGE, Keith (Keith)" , "dispatch@ietf.org" References: <548A256F.1010801@alum.mit.edu> (pkyzivat@alum.mit.edu) <874mt154lh.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> <548B590F.2090709@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B294A17@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D5B4C9F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5B4C9F@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418655791; bh=RnLHk3YDR6bT0H8DWI7aalOta5Z+kel2BPfXPpQinf0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Xlz/IC82SiFF0BRJ4+HCxl794WUlcrnDwuCsV5hs8OvxKFNm7hr7JPFJQmSY3Qbg2 NZWZTJZxNOsHvOaFlCk86+N1JwVkjGAcohbmTwQwY6TJLvjZinqCCD0zTyK2K+s2Hh lvgrfJtRdOWNsooH+SxVOizcp8QMxYTH4A7JlHM1efpOK/cKtiNgh+RxTjqCJwHNOG yJmQf8mfLSOKCo3c+ZhTNv9eMftvB+swkg8yVfzjJ77YdncO7EuhYO40AFVmr57BYM /PFXkj/lzmgGyJ7ur8yce+9kdWJsH+Bsf3BnCY0f+8n2SCmVjgt641U+Wdt/wEn/+B 2ViAi0vqR84Jg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/pDh2WHeUYONoyuinhJcan7rKO0I Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 15 Dec 2014 15:03:14 -0000 On 12/14/14 3:29 PM, Christer Holmberg wrote: > Hi, > > I suggest to keep the text as it is. I am sure the wise men and women of the IESG will guide me in the right direction, to get it right. Note that the text, as-is, *revises* the abnf definition of uri-parameter, specifying that it can take on one of a set of values, including your new one and some old ones. But if you examine the existing registry you will find that there are several additional values currently defined that are *not* included in your new abnf. The result is that your text adds confusion. At least using =/ doesn't suffer *that* problem. Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > Sent: 14 December 2014 19:32 > To: Paul Kyzivat; dispatch@ietf.org > Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl > > The IANA considerations section extends nothing - it is merely a set of instructions to IANA on how to update the registration tables. > > Therefore what you propose is not a practical solution to the documentation. > > Regards > > Keith > >> -----Original Message----- >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul >> Kyzivat >> Sent: 12 December 2014 21:07 >> To: dispatch@ietf.org >> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl >> >> On 12/12/14 11:57 AM, Christer Holmberg wrote: >>> Hi, >>> >>>>> There has been some discussion about whether such a change (using >>>>> =/) constitutes a revision to the base draft. (IMO it does, some >>>>> people don't think so.) If you actually do the change as you did >>>>> then I think there is no question - it clearly is a revision! >>>> >>>> It could be argued both ways, I think. Strictly speaking, >> the change >>>> doesn't extend the set of strings that are generated by >>>> , so I could argue that the draft only >> extends the base RFC by providing additional interpretation to strings >> that > are already valid. >>> >>> My fingers are ready, waiting on the keyboard. Just tell me what to >>> type :) >> >> My preference is that you not provide any ABNF extending the values >> for uri-parameter. The IANA considerations section are sufficient. >> >> Obviously we have a difference of opinion here. >> >> Thanks, >> Paul >> >> _______________________________________________ >> 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 Dec 15 07:04:33 2014 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 471471A3BA7 for ; Mon, 15 Dec 2014 07:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqOYUYFUS22v for ; Mon, 15 Dec 2014 07:04:31 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BCA41A1B5A for ; Mon, 15 Dec 2014 07:04:31 -0800 (PST) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-03v.sys.comcast.net with comcast id Tr4B1p0082D5gil01r4WnK; Mon, 15 Dec 2014 15:04:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-06v.sys.comcast.net with comcast id Tr4V1p00S3Ge9ey01r4V6y; Mon, 15 Dec 2014 15:04:30 +0000 Message-ID: <548EF87D.8080409@alum.mit.edu> Date: Mon, 15 Dec 2014 10:04:29 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , "dispatch@ietf.org" References: <548A256F.1010801@alum.mit.edu> (pkyzivat@alum.mit.edu) <874mt154lh.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> <548B590F.2090709@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B294A17@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B294A17@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418655870; bh=piFF7VZPD3k/AoUFigq0WSbyQcogKms6CZviYbN453I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TZfPe1njNnvuCz5ZCwlwgUfEHufT9p1o8VbjtTfeSXc9Ss64QlcX5bIKZX6Ti9hhd nkSjIuFo/DfliRymeVQfcDkfBzH12EDSE9DDkF+7BZUfnPji+RBO6nUfe56fuV4HLA 3SiCjpIOnT8ZgQ98XGRU8LyXsA/F21YBTf2BtXEPhQK+yCOcQP554FGldbjbvxBGH8 Uwmdo+boqUmFLjzKsooTjDGN2lYsjphVKY8lA7OafgMG4KvHJRRUZvVtwhlrW80ZPD 9IUfmaYbtDeu4skL13MLWwTJJdm6aeVWA058jR/Jv7eYASzdNylQRpOx/wQguLgHk0 Q2dJPcCXtvG2A== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/16eYSxvUWhA53dm0MMDg1DsaM-Y Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 15 Dec 2014 15:04:32 -0000 On 12/14/14 12:31 PM, DRAGE, Keith (Keith) wrote: > The IANA considerations section extends nothing - it is merely a set of instructions to IANA on how to update the registration tables. Exactly. That is the point. > Therefore what you propose is not a practical solution to the documentation. Why? Thanks, Paul > Regards > > Keith > >> -----Original Message----- >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 12 December 2014 21:07 >> To: dispatch@ietf.org >> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl >> >> On 12/12/14 11:57 AM, Christer Holmberg wrote: >>> Hi, >>> >>>>> There has been some discussion about whether such a change (using >>>>> =/) constitutes a revision to the base draft. (IMO it does, some >>>>> people don't think so.) If you actually do the change as you did >>>>> then I think there is no question - it clearly is a revision! >>>> >>>> It could be argued both ways, I think. Strictly speaking, >> the change >>>> doesn't extend the set of strings that are generated by >>>> , so I could argue that the draft only >> extends the base RFC by providing additional interpretation >> to strings that > are already valid. >>> >>> My fingers are ready, waiting on the keyboard. Just tell me what to >>> type :) >> >> My preference is that you not provide any ABNF extending the >> values for uri-parameter. The IANA considerations section are >> sufficient. >> >> Obviously we have a difference of opinion here. >> >> Thanks, >> Paul >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From nobody Mon Dec 15 07:08:36 2014 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 11D471A3BA7 for ; Mon, 15 Dec 2014 07:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UI7oHhMHFOTx for ; Mon, 15 Dec 2014 07:08:33 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94681A1B5A for ; Mon, 15 Dec 2014 07:08:32 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-99-548ef96e18b5 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B2.CB.24955.E69FE845; Mon, 15 Dec 2014 16:08:31 +0100 (CET) Received: from ESESSMB208.ericsson.se ([169.254.8.173]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 16:08:30 +0100 From: Christer Holmberg To: Paul Kyzivat , "DRAGE, Keith (Keith)" , "dispatch@ietf.org" Thread-Topic: [dispatch] AD review of draft-holmberg-dispatch-iotl - ABNF Thread-Index: AdAYeLIHDNMayZ6HTFCjThzs3HXmjg== Date: Mon, 15 Dec 2014 15:08:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5D10C6@ESESSMB208.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+JvjW7+z74Qg64eFoulkxawWjxtPMto sWLDAVYHZo/WZ3tZPf6+/8DksWTJT6YA5igum5TUnMyy1CJ9uwSujAOrZjAWdItVNJx0b2B8 K9jFyMkhIWAisXxFMzuELSZx4d56ti5GLg4hgSOMEisWLGOEcJYwSszqvsfUxcjBwSZgIdH9 TxskLiLQwyjxY+tOFpBuYQEPifZ3+8BsEQFPiZUXZoHViwjoSZzu9QAJswioSjw4NYMZxOYV 8JXYMqEBzGYEWvz91BomEJtZQFzi1pP5TBAHCUgs2XOeGcIWlXj5+B8rhK0k8WPDJRaIeh2J Bbs/sUHY2hLLFr6Gmi8ocXLmE5YJjMKzkIydhaRlFpKWWUhaFjCyrGIULU4tTspNNzLWSy3K TC4uzs/Ty0st2cQIjISDW36r7mC8/MbxEKMAB6MSD2+hWF+IEGtiWXFl7iFGaQ4WJXHehefm BQsJpCeWpGanphakFsUXleakFh9iZOLglGpgzNeoWzmXwzGg+Fpt3YHUtvpnhXNrlp/uOn9N 46V9/ucmjtPWt9uElj0JeNmmHVSiUKF0g+NRgrfm+gdFTyMq/335oHDmx9EDH7z1f1+vdPIU UX9m8dq6VEyEaUoEj7xExuJvRwwy4zPet7K9u5JUVeIRcVF8S1z8tYLXB0vUpV9/adGIrLJQ YinOSDTUYi4qTgQAydb91WUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/YearWxWkJn8A4sHzsQQFBBIkCpQ Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl - ABNF 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, 15 Dec 2014 15:08:35 -0000 Hi, >> I suggest to keep the text as it is. I am sure the wise men and women of= the IESG will guide me in the right direction, to get it right. > > Note that the text, as-is, *revises* the abnf definition of uri-parameter= , specifying that it can take on one of a set of values, including=20 > your new one and some old ones. But if you examine the existing registry = you will find that there are several additional values currently=20 > defined that are *not* included in your new abnf. The result is that your= text adds confusion. I think any other values are covered by "other-param", aren't they? Anyway, I have no problem using =3D/. So: "uri-parameter =3D/ iotl-param" Regards, Christer > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE,=20 > Keith (Keith) > Sent: 14 December 2014 19:32 > To: Paul Kyzivat; dispatch@ietf.org > Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl > > The IANA considerations section extends nothing - it is merely a set of i= nstructions to IANA on how to update the registration tables. > > Therefore what you propose is not a practical solution to the documentati= on. > > Regards > > Keith > >> -----Original Message----- >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul=20 >> Kyzivat >> Sent: 12 December 2014 21:07 >> To: dispatch@ietf.org >> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl >> >> On 12/12/14 11:57 AM, Christer Holmberg wrote: >>> Hi, >>> >>>>> There has been some discussion about whether such a change (using >>>>> =3D/) constitutes a revision to the base draft. (IMO it does, some=20 >>>>> people don't think so.) If you actually do the change as you did=20 >>>>> then I think there is no question - it clearly is a revision! >>>> >>>> It could be argued both ways, I think. Strictly speaking, >> the change >>>> doesn't extend the set of strings that are generated by=20 >>>> , so I could argue that the draft only >> extends the base RFC by providing additional interpretation to=20 >> strings that > are already valid. >>> >>> My fingers are ready, waiting on the keyboard. Just tell me what to=20 >>> type :) >> >> My preference is that you not provide any ABNF extending the values=20 >> for uri-parameter. The IANA considerations section are sufficient. >> >> Obviously we have a difference of opinion here. >> >> Thanks, >> Paul >> >> _______________________________________________ >> 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 Dec 15 07:11:30 2014 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 03C0E1A1EFD for ; Mon, 15 Dec 2014 07:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwvr-_66BzU2 for ; Mon, 15 Dec 2014 07:11:23 -0800 (PST) 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 E75651A3BA7 for ; Mon, 15 Dec 2014 07:11:22 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-a3-548efa189a98 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D5.B1.04076.81AFE845; Mon, 15 Dec 2014 16:11:21 +0100 (CET) Received: from ESESSMB208.ericsson.se ([169.254.8.173]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 16:11:20 +0100 From: Christer Holmberg To: "marianne.mohali@orange.com" , "dispatch@ietf.org" Thread-Topic: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 Thread-Index: AdAP2C5BeDuYjLy8Qce0wuL96+hw6gIoRB6Q Date: Mon, 15 Dec 2014 15:11:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5D110A@ESESSMB208.ericsson.se> References: <15139_1417707803_5480811A_15139_368_1_8B970F90C584EA4E97D5BAAC9172DBB8142C6B0F@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <15139_1417707803_5480811A_15139_368_1_8B970F90C584EA4E97D5BAAC9172DBB8142C6B0F@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D5D110AESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvja7kr74QgwMb2S2WTlrAarGteR+T A5PHkiU/mTxanp1kC2CK4rJJSc3JLEst0rdL4MqYe46zYHpmRduCo8wNjMejuhg5OSQETCT+ 7LjEAmGLSVy4t56ti5GLQ0jgCKNE6/cXjBDOEkaJbVOuMXUxcnCwCVhIdP/TBmkQEciQ2L5i NStIWFggQOLq3kKIcKDElb/NTBC2kcT/cx9ZQWwWAVWJbbs/g9m8Ar4Sl55PhxrfxihxaOFU FhCHU6CdUeLgxpeMIFWMQBd9P7UGbBKzgLjErSfzmSAuFZBYsuc8M4QtKvHy8T9WCFtJ4scG iG+YBfIl+le8ZYfYJihxcuYTlgmMIrOQjJqFpGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxm QhZfwMi+ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwrg5u+W21g/Hgc8dDjAIcjEo8vAVi fSFCrIllxZW5hxilOViUxHkXnpsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGR1fSqgs2i h24HZ758ylXJW+l73bDXc8bWBe9l1mR3acopGRQV/D9aca29JurH69mtV5/VX6x61/kprSYt 5uP5Rd+elVxSPPHKRqjN5U3mVEWu2+IKCnucuHg4GR4m//n6Wbrc3EWx+PaL123TaqLyZRh3 2bMLy/oLXDe+qOe94dBsznTz6DwlluKMREMt5qLiRABEUO+PjAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/kjSWsr5f_LXnIE8mzemafphlJzM Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 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, 15 Dec 2014 15:11:29 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D5D110AESESSMB208erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have identified some editorial nits, which I can provide later, but in ge= neral I support this draft moving forward, and I will follow the work and p= rovide comments. Regards, Christer From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of marianne.moh= ali@orange.com Sent: 4. joulukuuta 2014 17:43 To: dispatch@ietf.org Subject: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 Hi, I re-send my fist email with the correct draft title as subject. I already plan to improve the text of the draft by defining a clear definit= ion with a new wording to describe the scope of usage of the new cause URI = parameter value. This new vocabulary could be something like "service access number translat= ion" with a definition that will be somewhere between a retargeting while t= he target user remain the same and a redirection to a new target. Indeed, f= or premium/toll-free services users are trying to contact a service which i= s the target service and not a particular user behind a UA as a "target use= r" as defined in RFC7044. The service access number could be seen as a supe= r-alias pointing out to a set of UAs and a UAs could be pointed out by seve= ral service access numbers. Comments and review are still welcome. BR, Marianne ------ This draft defines a new value for the SIP URI parameter "cause", which can= be used to associate a SIP URI to a service access number that has been tr= anslated by a specific application. Abstract: RFC4458 defines a "cause" URI parameter as having predefined values for Red= irecting reasons as a mapping from ITU-T Q.732.2-5 Redirecting Reasons. Th= e "cause" URI parameter is to be used in SIP or SIPs URI. In particular, it= may appear in the History-Info header defined in RFC7044 that must be adde= d in retargeted requests. This specification creates a new predefined value= for cases when the retargeting is caused by a specific service action lead= ing to a called number translation. This document updates RFC4458. This draft is needed for 3GPP, but we've tried to write it in a way so that= it can also be applied to other environments. A first version of the draft can be seen under: http://www.ietf.org/internet-drafts/draft-mohali-dispatch-cause-for-service= -number-00.txt This version is a very first version and for sure needs improvement. Your comments are welcome. Regards, Marianne Mohali ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_7594FB04B1934943A5C02806D1A2204B1D5D110AESESSMB208erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I have identified some= editorial nits, which I can provide later, but in general I support this d= raft moving forward, and I will follow the work and provide comments.<= /o:p>

 

Regards,

 

Christer

 

From: dispatch= [mailto:dispatch-bounces@ietf.org] On Behalf Of marianne.mohali@orange.com
Sent: 4. joulukuuta 2014 17:43
To: dispatch@ietf.org
Subject: [dispatch] New draft-mohali-dispatch-cause-for-service-numb= er-00

 

Hi,

 

I re-send my fist email with the correct draft ti= tle as subject.

 

I already plan to improve the text of the draft b= y defining a clear definition with a new wording to describe the scope of u= sage of the new cause URI parameter value.

This new vocabulary could be something like "= ;service access number translation" with a definition that will be som= ewhere between a retargeting while the target user remain the same and a re= direction to a new target. Indeed, for premium/toll-free services users are trying to contact a service which is the target service= and not a particular user behind a UA as a "target user" as defi= ned in RFC7044. The service access number could be seen as a super-alias po= inting out to a set of UAs and a UAs could be pointed out by several service access numbers.

 

Comments and review are still welcome.=

 

BR,

Marianne

------

This draft defines a new value for the SIP URI pa= rameter "cause", which can be used to associate a SIP URI to a se= rvice access number that has been translated by a specific application.

 

Abstract:

RFC4458 defines a "cause" URI parameter= as having predefined values for Redirecting reasons as a mapping from ITU-= T Q.732.2-5 Redirecting Reasons.  The "cause" URI parameter = is to be used in SIP or SIPs URI. In particular, it may appear in the History-Info header defined in RFC7044 that must be added in retarg= eted requests. This specification creates a new predefined value for cases = when the retargeting is caused by a specific service action leading to a ca= lled number translation. This document updates RFC4458.

 

This draft is needed for 3GPP, but we’ve tr= ied to write it in a way so that it can also be applied to other environmen= ts.

 

A first version of the draft can be seen under: <= o:p>

http://www.ietf.org/internet-drafts/draft-mohali-dispatch-= cause-for-service-number-00.txt

 

This version is a very first version and for sure= needs improvement.

Your comments are welcome.

 

Regards,

Marianne Mohali

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_7594FB04B1934943A5C02806D1A2204B1D5D110AESESSMB208erics_-- From nobody Mon Dec 15 07:25:02 2014 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 C59121A6FCF for ; Mon, 15 Dec 2014 07:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eejGRERG7PsT for ; Mon, 15 Dec 2014 07:24:59 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [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 9069C1A6FBB for ; Mon, 15 Dec 2014 07:24:59 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-12v.sys.comcast.net with comcast id TrQP1p0082Qkjl901rQyB4; Mon, 15 Dec 2014 15:24:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-15v.sys.comcast.net with comcast id TrQx1p00A3Ge9ey01rQxFX; Mon, 15 Dec 2014 15:24:58 +0000 Message-ID: <548EFD49.5030103@alum.mit.edu> Date: Mon, 15 Dec 2014 10:24:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "DRAGE, Keith (Keith)" , "dispatch@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D5D10C6@ESESSMB208.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5D10C6@ESESSMB208.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418657098; bh=B8IdOR58apdlyW1WxZN4+wQVKhyNU20c2GO5mJY0Cos=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hBC4TS8YK1jt6xCmi/wjuNjeBfiUoBLALuhP/ewZDFsza+eL8Bkxhb1JDM3ngkQD3 q4X4tT8RVgd2ll8R3sjpKWfYUoBLZb0dilQTS69GvqFeHeRKo67FeuEtdjIrAYBSSN vuprAdzBqxcBb0Lpd008K03F3X8zPw7SzyRQ+YO6LePngI+xWC/nYOplbkiauSdJN1 KiSxpgiD0LsifXBqUW3ZIBPRsuwQxHWqx3tvf2qmwEM4fBfIbYnJd7kJTBpzw6VrDQ nKfOsUO+ACjIzxjp1QfFHukjJfKUwvixOjagfCPI22zlJVM7wNClHlirTF6cHJ0AFJ Dlq6JGMrmhCug== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/zPEEnjl247VyHlwmo-GtSYb8txg Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl - ABNF 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, 15 Dec 2014 15:25:01 -0000 On 12/15/14 10:08 AM, Christer Holmberg wrote: > Hi, > >>> I suggest to keep the text as it is. I am sure the wise men and women of the IESG will guide me in the right direction, to get it right. >> >> Note that the text, as-is, *revises* the abnf definition of uri-parameter, specifying that it can take on one of a set of values, including >> your new one and some old ones. But if you examine the existing registry you will find that there are several additional values currently >> defined that are *not* included in your new abnf. The result is that your text adds confusion. > > I think any other values are covered by "other-param", aren't they? And your new value is already covered by other-param too. So there really is no reason to revise the ABNF. In fact, since there is a registry, there is no reason for the abnf to mention any alternative other than other-param. When implementing an application that processes sip URIs, you cannot count on the abnf definition of uri-parameter from any single source as definitive for what parameters you need to handle. You will likely be supporting multiple RFCs that define URI parameters, and no single one is likely to have an exhaustive list. > Anyway, I have no problem using =/. So: > > "uri-parameter =/ iotl-param" I've already stated my preference. But I find this acceptable. Thanks, Paul From nobody Mon Dec 15 09:05:06 2014 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 8FD291A86EB for ; Mon, 15 Dec 2014 09:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQizWbT7dGFB for ; Mon, 15 Dec 2014 09:04:51 -0800 (PST) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C8E1A8701 for ; Mon, 15 Dec 2014 09:04:51 -0800 (PST) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-10v.sys.comcast.net with comcast id Tt3t1p0075Geu2801t4rlG; Mon, 15 Dec 2014 17:04:51 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-po-20v.sys.comcast.net with comcast id Tt4q1p0011KKtkw01t4qoY; Mon, 15 Dec 2014 17:04:50 +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 sBFH4nap019326 for ; Mon, 15 Dec 2014 12:04:49 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sBFH4ntL019325; Mon, 15 Dec 2014 12:04:49 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-Reply-To: <548EF82E.3090503@alum.mit.edu> (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 15 Dec 2014 12:04:49 -0500 Message-ID: <87k31ssv2m.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/cn769ADEgQ3JNp7dldR-cg8bHrA Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 15 Dec 2014 17:04:58 -0000 Paul Kyzivat writes: > Note that the text, as-is, *revises* the abnf definition of > uri-parameter, specifying that it can take on one of a set of values, > including your new one and some old ones. But if you examine the > existing registry you will find that there are several additional values > currently defined that are *not* included in your new abnf. The result > is that your text adds confusion. > > At least using =/ doesn't suffer *that* problem. There has been a custom in SIP to write productions like: thing = thing-subtype-A / thing-subtype-B / thing-subtype-C / generic-thing where all of the strings generated by are also strings generated by . This is pointless from the point of a formal grammar, but is informative for a human reader that wants to know the import of strings generated by . In regard to , there are 12 RFCs mentioned in its registry (https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-11), but only two (3261 and 5627) give productions for : uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / other-param uri-parameter =/ gr-param Dale From nobody Mon Dec 15 14:12:55 2014 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 5FC021A0141 for ; Mon, 15 Dec 2014 14:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9eggH9Th-nk for ; Mon, 15 Dec 2014 14:12:52 -0800 (PST) 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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EAB51A019B for ; Mon, 15 Dec 2014 14:12:52 -0800 (PST) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-08v.sys.comcast.net with comcast id TyCS1p0094yXVJQ01yCrJl; Mon, 15 Dec 2014 22:12:51 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-po-06v.sys.comcast.net with comcast id TyCq1p00b1KKtkw01yCrNl; Mon, 15 Dec 2014 22:12:51 +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 sBFMCnoH029701; Mon, 15 Dec 2014 17:12:49 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sBFMCntZ029698; Mon, 15 Dec 2014 17:12:49 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: In-Reply-To: <15139_1417707803_5480811A_15139_368_1_8B970F90C584EA4E97D5BAAC9172DBB8142C6B0F@PEXCVZYM12.corporate.adroot.infra.ftgroup> (marianne.mohali@orange.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 15 Dec 2014 17:12:47 -0500 Message-ID: <87fvcgr28w.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418681571; bh=U+kBeagR6PPUmJUTjX2uIwcYytsPn0lxELSHOG9UtNY=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=WT0i0ABRxWSKiObHDo7YptA8VQ8JIy9JjCfm7YbInsTbqOsNalDOxEHgCARhdzF3v yjaV+xWMYkfWFWX3Ru265PmYtH9DUW7IepO5oybrLprSR9EE4gpQ/zAWtOGN2QE3xy sZdU4rUsNgZUFFRRRF9qpqYj00ObiB4oDcKhIa48fGXulmYmlsHbjEShfARIbZ3X1X W+9iOJwHOhzr/jfEXilmkJ4omSQPFV8jwey96hnWaAWRLg+vhMWS8xq74SexDrmIJC oUiWUA9AgQJikkHeuMnjjNx+wd9fwSDadArqwz7747t0TKIlpdBsFauofi7BPIhHRM u0HHwRlQwjNSA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/FeNA4pFg9Xng2HVwBZ4aJskLBfM Cc: dispatch@ietf.org Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 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, 15 Dec 2014 22:12:53 -0000 This draft seems valuable to me and I think it should progress. One nit is the use of "IN". I believe it means "Intelligent Network" in the Q.1200 sense, but that acronym isn't commonly used in the SIP world, so it would help if it was explained more fully when it is first used. Dale From nobody Tue Dec 16 01:21:34 2014 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 F18D31ACD70 for ; Tue, 16 Dec 2014 01:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07F47-3PW-lg for ; Tue, 16 Dec 2014 01:21:09 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE0D1ACD42 for ; Tue, 16 Dec 2014 01:20:59 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-5e-548ff979fd72 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 25.46.04231.979FF845; Tue, 16 Dec 2014 10:20:57 +0100 (CET) Received: from ESESSMB208.ericsson.se ([169.254.8.173]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 10:20:56 +0100 From: Christer Holmberg To: "dispatch@ietf.org" Thread-Topic: New Version Notification for draft-holmberg-dispatch-iotl-03.txt Thread-Index: AQHQGRCwXlYfJSYSjkGjfBvBEm+GtpyR7+nw Date: Tue, 16 Dec 2014 09:20:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5DAC4D@ESESSMB208.ericsson.se> References: <20141216091407.29475.46050.idtracker@ietfa.amsl.com> In-Reply-To: <20141216091407.29475.46050.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+JvjW7lz/4Qg74eeYulkxawWkzts3Vg 8liy5CeTx+SNs1gCmKK4bFJSczLLUov07RK4MhpniRf8k69YvfQzewPjFPkuRk4OCQETiedv 17FB2GISF+6tB7K5OIQEjjBKHLz4jRHCWcIosXJvG2sXIwcHm4CFRPc/bZAGEQFtiaOruphB bGYBPYkVT06B2cICvhI/zh1lhqgJkPg0ewUThG0k8fTSPzCbRUBV4vSWzewgNi9Q/a6GyWBx IQFHiRONz9hAVnEKOEn8viICEmYEuu37qTVMEKvEJW49mc8EcbOAxJI955khbFGJl4//sULY ihLtTxsYQcYwC2hKrN+lD9GqKDGl+yHUVkGJkzOfsExgFJuFZOoshI5ZSDpmIelYwMiyilG0 OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwag5u+a27g3H1a8dDjAIcjEo8vAYL+kOEWBPLiitz DzFKc7AoifMuOjcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPj3NzdVlzSj7UX3D3k8859 4aQ7plq5NkeCjgZ5fPr+6frtNa3eSzs53z3+8+Dh2mMH9ZZdXhd9uVM7w8S1Z79Ma8nEH2ev t/Y9vrD9a+680/sULmxcs/TONn7P2Mfza4XOd2rVCAgeW6BdfintrtXLkKNaS929V6lITRa4 fG+WFNfmosmO90W28iixFGckGmoxFxUnAgBVO79+ewIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/DlpEMpiu3a0_cCBhAYN-fqmFDC4 Subject: [dispatch] FW: New Version Notification for draft-holmberg-dispatch-iotl-03.txt 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, 16 Dec 2014 09:21:23 -0000 SGksDQoNCkkgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiAoLTAzKSBvZiB0aGUgaW90bCBk cmFmdCwgYmFzZWQgb24gdGhlIGNvbW1lbnRzIGZyb20gUmljaGFyZC4NCg0KQSBjb3VwbGUgb2Yg bWlub3IgY2hhbmdlcyBmcm9tIHRoZSBlLW1haWwgc3VnZ2VzdGlvbnM6DQoNCi0gRm9yIHRoZSAi aG9tZSIgYW5kICJ2aXNpdGVkIiByZWZlcmVuY2VzLCBJIGluY2x1ZGVkIGEgcmVmZXJlbmNlIHRv IFRTIDI0LjIyOSAoaW5zdGVhZCBvZiBUUiAyMS45MDUpLg0KLSBJIGFkZGVkIFJGQyAzMzI1IGFz IGFuIEluZm9ybWF0aXZlIHJlZmVyZW5jZSAoaW5zdGVhZCBvZiBhIE5vcm1hdGl2ZSkuIFRoZSBS RkMgaXMgSW5mb3JtYXRpb25hbCwgYW5kIHRoZSBpZG5pdHMgdG9vbCByZXR1cm5zIGFuIGVycm9y IGlmIHN1Y2ggaXMgcHV0IGFzIGEgTm9ybWF0aXZlIHJlZmVyZW5jZS4NCg0KUmVnYXJkaW5nIHRo ZSBBQk5GLCBJIGFtIG5vdCB1c2luZyB0aGUgInVyaS1wYXJhbWV0ZXIgPS8gIGlvdGwtcGFyYW0i IGZvcm1hdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IDE2LiBqb3VsdWt1dXRhIDIwMTQgMTE6MTQNClRvOiBK YW4gSG9sbTsgTWFydGluIERvbGx5OyBDaHJpc3RlciBIb2xtYmVyZzsgQ2hyaXN0ZXIgSG9sbWJl cmc7IFJvbGFuZCBKZXNza2U7IFJvbGFuZCBKZXNza2U7IEphbiBIb2xtOyBNYXJ0aW4gRG9sbHkN ClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaG9sbWJlcmctZGlz cGF0Y2gtaW90bC0wMy50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaG9sbWJl cmctZGlzcGF0Y2gtaW90bC0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgQ2hyaXN0ZXIgSG9sbWJlcmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0K DQpOYW1lOgkJZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtaW90bA0KUmV2aXNpb246CTAzDQpUaXRs ZToJCTNyZC1HZW5lcmF0aW9uIFBhcnRuZXJzaGlwIFByb2plY3QgKDNHUFApIFNJUCBVUkkgSW50 ZXIgT3BlcmF0b3IgVHJhZmZpYyBMZWcgcGFyYW1ldGVyDQpEb2N1bWVudCBkYXRlOgkyMDE0LTEy LTE2DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxNg0KVVJMOiAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhvbG1iZXJn LWRpc3BhdGNoLWlvdGwtMDMudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtaW90bC8NCkh0bWxpemVkOiAg ICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1p b3RsLTAzDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtaW90bC0wMw0KDQpBYnN0cmFjdDoNCiAgIEluIDNyZC1H ZW5lcmF0aW9uIFBhcnRuZXJzaGlwIFByb2plY3QgKDNHUFApIG5ldHdvcmtzLCB0aGUgc2lnbmFs bGluZw0KICAgcGF0aCBiZXR3ZWVuIGEgY2FsbGluZyB1c2VyIGFuZCBhIGNhbGxlZCB1c2VyIGNh biBiZSBwYXJ0aW9uZWQgaW50bw0KICAgc2VnbWVudHMsIHJlZmVycmVkIHRvIGFzIHRyYWZmaWMg bGVncy4gIEVhY2ggdHJhZmZpYyBsZWcgbWF5IHNwYW4NCiAgIG5ldHdvcmtzIGJlbG9uZ2luZyB0 byBkaWZmZXJlbnQgb3BlcmF0b3JzLCBhbmQgd2lsbCBoYXZlIGl0cyBvd24NCiAgIGNoYXJhY3Rl cmlzdGljcyB0aGF0IGNhbiBiZSBkaWZmZXJlbnQgZnJvbSBvdGhlciB0cmFmZmljIGxlZ3MgaW4g dGhlDQogICBzYW1lIGNhbGwuICBUaGUgZGlyZWN0aW9uYWxpdHkgaW4gdHJhZmZpYyBsZWdzIHJl bGF0ZXMgdG8gYSBTSVANCiAgIHJlcXVlc3QgY3JlYXRpbmcgYSBkaWFsb2d1ZSBhbmQgc3RhbmQt YWxvbmUgU0lQIHJlcXVlc3QuICBBIHRyYWZmaWMNCiAgIGxlZyBtaWdodCBiZSBhc3NvY2lhdGVk IHdpdGggbXVsdGlwbGUgU0lQIGRpYWxvZ3MsIGUuZy4gaW4gY2FzZSBhDQogICBCMkJVQSB3aGlj aCBtb2RpZmllcyB0aGUgU0lQIGRpYWxvZyBpZGVudGlmaWVyIGlzIGxvY2F0ZWQgd2l0aGluIHRo ZQ0KICAgdHJhZmZpYyBsZWcuDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBTSVAg VVJJIHBhcmFtZXRlciwgJ2lvdGwnLiAgVGhlIHBhcmFtZXRlcg0KICAgY2FuIGJlIHVzZWQgaW4g YSBTSVAgVVJJIHRvIGluZGljYXRlIHRoYXQgdGhlIGVudGl0eSBhc3NvY2lhdGVkIHdpdGgNCiAg IHRoZSBhZGRyZXNzLCBvciBhbiBlbnRpdHkgcmVzcG9uc2libGUgZm9yIHRoZSBob3N0IHBhcnQg b2YgdGhlDQogICBhZGRyZXNzLCByZXByZXNlbnRzIHRoZSBlbmQgb2YgYSBzcGVjaWZpYyB0cmFm ZmljIGxlZyAob3IgbXVsdGlwbGUNCiAgIHRyYWZmaWMgbGVncykuDQoNCiAgIFRoZSBTSVAgVVJJ ICdpb3RsJyBwYXJhbWV0ZXIgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGlzIG9ubHkNCiAgIGFw cGxpY2FibGUgdG8gM0dQUCBuZXR3b3Jrcy4gIFRoZSB1c2FnZSBvZiB0aGUgcGFyYW1ldGVyIHdp dGhpbiBvdGhlcg0KICAgdHlwZXMgb2YgbmV0d29ya3MgaXMgdW5kZWZpbmVkLg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Dec 16 02:23:50 2014 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 08E411ACD5D for ; Tue, 16 Dec 2014 02:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9-n6hARI7IH for ; Tue, 16 Dec 2014 02:23:41 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416D41A1A8C for ; Tue, 16 Dec 2014 02:23:41 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBGANdNc018984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Dec 2014 10:23:39 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBGANcaJ028957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Dec 2014 11:23:39 +0100 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 16 Dec 2014 11:23:38 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.147]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 11:23:38 +0100 From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: "marianne.mohali@orange.com" , "dispatch@ietf.org" Thread-Topic: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 Thread-Index: AQHQGHl1aiPNVPikLEC0/Xb6skxTd5ySA2nw Date: Tue, 16 Dec 2014 10:23:38 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF81955274B@DEMUMBX005.nsn-intra.net> References: <15139_1417707803_5480811A_15139_368_1_8B970F90C584EA4E97D5BAAC9172DBB8142C6B0F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <7594FB04B1934943A5C02806D1A2204B1D5D110A@ESESSMB208.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5D110A@ESESSMB208.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.158] Content-Type: multipart/alternative; boundary="_000_56C2F665D49E0341B9DF5938005ACDF81955274BDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 16066 X-purgate-ID: 151667::1418725419-0000658F-69553DFD/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/raf-DAgwj9IRTYT_TJLMfRhk0lk Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 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, 16 Dec 2014 10:23:46 -0000 --_000_56C2F665D49E0341B9DF5938005ACDF81955274BDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Marianne, all, I also support to move this draft forward. Kind regards, Uwe From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Christer= Holmberg Sent: Monday, December 15, 2014 4:11 PM To: marianne.mohali@orange.com; dispatch@ietf.org Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number-= 00 Hi, I have identified some editorial nits, which I can provide later, but in ge= neral I support this draft moving forward, and I will follow the work and p= rovide comments. Regards, Christer From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of marianne.moh= ali@orange.com Sent: 4. joulukuuta 2014 17:43 To: dispatch@ietf.org Subject: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 Hi, I re-send my fist email with the correct draft title as subject. I already plan to improve the text of the draft by defining a clear definit= ion with a new wording to describe the scope of usage of the new cause URI = parameter value. This new vocabulary could be something like "service access number translat= ion" with a definition that will be somewhere between a retargeting while t= he target user remain the same and a redirection to a new target. Indeed, f= or premium/toll-free services users are trying to contact a service which i= s the target service and not a particular user behind a UA as a "target use= r" as defined in RFC7044. The service access number could be seen as a supe= r-alias pointing out to a set of UAs and a UAs could be pointed out by seve= ral service access numbers. Comments and review are still welcome. BR, Marianne ------ This draft defines a new value for the SIP URI parameter "cause", which can= be used to associate a SIP URI to a service access number that has been tr= anslated by a specific application. Abstract: RFC4458 defines a "cause" URI parameter as having predefined values for Red= irecting reasons as a mapping from ITU-T Q.732.2-5 Redirecting Reasons. Th= e "cause" URI parameter is to be used in SIP or SIPs URI. In particular, it= may appear in the History-Info header defined in RFC7044 that must be adde= d in retargeted requests. This specification creates a new predefined value= for cases when the retargeting is caused by a specific service action lead= ing to a called number translation. This document updates RFC4458. This draft is needed for 3GPP, but we've tried to write it in a way so that= it can also be applied to other environments. A first version of the draft can be seen under: http://www.ietf.org/internet-drafts/draft-mohali-dispatch-cause-for-service= -number-00.txt This version is a very first version and for sure needs improvement. Your comments are welcome. Regards, Marianne Mohali ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_56C2F665D49E0341B9DF5938005ACDF81955274BDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Marianne, all,

 

I also support to move this draft forward.

 

Kind regards,=

Uwe

 

 

From: dispatch= [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Christer Holmberg
Sent: Monday, December 15, 2014 4:11 PM
To: marianne.mohali@orange.com; dispatch@ietf.org
Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-= number-00

 

Hi,<= /p>

 

I have identified some= editorial nits, which I can provide later, but in general I support this d= raft moving forward, and I will follow the work and provide comments.<= /o:p>

 

Regards,

 

Christer

 

From: dispatch= [mailto:dispatch-bounces@ietf= .org] On Behalf Of marianne.= mohali@orange.com
Sent: 4. joulukuuta 2014 17:43
To: dispatch@ietf.org
Subject: [dispatch] New draft-mohali-dispatch-cause-for-service-numb= er-00

 

Hi,

 

I re-send my fist email with the correct draft ti= tle as subject.

 

I already plan to improve the text of the draft b= y defining a clear definition with a new wording to describe the scope of u= sage of the new cause URI parameter value.

This new vocabulary could be something like "= ;service access number translation" with a definition that will be som= ewhere between a retargeting while the target user remain the same and a re= direction to a new target. Indeed, for premium/toll-free services users are trying to contact a service which is the target service= and not a particular user behind a UA as a "target user" as defi= ned in RFC7044. The service access number could be seen as a super-alias po= inting out to a set of UAs and a UAs could be pointed out by several service access numbers.

 

Comments and review are still welcome.=

 

BR,

Marianne

------

This draft defines a new value for the SIP URI pa= rameter "cause", which can be used to associate a SIP URI to a se= rvice access number that has been translated by a specific application.

 

Abstract:

RFC4458 defines a "cause" URI parameter= as having predefined values for Redirecting reasons as a mapping from ITU-= T Q.732.2-5 Redirecting Reasons.  The "cause" URI parameter = is to be used in SIP or SIPs URI. In particular, it may appear in the History-Info header defined in RFC7044 that must be added in retarg= eted requests. This specification creates a new predefined value for cases = when the retargeting is caused by a specific service action leading to a ca= lled number translation. This document updates RFC4458.

 

This draft is needed for 3GPP, but we’ve tr= ied to write it in a way so that it can also be applied to other environmen= ts.

 

A first version of the draft can be seen under: <= o:p>

http://www.ietf.org/internet-drafts/draft-mohali-dispatch-= cause-for-service-number-00.txt

 

This version is a very first version and for sure= needs improvement.

Your comments are welcome.

 

Regards,

Marianne Mohali

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_56C2F665D49E0341B9DF5938005ACDF81955274BDEMUMBX005nsnin_-- From nobody Tue Dec 16 03:17:27 2014 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 44AF31A1AA0 for ; Tue, 16 Dec 2014 03:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Gz_fIrvYw6S for ; Tue, 16 Dec 2014 03:17:20 -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 97F6C1A01F0 for ; Tue, 16 Dec 2014 03:17:20 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 5F10FD58C075C; Tue, 16 Dec 2014 11:17:15 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sBGBHH3c015259 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Dec 2014 12:17:17 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 12:17:17 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] AD review of draft-holmberg-dispatch-iotl Thread-Index: AQHQGHhsWDyZe1mldUGUh5XqNnd/XZySEiSg Date: Tue, 16 Dec 2014 11:17:16 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B295BC0@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <548A256F.1010801@alum.mit.edu> (pkyzivat@alum.mit.edu) <874mt154lh.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> <548B590F.2090709@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B294A17@FR712WXCHMBA11.zeu.alcatel-lucent.com> <548EF87D.8080409@alum.mit.edu> In-Reply-To: <548EF87D.8080409@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/TOhGrYS0WecK2rbjSDU_CUH3snc Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 16 Dec 2014 11:17:24 -0000 I read your proposal as to not have any ABNF at all, and a proposal to rely= on the IANA registration. If that is what is proposed it contains no normative proposal for the codin= g, and therefore that is why it is not acceptable. I prefer the =3D/ which at least adds to the 3261 definition.=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > Sent: 15 December 2014 15:04 > To: DRAGE, Keith (Keith); dispatch@ietf.org > Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl >=20 > On 12/14/14 12:31 PM, DRAGE, Keith (Keith) wrote: > > The IANA considerations section extends nothing - it is=20 > merely a set of instructions to IANA on how to update the=20 > registration tables. >=20 > Exactly. That is the point. >=20 > > Therefore what you propose is not a practical solution to=20 > the documentation. >=20 > Why? >=20 > Thanks, > Paul >=20 > > Regards > > > > Keith > > > >> -----Original Message----- > >> From: dispatch [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of Paul=20 > >> Kyzivat > >> Sent: 12 December 2014 21:07 > >> To: dispatch@ietf.org > >> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl > >> > >> On 12/12/14 11:57 AM, Christer Holmberg wrote: > >>> Hi, > >>> > >>>>> There has been some discussion about whether such a=20 > change (using > >>>>> =3D/) constitutes a revision to the base draft. (IMO it=20 > does, some=20 > >>>>> people don't think so.) If you actually do the change=20 > as you did=20 > >>>>> then I think there is no question - it clearly is a revision! > >>>> > >>>> It could be argued both ways, I think. Strictly speaking, > >> the change > >>>> doesn't extend the set of strings that are generated by=20 > >>>> , so I could argue that the draft only > >> extends the base RFC by providing additional interpretation to=20 > >> strings that > are already valid. > >>> > >>> My fingers are ready, waiting on the keyboard. Just tell=20 > me what to=20 > >>> type :) > >> > >> My preference is that you not provide any ABNF extending=20 > the values=20 > >> for uri-parameter. The IANA considerations section are sufficient. > >> > >> Obviously we have a difference of opinion here. > >> > >> Thanks, > >> Paul > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> >=20 > = From nobody Tue Dec 16 05:41:31 2014 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 8E23F1A1B19 for ; Tue, 16 Dec 2014 05:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgaBRjtcwCSC for ; Tue, 16 Dec 2014 05:41:28 -0800 (PST) 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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6F81A1B0C for ; Tue, 16 Dec 2014 05:41:26 -0800 (PST) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-05v.sys.comcast.net with comcast id UDh71p0042AWL2D01DhSaU; Tue, 16 Dec 2014 13:41:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-04v.sys.comcast.net with comcast id UDhR1p00J3Ge9ey01DhRKB; Tue, 16 Dec 2014 13:41:26 +0000 Message-ID: <54903685.3090507@alum.mit.edu> Date: Tue, 16 Dec 2014 08:41:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , "dispatch@ietf.org" References: <548A256F.1010801@alum.mit.edu> (pkyzivat@alum.mit.edu) <874mt154lh.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> <548B590F.2090709@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B294A17@FR712WXCHMBA11.zeu.alcatel-lucent.com> <548EF87D.8080409@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B295BC0@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B295BC0@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418737286; bh=mQh6IYwhkenB5SAJHtnEc703pnG4Cok0BZub+tPciWY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=enJl7k+kozvwepkcxIEzoRD2b/A9gtmVLKBPWUvNCrxIi/rfUIaewEVT9oDvo4UKn PHexMoEAHPNS4BH2Vih0OuGQsZ/5l0UP41zeiHZ5xp4I7FN2Avpaa0nlD1e5YQP3Cd IbOLY9RMCqjuFc9N4OxDQxqK9OT+wMf58PkyOVjSWQv6DQ1k3WW6aW9HJSM3o/30Cb RKW+5Xj9DX9+r8q1z2+O5skCA5C8lXpR7UXNXMoLdSd76a3YAob0L6mx3PGKhRkluC 7CkBxiwa/KLHoyUVASfpCTjf2/NAkeNlkmA1Y/FBlYzlKmRJd6zX0wgrwRWlU5Go49 g/Yenqe/SstDw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/o7tx9ymtXu6S4bOGrj5U6xSbyuE Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 16 Dec 2014 13:41:29 -0000 On 12/16/14 6:17 AM, DRAGE, Keith (Keith) wrote: > I read your proposal as to not have any ABNF at all, and a proposal to rely on the IANA registration. > > If that is what is proposed it contains no normative proposal for the coding, and therefore that is why it is not acceptable. It needs to say in a normative way that it is defining a new uri-parameter, consistent with the definition in 3261, and give the name of that parameter. That is all it needs to do. AFAICT, this *could* be accomplished with normative language within the IANA Considerations section, or it could be in some other section referenced by the IANA Considerations section. Thanks, Paul > I prefer the =/ which at least adds to the 3261 definition. > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 15 December 2014 15:04 >> To: DRAGE, Keith (Keith); dispatch@ietf.org >> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl >> >> On 12/14/14 12:31 PM, DRAGE, Keith (Keith) wrote: >>> The IANA considerations section extends nothing - it is >> merely a set of instructions to IANA on how to update the >> registration tables. >> >> Exactly. That is the point. >> >>> Therefore what you propose is not a practical solution to >> the documentation. >> >> Why? >> >> Thanks, >> Paul >> >>> Regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: dispatch [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Paul >>>> Kyzivat >>>> Sent: 12 December 2014 21:07 >>>> To: dispatch@ietf.org >>>> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl >>>> >>>> On 12/12/14 11:57 AM, Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>>>> There has been some discussion about whether such a >> change (using >>>>>>> =/) constitutes a revision to the base draft. (IMO it >> does, some >>>>>>> people don't think so.) If you actually do the change >> as you did >>>>>>> then I think there is no question - it clearly is a revision! >>>>>> >>>>>> It could be argued both ways, I think. Strictly speaking, >>>> the change >>>>>> doesn't extend the set of strings that are generated by >>>>>> , so I could argue that the draft only >>>> extends the base RFC by providing additional interpretation to >>>> strings that > are already valid. >>>>> >>>>> My fingers are ready, waiting on the keyboard. Just tell >> me what to >>>>> type :) >>>> >>>> My preference is that you not provide any ABNF extending >> the values >>>> for uri-parameter. The IANA considerations section are sufficient. >>>> >>>> Obviously we have a difference of opinion here. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >> >> From nobody Tue Dec 16 05:53:40 2014 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 B60741A1B1A for ; Tue, 16 Dec 2014 05:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRKgEqzIi91j for ; Tue, 16 Dec 2014 05:53:37 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1B31A1AB1 for ; Tue, 16 Dec 2014 05:53:35 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-86-5490395d1d27 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3C.44.24955.D5930945; Tue, 16 Dec 2014 14:53:34 +0100 (CET) Received: from ESESSMB208.ericsson.se ([169.254.8.173]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 14:53:33 +0100 From: Christer Holmberg To: Paul Kyzivat , "DRAGE, Keith (Keith)" , "dispatch@ietf.org" Thread-Topic: [dispatch] AD review of draft-holmberg-dispatch-iotl Thread-Index: AQHQFhdBZr5NpOwNi02y+0ZPv/YmtpyMLQZQgAA1S4CAAuh3gIABaR+AgAFS2QCAAChGgIAAExJA Date: Tue, 16 Dec 2014 13:53:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5DCA2E@ESESSMB208.ericsson.se> References: <548A256F.1010801@alum.mit.edu> (pkyzivat@alum.mit.edu) <874mt154lh.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> <548B590F.2090709@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B294A17@FR712WXCHMBA11.zeu.alcatel-lucent.com> <548EF87D.8080409@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B295BC0@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54903685.3090507@alum.mit.edu> In-Reply-To: <54903685.3090507@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjW6c5YQQg4P3OS2WTlrAavG08Syj xYoNB1gdmD1an+1l9fj7/gOTx5IlP5kCmKO4bFJSczLLUov07RK4Mj6u7mEv+CVW8ejrevYG xhNCXYycHBICJhLvjr1ihrDFJC7cW8/WxcjFISRwhFHi0cWbTBDOEkaJ1y0rgRwODjYBC4nu f9ogcRGBHkaJH1t3soB0Cws4SlztWAw2SUTASWLvl59QdpTE044HjCA2i4CqxKkXy8DqeQV8 JU4cfAm1bQezxNqXN8ESnAI6EpOP3QNrZgQ66fupNUwgNrOAuMStJ/OZIE4VkFiy5zzU2aIS Lx//Y4WwFSXanzYwQtTrSCzY/YkNwtaWWLbwNTPEYkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKy gJFlFaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZg/Bzc8lt1B+PlN46HGAU4GJV4eA0W9IcI sSaWFVfmHmKU5mBREuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG2kdm2Y9PndN0 UPEOuGgtmPd4UsWbM0XiM1TNn2xnXc2QF9DN/OlMCdNEv/arP+MnnaurmsusscFotq3A4Vki jjNylQrWzZ203/2V/Y8VTnbLsx4v8Ty6NEe1Ii1/wTuf3J23Lm3d4z53BZ8yq/pPVzbhAN9v jR/UJpzmlGZIrfrYXPFI4I++EktxRqKhFnNRcSIAjcuSbIACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/EoArcWxvRqnC5DrZuKPso1ybKJI Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 16 Dec 2014 13:53:39 -0000 Hi, >> I read your proposal as to not have any ABNF at all, and a proposal to r= ely on the IANA registration. >> >> If that is what is proposed it contains no normative proposal for the co= ding, and therefore that is why it is not acceptable. > > It needs to say in a normative way that it is defining a new uri-paramete= r, consistent with the definition in 3261, and give the name of that parame= ter. That is all it needs to do. Just for my understanding, where would the syntax of the parameter value(s)= etc be defined? Regards, Christer > I prefer the =3D/ which at least adds to the 3261 definition. > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 15 December 2014 15:04 >> To: DRAGE, Keith (Keith); dispatch@ietf.org >> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl >> >> On 12/14/14 12:31 PM, DRAGE, Keith (Keith) wrote: >>> The IANA considerations section extends nothing - it is >> merely a set of instructions to IANA on how to update the=20 >> registration tables. >> >> Exactly. That is the point. >> >>> Therefore what you propose is not a practical solution to >> the documentation. >> >> Why? >> >> Thanks, >> Paul >> >>> Regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: dispatch [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Paul >>>> Kyzivat >>>> Sent: 12 December 2014 21:07 >>>> To: dispatch@ietf.org >>>> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl >>>> >>>> On 12/12/14 11:57 AM, Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>>>> There has been some discussion about whether such a >> change (using >>>>>>> =3D/) constitutes a revision to the base draft. (IMO it >> does, some >>>>>>> people don't think so.) If you actually do the change >> as you did >>>>>>> then I think there is no question - it clearly is a revision! >>>>>> >>>>>> It could be argued both ways, I think. Strictly speaking, >>>> the change >>>>>> doesn't extend the set of strings that are generated by=20 >>>>>> , so I could argue that the draft only >>>> extends the base RFC by providing additional interpretation to=20 >>>> strings that > are already valid. >>>>> >>>>> My fingers are ready, waiting on the keyboard. Just tell >> me what to >>>>> type :) >>>> >>>> My preference is that you not provide any ABNF extending >> the values >>>> for uri-parameter. The IANA considerations section are sufficient. >>>> >>>> Obviously we have a difference of opinion here. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> 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 Dec 16 06:03:36 2014 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 C35A81A1AC2 for ; Tue, 16 Dec 2014 06:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bU61VB0E2bkh for ; Tue, 16 Dec 2014 06:03:33 -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 9F1981A1A8F for ; Tue, 16 Dec 2014 06:03:32 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 34B144CDA6459; Tue, 16 Dec 2014 14:03:28 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sBGE3OGL013730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Dec 2014 15:03:30 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 15:03:26 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] AD review of draft-holmberg-dispatch-iotl Thread-Index: AQHQGTX8WDyZe1mldUGUh5XqNnd/XZySLCsAgAASf/A= Date: Tue, 16 Dec 2014 14:03:26 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B295D9D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <548A256F.1010801@alum.mit.edu> (pkyzivat@alum.mit.edu) <874mt154lh.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> <548B590F.2090709@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B294A17@FR712WXCHMBA11.zeu.alcatel-lucent.com> <548EF87D.8080409@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B295BC0@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54903685.3090507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5DCA2E@ESESSMB208.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5DCA2E@ESESSMB208.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/sxsKS8w7QHCU5s5GxE5J3BWAYyQ Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 16 Dec 2014 14:03:36 -0000 Well in my view in the main body of the document. The main body of the document is for the implementors to read. The IANA con= siderations section is for IANA to read, and then update to say what they h= ave done. Regards Keith > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 16 December 2014 13:54 > To: Paul Kyzivat; DRAGE, Keith (Keith); dispatch@ietf.org > Subject: RE: [dispatch] AD review of draft-holmberg-dispatch-iotl >=20 > Hi, >=20 > >> I read your proposal as to not have any ABNF at all, and a=20 > proposal to rely on the IANA registration. > >> > >> If that is what is proposed it contains no normative=20 > proposal for the coding, and therefore that is why it is not=20 > acceptable. > > > > It needs to say in a normative way that it is defining a=20 > new uri-parameter, consistent with the definition in 3261,=20 > and give the name of that parameter. That is all it needs to do. >=20 > Just for my understanding, where would the syntax of the=20 > parameter value(s) etc be defined? >=20 > Regards, >=20 > Christer >=20 >=20 > > I prefer the =3D/ which at least adds to the 3261 definition. > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: 15 December 2014 15:04 > >> To: DRAGE, Keith (Keith); dispatch@ietf.org > >> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl > >> > >> On 12/14/14 12:31 PM, DRAGE, Keith (Keith) wrote: > >>> The IANA considerations section extends nothing - it is > >> merely a set of instructions to IANA on how to update the=20 > >> registration tables. > >> > >> Exactly. That is the point. > >> > >>> Therefore what you propose is not a practical solution to > >> the documentation. > >> > >> Why? > >> > >> Thanks, > >> Paul > >> > >>> Regards > >>> > >>> Keith > >>> > >>>> -----Original Message----- > >>>> From: dispatch [mailto:dispatch-bounces@ietf.org] On > >> Behalf Of Paul > >>>> Kyzivat > >>>> Sent: 12 December 2014 21:07 > >>>> To: dispatch@ietf.org > >>>> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl > >>>> > >>>> On 12/12/14 11:57 AM, Christer Holmberg wrote: > >>>>> Hi, > >>>>> > >>>>>>> There has been some discussion about whether such a > >> change (using > >>>>>>> =3D/) constitutes a revision to the base draft. (IMO it > >> does, some > >>>>>>> people don't think so.) If you actually do the change > >> as you did > >>>>>>> then I think there is no question - it clearly is a revision! > >>>>>> > >>>>>> It could be argued both ways, I think. Strictly speaking, > >>>> the change > >>>>>> doesn't extend the set of strings that are generated by=20 > >>>>>> , so I could argue that the draft only > >>>> extends the base RFC by providing additional interpretation to=20 > >>>> strings that > are already valid. > >>>>> > >>>>> My fingers are ready, waiting on the keyboard. Just tell > >> me what to > >>>>> type :) > >>>> > >>>> My preference is that you not provide any ABNF extending > >> the values > >>>> for uri-parameter. The IANA considerations section are=20 > sufficient. > >>>> > >>>> Obviously we have a difference of opinion here. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> _______________________________________________ > >>>> 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 Tue Dec 16 07:49:05 2014 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 3F6AE1A1B05 for ; Tue, 16 Dec 2014 07:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrTn0Sl5ki9H for ; Tue, 16 Dec 2014 07:48:56 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7AD1A1B49 for ; Tue, 16 Dec 2014 07:48:54 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBGFmrrb053000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 16 Dec 2014 09:48:54 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <54905460.7060508@nostrum.com> Date: Tue, 16 Dec 2014 09:48:48 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <548A256F.1010801@alum.mit.edu> (pkyzivat@alum.mit.edu) <874mt154lh.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> <548B590F.2090709@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B294A17@FR712WXCHMBA11.zeu.alcatel-lucent.com> <548EF87D.8080409@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B295BC0@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54903685.3090507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5DCA2E@ESESSMB208.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B295D9D@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B295D9D@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/gA9B2UrXv_i5FyPJTcphkYwzndg Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 16 Dec 2014 15:48:58 -0000 I've found this conversation a little hard to follow. Hopefully I'm not going to make it worse for anyone, but I think this is where the discussion is. 1) There _should_ be some ABNF somewhere, the core of the remaining discussion is where to put it. 2) The ABNF should probably use =/ (even though Christer didn't do that for -03). Do I have that right? fwiw, I drew the genart straw on this draft, and will be doing a careful review, but hadn't planned to do that until later this week or sometime next. RjS On 12/16/14 8:03 AM, DRAGE, Keith (Keith) wrote: > Well in my view in the main body of the document. > > The main body of the document is for the implementors to read. The IANA considerations section is for IANA to read, and then update to say what they have done. > > Regards > > Keith > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: 16 December 2014 13:54 >> To: Paul Kyzivat; DRAGE, Keith (Keith); dispatch@ietf.org >> Subject: RE: [dispatch] AD review of draft-holmberg-dispatch-iotl >> >> Hi, >> >>>> I read your proposal as to not have any ABNF at all, and a >> proposal to rely on the IANA registration. >>>> If that is what is proposed it contains no normative >> proposal for the coding, and therefore that is why it is not >> acceptable. >>> It needs to say in a normative way that it is defining a >> new uri-parameter, consistent with the definition in 3261, >> and give the name of that parameter. That is all it needs to do. >> >> Just for my understanding, where would the syntax of the >> parameter value(s) etc be defined? >> >> Regards, >> >> Christer >> >> >>> I prefer the =/ which at least adds to the 3261 definition. >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: 15 December 2014 15:04 >>>> To: DRAGE, Keith (Keith); dispatch@ietf.org >>>> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl >>>> >>>> On 12/14/14 12:31 PM, DRAGE, Keith (Keith) wrote: >>>>> The IANA considerations section extends nothing - it is >>>> merely a set of instructions to IANA on how to update the >>>> registration tables. >>>> >>>> Exactly. That is the point. >>>> >>>>> Therefore what you propose is not a practical solution to >>>> the documentation. >>>> >>>> Why? >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards >>>>> >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: dispatch [mailto:dispatch-bounces@ietf.org] On >>>> Behalf Of Paul >>>>>> Kyzivat >>>>>> Sent: 12 December 2014 21:07 >>>>>> To: dispatch@ietf.org >>>>>> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl >>>>>> >>>>>> On 12/12/14 11:57 AM, Christer Holmberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>>>> There has been some discussion about whether such a >>>> change (using >>>>>>>>> =/) constitutes a revision to the base draft. (IMO it >>>> does, some >>>>>>>>> people don't think so.) If you actually do the change >>>> as you did >>>>>>>>> then I think there is no question - it clearly is a revision! >>>>>>>> It could be argued both ways, I think. Strictly speaking, >>>>>> the change >>>>>>>> doesn't extend the set of strings that are generated by >>>>>>>> , so I could argue that the draft only >>>>>> extends the base RFC by providing additional interpretation to >>>>>> strings that > are already valid. >>>>>>> My fingers are ready, waiting on the keyboard. Just tell >>>> me what to >>>>>>> type :) >>>>>> My preference is that you not provide any ABNF extending >>>> the values >>>>>> for uri-parameter. The IANA considerations section are >> sufficient. >>>>>> Obviously we have a difference of opinion here. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>> >>>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Dec 16 10:49:35 2014 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 C49DA1ACDC4 for ; Tue, 16 Dec 2014 10:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbIQx9-Oiw5z for ; Tue, 16 Dec 2014 10:49:31 -0800 (PST) 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 1ED271A8712 for ; Tue, 16 Dec 2014 10:49:30 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-d2-54907eb81611 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D9.88.04076.8BE70945; Tue, 16 Dec 2014 19:49:29 +0100 (CET) Received: from ESESSMB208.ericsson.se ([169.254.8.173]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 19:49:28 +0100 From: Christer Holmberg To: Robert Sparks , "dispatch@ietf.org" Thread-Topic: [dispatch] AD review of draft-holmberg-dispatch-iotl Thread-Index: AQHQFhdBZr5NpOwNi02y+0ZPv/YmtpyMLQZQgAA1S4CAAuh3gIABaR+AgAFS2QCAAChGgIAAExJA///zFQCAAB1wAIAAQjjQ Date: Tue, 16 Dec 2014 18:49:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5DD6AB@ESESSMB208.ericsson.se> References: <548A256F.1010801@alum.mit.edu> (pkyzivat@alum.mit.edu) <874mt154lh.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> <548B590F.2090709@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B294A17@FR712WXCHMBA11.zeu.alcatel-lucent.com> <548EF87D.8080409@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B295BC0@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54903685.3090507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5DCA2E@ESESSMB208.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B295D9D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54905460.7060508@nostrum.com> In-Reply-To: <54905460.7060508@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje7OugkhBgt/8FosnbSA1eLanEY2 ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugStjw7NetoJJqhUrJ95lb2DcKNfFyMkhIWAi sezVX3YIW0ziwr31bF2MXBxCAkcYJb6vnskK4SxhlJj35BhjFyMHB5uAhUT3P22QBhGBYIlL DZtYQGxhAUeJqx2LmSHiThJ7v/xkBikXEciT+LpEGCTMIqAq0bD0ICuIzSvgK7H6+GIwW0jg HYtEy35BEJtTQFtiS+dRsJGMQPd8P7WGCcRmFhCXuPVkPhPEnQISS/acZ4awRSVePv7HCmEr Saw9vJ0Fol5HYsHuT2wQtrbEsoWvmSH2CkqcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGEWL U4uLc9ONjPRSizKTi4vz8/TyUks2MQKj5OCW31Y7GA8+dzzEKMDBqMTDa7CgP0SINbGsuDL3 EKM0B4uSOO/Cc/OChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAuX/P15J95v2RD26dGf/Pl 3sFy5OlzDpeHcsIP9j9SW8RyIfqhbNw1BoF3H0u/tXx9d+7WlT+NHQt9lTnexh1rLa2O7F5i WSTgIJGiyWqxQj/Ibc3/kqrZqYmrqt7ViPZ1yDTU7Jk3+e+8/+sZupeICq1bXPHJ8466pJ2J /9ejSWsWxyi2L1ugxFKckWioxVxUnAgAJJxJR3MCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/l8xdxxXe-5iNpGigrW9RrurATOc Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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, 16 Dec 2014 18:49:33 -0000 Hi Robert, >I've found this conversation a little hard to follow. >Hopefully I'm not going to make it worse for anyone, but I think this is w= here the >discussion is. > >1) There _should_ be some ABNF somewhere, the core of the remaining discus= sion is >where to put it. >2) The ABNF should probably use =3D/ (even though Christer didn't do that = for -03). -03 (submitted today) does use =3D/, as it seems everyone can live with tha= t. http://www.ietf.org/id/draft-holmberg-dispatch-iotl-03.txt >fwiw, I drew the genart straw on this draft, and will be doing a careful r= eview, but >hadn't planned to do that until later this week or sometime nex= t. Were you assigned version -03? If not, is it possible to change the version= ? Regards, Christer On 12/16/14 8:03 AM, DRAGE, Keith (Keith) wrote: > Well in my view in the main body of the document. > > The main body of the document is for the implementors to read. The IANA c= onsiderations section is for IANA to read, and then update to say what they= have done. > > Regards > > Keith > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: 16 December 2014 13:54 >> To: Paul Kyzivat; DRAGE, Keith (Keith); dispatch@ietf.org >> Subject: RE: [dispatch] AD review of draft-holmberg-dispatch-iotl >> >> Hi, >> >>>> I read your proposal as to not have any ABNF at all, and a >> proposal to rely on the IANA registration. >>>> If that is what is proposed it contains no normative >> proposal for the coding, and therefore that is why it is not=20 >> acceptable. >>> It needs to say in a normative way that it is defining a >> new uri-parameter, consistent with the definition in 3261, and give=20 >> the name of that parameter. That is all it needs to do. >> >> Just for my understanding, where would the syntax of the parameter=20 >> value(s) etc be defined? >> >> Regards, >> >> Christer >> >> >>> I prefer the =3D/ which at least adds to the 3261 definition. >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: 15 December 2014 15:04 >>>> To: DRAGE, Keith (Keith); dispatch@ietf.org >>>> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl >>>> >>>> On 12/14/14 12:31 PM, DRAGE, Keith (Keith) wrote: >>>>> The IANA considerations section extends nothing - it is >>>> merely a set of instructions to IANA on how to update the=20 >>>> registration tables. >>>> >>>> Exactly. That is the point. >>>> >>>>> Therefore what you propose is not a practical solution to >>>> the documentation. >>>> >>>> Why? >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards >>>>> >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: dispatch [mailto:dispatch-bounces@ietf.org] On >>>> Behalf Of Paul >>>>>> Kyzivat >>>>>> Sent: 12 December 2014 21:07 >>>>>> To: dispatch@ietf.org >>>>>> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl >>>>>> >>>>>> On 12/12/14 11:57 AM, Christer Holmberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>>>> There has been some discussion about whether such a >>>> change (using >>>>>>>>> =3D/) constitutes a revision to the base draft. (IMO it >>>> does, some >>>>>>>>> people don't think so.) If you actually do the change >>>> as you did >>>>>>>>> then I think there is no question - it clearly is a revision! >>>>>>>> It could be argued both ways, I think. Strictly speaking, >>>>>> the change >>>>>>>> doesn't extend the set of strings that are generated by=20 >>>>>>>> , so I could argue that the draft only >>>>>> extends the base RFC by providing additional interpretation to=20 >>>>>> strings that > are already valid. >>>>>>> My fingers are ready, waiting on the keyboard. Just tell >>>> me what to >>>>>>> type :) >>>>>> My preference is that you not provide any ABNF extending >>>> the values >>>>>> for uri-parameter. The IANA considerations section are >> sufficient. >>>>>> Obviously we have a difference of opinion here. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> _______________________________________________ >>>>>> 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 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Dec 16 21:22:06 2014 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 2C02B1A1BF6 for ; Tue, 16 Dec 2014 21:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fU_3jdpA1AzL for ; Tue, 16 Dec 2014 21:22:02 -0800 (PST) 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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441151A0394 for ; Tue, 16 Dec 2014 21:22:02 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-05v.sys.comcast.net with comcast id UVN11p00229Cfhx01VN1Vu; Wed, 17 Dec 2014 05:22:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-03v.sys.comcast.net with comcast id UVN01p00U3Ge9ey01VN1Xi; Wed, 17 Dec 2014 05:22:01 +0000 Message-ID: <549112F8.2060703@alum.mit.edu> Date: Wed, 17 Dec 2014 00:22:00 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <548A256F.1010801@alum.mit.edu> (pkyzivat@alum.mit.edu) <874mt154lh.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D5924C3@ESESSMB209.ericsson.se> <548B590F.2090709@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B294A17@FR712WXCHMBA11.zeu.alcatel-lucent.com> <548EF87D.8080409@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B295BC0@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54903685.3090507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5DCA2E@ESESSMB208.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B295D9D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54905460.7060508@nostrum.com> In-Reply-To: <54905460.7060508@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418793721; bh=rKwQQnENXWhNGhv5D2Pnp4ib7AlXIZDCbo5nwH7M9qc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UVrCzqYbjVPx3vDj8myW7Q9KX7Ka2divIeZ0/ghFL/ZFLeKOtVSvhBILcMQtAtf3C BXaHTnOxmzGV/yiCRxWk7Tp55f/SlDtfM4SYiwGpuTfDOpKYTziNqRwdME+3TwufOW 08I9M+4NaOzQDWNJnCP6rr7Z16dvoqikL4OCGDkzItG1Lo4ZvoWtRLFKBGfYkMdhzK 8jPW83IPOX/InwQawl83iS7Joxcyu+w6bcxn9xDIZjaHPTrdCTvBf9JQxg4wYL+HVy A83EwuAI1GzWzrf4Ndfc5EvQ0nSD614Hl1AC7bCN6YSkkqrcbjlJsSt0CwywCHClXb S2u+vu8Kuu2NA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/-D7_Nc33hs0GuSmd5M22mKSYNBk Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl 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: Wed, 17 Dec 2014 05:22:04 -0000 On 12/16/14 10:48 AM, Robert Sparks wrote: > I've found this conversation a little hard to follow. > Hopefully I'm not going to make it worse for anyone, but I think this is > where the discussion is. > > 1) There _should_ be some ABNF somewhere, the core of the remaining > discussion is where to put it. > 2) The ABNF should probably use =/ (even though Christer didn't do that > for -03). > > Do I have that right? I'm arguing otherwise. My opinion is that in cases where there is an IANA registry of values, and the base syntax has provision for values defined in the future, then there need not, and should not, be ABNF extending the base syntax. Yes, I know this goes against a lot of precedent. But I also find that the result of that precedent is confusing. It is *less* confusing when =/ is used than when the base syntax rule is restated and revised, but still confusing nevertheless. When there is a registry it is the only authoritative place to get an exhaustive list of possible values. In the future, I would not do enumerations in ABNF for things that are to have registries - right from the beginning. Thanks, Paul > fwiw, I drew the genart straw on this draft, and will be doing a careful > review, but hadn't planned to do > that until later this week or sometime next. > > RjS > > On 12/16/14 8:03 AM, DRAGE, Keith (Keith) wrote: >> Well in my view in the main body of the document. >> >> The main body of the document is for the implementors to read. The >> IANA considerations section is for IANA to read, and then update to >> say what they have done. >> >> Regards >> >> Keith >> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: 16 December 2014 13:54 >>> To: Paul Kyzivat; DRAGE, Keith (Keith); dispatch@ietf.org >>> Subject: RE: [dispatch] AD review of draft-holmberg-dispatch-iotl >>> >>> Hi, >>> >>>>> I read your proposal as to not have any ABNF at all, and a >>> proposal to rely on the IANA registration. >>>>> If that is what is proposed it contains no normative >>> proposal for the coding, and therefore that is why it is not >>> acceptable. >>>> It needs to say in a normative way that it is defining a >>> new uri-parameter, consistent with the definition in 3261, >>> and give the name of that parameter. That is all it needs to do. >>> >>> Just for my understanding, where would the syntax of the >>> parameter value(s) etc be defined? >>> >>> Regards, >>> >>> Christer >>> >>> >>>> I prefer the =/ which at least adds to the 3261 definition. >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>> Sent: 15 December 2014 15:04 >>>>> To: DRAGE, Keith (Keith); dispatch@ietf.org >>>>> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl >>>>> >>>>> On 12/14/14 12:31 PM, DRAGE, Keith (Keith) wrote: >>>>>> The IANA considerations section extends nothing - it is >>>>> merely a set of instructions to IANA on how to update the >>>>> registration tables. >>>>> >>>>> Exactly. That is the point. >>>>> >>>>>> Therefore what you propose is not a practical solution to >>>>> the documentation. >>>>> >>>>> Why? >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Regards >>>>>> >>>>>> Keith >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: dispatch [mailto:dispatch-bounces@ietf.org] On >>>>> Behalf Of Paul >>>>>>> Kyzivat >>>>>>> Sent: 12 December 2014 21:07 >>>>>>> To: dispatch@ietf.org >>>>>>> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl >>>>>>> >>>>>>> On 12/12/14 11:57 AM, Christer Holmberg wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>>>> There has been some discussion about whether such a >>>>> change (using >>>>>>>>>> =/) constitutes a revision to the base draft. (IMO it >>>>> does, some >>>>>>>>>> people don't think so.) If you actually do the change >>>>> as you did >>>>>>>>>> then I think there is no question - it clearly is a revision! >>>>>>>>> It could be argued both ways, I think. Strictly speaking, >>>>>>> the change >>>>>>>>> doesn't extend the set of strings that are generated by >>>>>>>>> , so I could argue that the draft only >>>>>>> extends the base RFC by providing additional interpretation to >>>>>>> strings that > are already valid. >>>>>>>> My fingers are ready, waiting on the keyboard. Just tell >>>>> me what to >>>>>>>> type :) >>>>>>> My preference is that you not provide any ABNF extending >>>>> the values >>>>>>> for uri-parameter. The IANA considerations section are >>> sufficient. >>>>>>> Obviously we have a difference of opinion here. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Wed Dec 17 08:40:14 2014 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 3D36E1A8F4C for ; Wed, 17 Dec 2014 08:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rwq_vHkZEgzK for ; Wed, 17 Dec 2014 08:39:58 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE231A8F37 for ; Wed, 17 Dec 2014 08:39:55 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id DCD4D264320; Wed, 17 Dec 2014 17:39:53 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id AFE5727C098; Wed, 17 Dec 2014 17:39:53 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Wed, 17 Dec 2014 17:39:53 +0100 From: To: "Dale R. Worley" Thread-Topic: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 Thread-Index: AQHQGLRBeDuYjLy8Qce0wuL96+hw6pyTna+w Date: Wed, 17 Dec 2014 16:39:52 +0000 Message-ID: <12008_1418834393_5491B1D9_12008_723_6_8B970F90C584EA4E97D5BAAC9172DBB8142CA341@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <15139_1417707803_5480811A_15139_368_1_8B970F90C584EA4E97D5BAAC9172DBB8142C6B0F@PEXCVZYM12.corporate.adroot.infra.ftgroup> (marianne.mohali@orange.com) <87fvcgr28w.fsf@hobgoblin.ariadne.com> In-Reply-To: <87fvcgr28w.fsf@hobgoblin.ariadne.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.73920 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/QOoFJxv9HP4MkG2R_-FLkPix9yA Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 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: Wed, 17 Dec 2014 16:40:05 -0000 Hi, Thank you Dale for your support! Indeed, I think IN (for Intelligent Network) is not an acronym to be used i= n the SIP world. I would like to define a new vocabulary to define a clear = context of the usage of this new cause value. I was thinking about somethin= g like "Service access number translation" : action to replace as received = alias number identifying a service by a target number to be routed downstre= am. Any opinion?=20 BR, Marianne -----Message d'origine----- De=A0: Dale R. Worley [mailto:worley@ariadne.com]=20 Envoy=E9=A0: lundi 15 d=E9cembre 2014 23:13 =C0=A0: MOHALI Marianne IMT/OLN Cc=A0: dispatch@ietf.org Objet=A0: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number= -00 This draft seems valuable to me and I think it should progress. One nit is the use of "IN". I believe it means "Intelligent Network" in th= e Q.1200 sense, but that acronym isn't commonly used in the SIP world, so i= t would help if it was explained more fully when it is first used. Dale ___________________________________________________________________________= ______________________________________________ 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 Thu Dec 18 07:43:16 2014 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 F3FF81A9080 for ; Thu, 18 Dec 2014 07:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UrpEDg7PfBi for ; Thu, 18 Dec 2014 07:43:01 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD44F1A9075 for ; Thu, 18 Dec 2014 07:42:59 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-e8-5492f601c251 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id EB.1E.29772.106F2945; Thu, 18 Dec 2014 16:42:58 +0100 (CET) Received: from ESESSMB305.ericsson.se ([169.254.5.122]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 16:42:57 +0100 From: =?iso-8859-1?Q?J=F6rgen_Axell?= To: "marianne.mohali@orange.com" , "dispatch@ietf.org" Thread-Topic: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 Thread-Index: AdAP2C5BeDuYjLy8Qce0wuL96+hw6gAfumQAAA9KhDACjPZfsA== Date: Thu, 18 Dec 2014 15:42:57 +0000 Message-ID: <5AEA7B339C0B944BB33A6939249264AD1A203ACD@ESESSMB305.ericsson.se> References: <15139_1417707803_5480811A_15139_368_1_8B970F90C584EA4E97D5BAAC9172DBB8142C6B0F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <1E97FFD1485F1142BC075FF145A53A1E043D532D@A04067.BGC.NET> <14147_1417788307_5481BB93_14147_9260_1_8B970F90C584EA4E97D5BAAC9172DBB8142C7104@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <14147_1417788307_5481BB93_14147_9260_1_8B970F90C584EA4E97D5BAAC9172DBB8142C7104@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_5AEA7B339C0B944BB33A6939249264AD1A203ACDESESSMB305erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM+JvjS7Tt0khBg+/sVgsnbSA1WJb8z4m ByaPJUt+Mnm0PDvJFsAUxWWTkpqTWZZapG+XwJWxZvEttoK/vUwVp2bMYG5gPPSRsYuRk0NC wERiwdq3zBC2mMSFe+vZuhi5OIQEjjBKPNvUwgThLGGUWP7hIRtIFZuAo8TVf3/YQWwRgQyJ 7StWs4LYwgK+Esd7jrJBxAMkTvy5CLSBA8h2kjhyLxokzCKgKvHhXAcTiM0LVL7n5DN2iPkH mCR2ty1hAXE4BToYJf7cmAY2iFFAVuL+93ssIDazgLjErSfzmSBOFZBYsuc81NmiEi8f/2OF sBUlPr7axwhRny9xsXU3G8Q2QYmTM5+wTGAUmYVk1CwkZbOQlEHE9SRuTJ3CBmFrSyxb+JoZ wtaVmPHvEAuy+AJG9lWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgfF1cMtvgx2ML587HmIU 4GBU4uE1cJ4UIsSaWFZcmXuIUZqDRUmcd+G5ecFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GH3WVWTuP20oMkdLPGlrTWeh5mG//YmHribG7TnqdU3kxg9/Zp2W1SkKh67ebHwTKJm52G79 56Ym3fPfvcMylaUmRjIqry9xdLO57znLYsq/gu2Ndz22zV1a+6K3Z7HQa/HUaZk217pVXgu6 hrWfZWefUFP5rHeC0vFZ++aGtRr2l3rz3z3/RomlOCPRUIu5qDgRAFRLv+mQAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/L1OXKyccCwQDKfir2FvumfPLdMw Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 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, 18 Dec 2014 15:43:15 -0000 --_000_5AEA7B339C0B944BB33A6939249264AD1A203ACDESESSMB305erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bonjour Marianne, I believe this is a useful case and Ihave some minor comments: Please be consistent in specifying that it is the "cause" URI parameter (or= SIP URI parameter). The confusion with the "cause" in Reason headers is we= ll-known. Section 2: " URIs that are issued form a retargeting" from a retargeting? Section 3: "mp" tag seems to be a pre-requisite for the "cause" SIP URI par= ameter. Is this always true? Can't the number translation be seen as a repl= acement of the dialled number without changing the target user? In section 3 you change to cause-param and target-param instead of "cause" = SIP URI... Section 4 hte-->the Section 5: " new value for the "cause" parameter: 480" I thought 380 ;-), 4= 80 is deflection immediate response. Regards, J=F6rgen From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of marianne.moh= ali@orange.com Sent: 05 December 2014 15:05 To: VAN GEEL Jan (SPC/CSP); dispatch@ietf.org Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number-= 00 Hi Jan, It is right, I saw it after submitted the draft. I will correct it for the next version. Thank you, Kind Regards, Marianne De : VAN GEEL Jan (SPC/CSP) [mailto:jan.van.geel@proximus.com] Envoy=E9 : vendredi 5 d=E9cembre 2014 07:47 =C0 : MOHALI Marianne IMT/OLN; dispatch@ietf.org Objet : RE: [dispatch] New draft-mohali-dispatch-cause-for-service-number-0= 0 Marianne, My only comment is an editorial one: "tool free service" should be "toll fr= ee service" Kind regards Jan Van Geel IT and Network Specialist Belgacom CIS/SCC/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of marianne.moh= ali@orange.com Sent: Thursday 4 December 2014 16:43 To: dispatch@ietf.org Subject: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 Hi, I re-send my fist email with the correct draft title as subject. I already plan to improve the text of the draft by defining a clear definit= ion with a new wording to describe the scope of usage of the new cause URI = parameter value. This new vocabulary could be something like "service access number translat= ion" with a definition that will be somewhere between a retargeting while t= he target user remain the same and a redirection to a new target. Indeed, f= or premium/toll-free services users are trying to contact a service which i= s the target service and not a particular user behind a UA as a "target use= r" as defined in RFC7044. The service access number could be seen as a supe= r-alias pointing out to a set of UAs and a UAs could be pointed out by seve= ral service access numbers. Comments and review are still welcome. BR, Marianne ------ This draft defines a new value for the SIP URI parameter "cause", which can= be used to associate a SIP URI to a service access number that has been tr= anslated by a specific application. Abstract: RFC4458 defines a "cause" URI parameter as having predefined values for Red= irecting reasons as a mapping from ITU-T Q.732.2-5 Redirecting Reasons. Th= e "cause" URI parameter is to be used in SIP or SIPs URI. In particular, it= may appear in the History-Info header defined in RFC7044 that must be adde= d in retargeted requests. This specification creates a new predefined value= for cases when the retargeting is caused by a specific service action lead= ing to a called number translation. This document updates RFC4458. This draft is needed for 3GPP, but we've tried to write it in a way so that= it can also be applied to other environments. A first version of the draft can be seen under: http://www.ietf.org/internet-drafts/draft-mohali-dispatch-cause-for-service= -number-00.txt This version is a very first version and for sure needs improvement. Your comments are welcome. Regards, Marianne Mohali ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ________________________________ ***** Disclaimer ***** http://www.proximus.be/maildisclaimer ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_5AEA7B339C0B944BB33A6939249264AD1A203ACDESESSMB305erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bonjour Marianne,=

 

I believe this is a us= eful case and Ihave some minor comments:

 

Please be consistent i= n specifying that it is the "cause" URI parameter (or SIP URI par= ameter). The confusion with the "cause" in Reason headers is well= -known.

Section 2: " URIs that are issued form a retargeting" from a reta=
rgeting?
Section 3: "mp" tag seems to b=
e a pre-requisite for the "cause" SIP URI parameter. Is this alwa=
ys true? Can't the number translation be seen as a replacement of the diall=
ed number without changing the target user?
In section 3 you change to cause-param a=
nd target-param instead of "cause" SIP URI...

Section 4 hte-->the=



Section 5: " new value for t=
he "cause" parameter: 480" I t=
hought 380 ;-), 480 is deflection immediate response.

 


Regards,


J=F6rgen






From:=
 dispatch
 [mailto:dispatch-bounces@ietf.org] On Behalf Of marianne.mohali@ora=
nge.com

Sent: 05 December 2014 15:05

To: VAN GEEL Jan (SPC/CSP); dispatch@ietf.org

Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-=
number-00






 


Hi Jan,


 


It is right, I=
 saw it after submitted the draft.



I will correct=
 it for the next version.


 <=
span lang=3D"FR">


Thank you,


 <=
span lang=3D"FR">


Kind Regards,<=
/span>


Marianne


 <=
span lang=3D"FR">






D=
e : VAN GEE=
L Jan (SPC/CSP)
 [mailto:jan.van.geel@proximus=
.com]


Envoy=E9 : vendredi 5 d=E9cembre 2014 07:47

=C0 : MOHALI Marianne IMT/OLN; dispatch@ietf.org

Objet : RE: [dispatch] New draft-mohali-dispatch-cause-for-serv=
ice-number-00






 


Marianne,


 


My only comment is an =
editorial one: “tool free service” should be “toll free s=
ervice”


 


Kind regards


 




Jan Van Geel


IT and Network Spec=
ialist


Belgacom CIS/SCC/FV=
C


Tel: +32 2 202 =
1035


Tel: +32 2 207 =
9032


Email :
jan.van.geel@belgacom.be




 






From:=
 dispatch
 [mailto:dispatch-bounces@ietf=
.org]
On Behalf Of marianne.=
mohali@orange.com

Sent: Thursday 4 December 2014 16:43

To: dispatch@ietf.org

Subject: [dispatch] New draft-mohali-dispatch-cause-for-service-numb=
er-00






 


Hi,<=
span lang=3D"FR">


 


I re-send m=
y fist email with the correct draft title as subject.


 


I already p=
lan to improve the text of the draft by defining a clear definition with a =
new wording to describe the scope of usage of the new cause
 URI parameter value.


This new vo=
cabulary could be something like "service access number translation&qu=
ot; with a definition that will be somewhere between a retargeting while
 the target user remain the same and a redirection to a new target. Indeed,=
 for premium/toll-free services users are trying to contact a service which=
 is the target service and not a particular user behind a UA as a "tar=
get user" as defined in RFC7044. The
 service access number could be seen as a super-alias pointing out to a set=
 of UAs and a UAs could be pointed out by several service access numbers.



 


Comments an=
d review are still welcome.


 


BR,<=
span lang=3D"FR">


Marianne


------


This draft =
defines a new value for the SIP URI parameter "cause", which can =
be used to associate a SIP URI to a service access number that has been
 translated by a specific application.<=
/span>


 


Abstract:



RFC4458 def=
ines a "cause" URI parameter as having predefined values for Redi=
recting reasons as a mapping from ITU-T Q.732.2-5 Redirecting Reasons. =
;
 The "cause" URI parameter is to be used in SIP or SIPs URI. In p=
articular, it may appear in the History-Info header defined in RFC7044 that=
 must be added in retargeted requests. This specification creates a new pre=
defined value for cases when the retargeting
 is caused by a specific service action leading to a called number translat=
ion. This document updates RFC4458.


 


This draft =
is needed for 3GPP, but we’ve tried to write it in a way so that it c=
an also be applied to other environments.


 


A first ver=
sion of the draft can be seen under:



http://www.ietf.org/internet-drafts/draft=
-mohali-dispatch-cause-for-service-number-00.txt


 


This versio=
n is a very first version and for sure needs improvement.


Your commen=
ts are welcome.


 


Regards,


Marianne Mo=
hali


_____________________________________=
___________________________________________________________________________=
_________


 


Ce message et ses pieces jointes peuv=
ent contenir des informations confidentielles ou privilegiees et ne doivent=
 donc


pas etre diffuses, exploites ou copie=
s sans autorisation. Si vous avez recu ce message par erreur, veuillez le s=
ignaler


a l'expediteur et le detruire ainsi q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration,


Orange decline toute responsabilite s=
i 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 er=
ror, please notify the sender and delete this message and its attachments.<=
o:p>


As emails may be altered, Orange is n=
ot liable for messages that have been modified, changed or falsified.<=
/o:p>


Thank you.


 










***** Disclaimer *****

http://www.proximus.be/ma=
ildisclaimer


_____________________________________=
___________________________________________________________________________=
_________


 


Ce message et ses pieces jointes peuv=
ent contenir des informations confidentielles ou privilegiees et ne doivent=
 donc


pas etre diffuses, exploites ou copie=
s sans autorisation. Si vous avez recu ce message par erreur, veuillez le s=
ignaler


a l'expediteur et le detruire ainsi q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration,


Orange decline toute responsabilite s=
i 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 er=
ror, please notify the sender and delete this message and its attachments.<=
o:p>


As emails may be altered, Orange is n=
ot liable for messages that have been modified, changed or falsified.<=
/o:p>


Thank you.
--_000_5AEA7B339C0B944BB33A6939249264AD1A203ACDESESSMB305erics_-- From nobody Thu Dec 18 13:09:37 2014 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 13B121A1B87; Thu, 18 Dec 2014 13:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik_-PGlo5mLY; Thu, 18 Dec 2014 13:09:29 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C41D1A6FD6; Thu, 18 Dec 2014 13:09:29 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBIL9St6048239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Dec 2014 15:09:28 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54934283.5090905@nostrum.com> Date: Thu, 18 Dec 2014 15:09:23 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: draft-holmberg-dispatch-iotl@tools.ietf.org, dispatch@ietf.org, "ietf@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/YQnyBuHMi96TO-YopoL6jLcRJ1c Subject: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt 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, 18 Dec 2014 21:09:31 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-holmberg-dispatch-iotl-03 Reviewer: Robert Sparks Review Date: 18-Dec-2014 IETF LC End Date: 8-Jan-2015 IESG Telechat date: Not on an upcoming telechat agenda Summary: Almost ready for publication as a Proposed Standard but has issues that need to be addressed There are only a few issues to address: Major Issue 1: It makes no sense to publish a standards track RFC that says behavior on general networks is undefined. I've reviewed all of the list traffic about this document, and I understand how the text that's currently in the document got there, but it's not the best way to deal with the concern that caused it to be introduced. The original concern was that the document didn't provide enough detail to tell what the presence or absence of the values meant, and whether there was an associate d change to the semantics of the protocol. While the description is thin, I think there has been enough shown to know that the semantics of the protocol are not being changed. So, instead, the document should just recognize that devices that don't implement this specification will do what RFC 3261 requires them to do with unknown URI parameters: ignore them. This document sufficiently describes what the values it defines means to elements that _do_ implement this specification. They provide additional information to upper layers (ultimately, transaction users as 3261 defines them), and those upper layers might make forwarding decisions using it, just like they can use _anything_ at their disposal. The basic semantics of the SIP protocol are unaffected. To resolve this issue, I suggest removing the text that occurs in several places saying that this is applicable only to 3gpp networks, and add a short sentence reminding the reader that RFC3261 expects new URI parameters to be standardized and defines how unknown URI parameters are handled. Major Issue 2: The document suggests that implementations violate what RFC3261 requires them to do. Specifically, it says "An entity that understands the 'iotl' parameter MUST NOT, from a SIP request, remove 'iotl' parameters from SIP URIs associated with other entities, unless the entity has means to determine that the 'iotl' parameter does not represent a valid traffic leg." RFC3261 requires that MUST NOT, and it does not allow the "unless" clause. It is not ok for an entity to change some other entities URIs in, say, Route, Service-Route, Path, and similar places under any circumstances. My suggested resolution is to remove the unless clause, and change the first part of the sentence to note that this is what 3261 requires. Major issue 3: The Security considerations section is incomplete. Please discuss the ramifications of something maliciously providing an incorrect value in the parameter. What are the ramifications if someone does violate protocol and changes or removes a value in transit? Minor issue 1: It is unclear where you expect these URIs to occur. I have a good feel only after reading the list traffic. I suggest you be explicit in 5.1 that you expect these to be placed in Service-Route and Path header field values, hence to occur in Route header field values, and Request-URIs. Minor issue 2: Why do you say "This document does not specify the usage of the 'iotl' parameter within a SIP URI of a Record-Route header field. Would it create an interoperability problem if someone put one there? Because if they do, it will end up in Route header fields later. If that's ok, please strike the sentence. If it's not, then you need to say MUST NOT place the parameter in URIs in Record-Route header field values. Nits/editorial comments: Since you are providing an extension point for other values, someone will ask if you need a registry for those values. I suggest explicitly saying we are not creating a registry at this time but expect to do so if the extension point is ever used to head that conversation off. "dialogue" appears in a couple of places. Since we're talking about the 3261 term, I suggest using "dialog" consistently. The sentence (which occurs in the abstract and introduction) "The directionality in traffic legs relates to a SIP request creating a dialogue and stand-alone SIP request." does not parse. What is it trying to say, and why is it important? From nobody Thu Dec 18 13:20:54 2014 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 3159C1A8712 for ; Thu, 18 Dec 2014 13:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIs6e7qfbs3U for ; Thu, 18 Dec 2014 13:20:50 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8A51A7D81 for ; Thu, 18 Dec 2014 13:20:50 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBILKng3049240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 18 Dec 2014 15:20:50 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <5493452C.7060908@nostrum.com> Date: Thu, 18 Dec 2014 15:20:44 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dispatch@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/GA2U3etas8hmajOA4yLxGINY9RQ Subject: [dispatch] Observations on process after reviewing the iotl draft 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, 18 Dec 2014 21:20:52 -0000 All - I just sent in a gen-art LC review on the iotl draft. While putting that review together, I went back through the email discussion of the draft, and when taking it in all at once like that I saw a few things I think we should discuss. First, Christer has worked very hard to do the right thing, and to get the IETF community to do the right thing with this draft. Thank you Christer. Please keep doing that. Our response as a community was underwhelming, and very slow. I don't think we need to beat any individuals up about that, but I do think we have an opportunity to study how this went, so we can do better with other things. There were concerns raised early (last May) about the design (URI parameter vs header field parameter) that I don't think were well resolved on list. When that discussion came up, I think we should have taken it as a flag that this would have benefited from a WG discussing it with a chair driving the discussion. When we decide to send something off to AD sponsorship in the future, the AD should watch for similar conversations and send it back to us (and we should help the AD of the time recognize what's happening). Again, I'm not trying to call what's in this document into question at this point. I just wish we had done better back in May. Much of the discussion danced around URI parameters requiring standards-track, and header parameters only requiring informational, rather than which of those things (or something else) might have the most technical merit (and based on the conversation, there were implementors vested in the choice that had been made before the draft came here). As we've often seen, this points to bringing the problem here earlier, rather than the solution. It also points out that the current standards-track requirement for URI parameters is probably overkill. I'd like to suggest we change that to specification required with expert review. The expert would not allow parameters that changed the semantics of the protocol unless the specification happened to be an IETF stream standards track document. It was an interesting experiment using the dispatch list to refine the document's technical content. In my opinion, we should not do that again. RjS From nobody Thu Dec 18 14:46:45 2014 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 C7AA51A8795 for ; Thu, 18 Dec 2014 14:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6YAIH2vAPPo for ; Thu, 18 Dec 2014 14:46:41 -0800 (PST) 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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1ABA1A008D for ; Thu, 18 Dec 2014 14:46:41 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-05v.sys.comcast.net with comcast id VAmg1p0022Udklx01Amgg0; Thu, 18 Dec 2014 22:46:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-18v.sys.comcast.net with comcast id VAmg1p0023Ge9ey01Amg67; Thu, 18 Dec 2014 22:46:40 +0000 Message-ID: <5493594F.602@alum.mit.edu> Date: Thu, 18 Dec 2014 17:46:39 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <54934283.5090905@nostrum.com> In-Reply-To: <54934283.5090905@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418942800; bh=FFxN4CfFEa2lT8NfQ4w0wFZ2lJg5X/zLSVafPjbcyvs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lHb6mBfn3sesvTw3djk2rLjT4NPwB5TMSDUCGdf31n1RMsw48F9m0B27AgdJfpCbl gqwuzVD7NaqRIzKINqpNYw1Pp9mHkCqtavX5bTzF7ZUivODZmIPolf95UeT9fvJaIJ cntoLYBzTFXyug4n6CrE/D4Z4eluhsMgZdiL1z/8V6RkK3AFKeR2Tp2OV3OrraKN96 ScKOHYD/KLoSG2QLNJCwyXoBvcjDeR9xIEXMffMs0sdh96/ea1FQikf5PMJdJVXFi7 ZfbdbxaYaPFA0VHCF5GDXDNvowopzji5IGe3PxL5nxqL/0Sgtzde2R89ws2lE02yiJ rlisSndvU7Q0Q== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/bnCY1K9Om3d8vHFEUyxfiJG5jSs Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt 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, 18 Dec 2014 22:46:44 -0000 On 12/18/14 4:09 PM, Robert Sparks wrote: > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-holmberg-dispatch-iotl-03 > Reviewer: Robert Sparks > Review Date: 18-Dec-2014 > IETF LC End Date: 8-Jan-2015 > IESG Telechat date: Not on an upcoming telechat agenda > > Summary: Almost ready for publication as a Proposed Standard but has > issues that need to be addressed > > There are only a few issues to address: > > Major Issue 1: It makes no sense to publish a standards track RFC that > says behavior on general networks is undefined. I've reviewed all of the > list traffic about this document, and I understand how the text that's > currently in the document got there, but it's not the best way to deal > with the concern that caused it to be introduced. The original concern > was that the document didn't provide enough detail to tell what the > presence or absence of the values meant, and whether there was an > associate d change to the semantics of the protocol. While the > description is thin, I think there has been enough shown to know that > the semantics of the protocol are not being changed. > > So, instead, the document should just recognize that devices that don't > implement this specification will do what RFC 3261 requires them to do > with unknown URI parameters: ignore them. This document sufficiently > describes what the values it defines means to elements that _do_ > implement this specification. They provide additional information to > upper layers (ultimately, transaction users as 3261 defines them), and > those upper layers might make forwarding decisions using it, just like > they can use _anything_ at their disposal. The basic semantics of the > SIP protocol are unaffected. > > To resolve this issue, I suggest removing the text that occurs in > several places saying that this is applicable only to 3gpp networks, and > add a short sentence reminding the reader that RFC3261 expects new URI > parameters to be standardized and defines how unknown URI parameters are > handled. My problem with this is that IMO the semantics of traffic legs, and the particular types of traffic legs, is not defined in a way that makes any sense outside of an IMS network. Thanks, Paul > Major Issue 2: The document suggests that implementations violate what > RFC3261 requires them to do. Specifically, it says "An entity that > understands the 'iotl' parameter MUST NOT, from a SIP request, remove > 'iotl' parameters from SIP URIs associated with other entities, unless > the entity has means to determine that the 'iotl' parameter does not > represent a valid traffic leg." RFC3261 requires that MUST NOT, and it > does not allow the "unless" clause. It is not ok for an entity to change > some other entities URIs in, say, Route, Service-Route, Path, and > similar places under any circumstances. > > My suggested resolution is to remove the unless clause, and change the > first part of the sentence to note that this is what 3261 requires. > > Major issue 3: The Security considerations section is incomplete. Please > discuss the ramifications of something maliciously providing an > incorrect value in the parameter. What are the ramifications if someone > does violate protocol and changes or removes a value in transit? > > Minor issue 1: It is unclear where you expect these URIs to occur. I > have a good feel only after reading the list traffic. I suggest you be > explicit in 5.1 that you expect these to be placed in Service-Route and > Path header field values, hence to occur in Route header field values, > and Request-URIs. > > Minor issue 2: Why do you say "This document does not specify the usage > of the 'iotl' parameter within a SIP URI of a Record-Route header field. > Would it create an interoperability problem if someone put one there? > Because if they do, it will end up in Route header fields later. If > that's ok, please strike the sentence. If it's not, then you need to say > MUST NOT place the parameter in URIs in Record-Route header field values. > > Nits/editorial comments: > > Since you are providing an extension point for other values, someone > will ask if you need a registry for those values. I suggest explicitly > saying we are not creating a registry at this time but expect to do so > if the extension point is ever used to head that conversation off. > > "dialogue" appears in a couple of places. Since we're talking about the > 3261 term, I suggest using "dialog" consistently. > > The sentence (which occurs in the abstract and introduction) "The > directionality in traffic legs relates to a SIP request creating a > dialogue and stand-alone SIP request." does not parse. What is it trying > to say, and why is it important? > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Thu Dec 18 15:10:30 2014 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 0210C1A90C2 for ; Thu, 18 Dec 2014 15:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wp5_uT01i0RN for ; Thu, 18 Dec 2014 15:10:25 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 646931A8825 for ; Thu, 18 Dec 2014 15:10:24 -0800 (PST) Received: from xct103cnc.rim.net ([10.65.161.203]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 18 Dec 2014 18:10:08 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT103CNC.rim.net ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.03.0210.002; Thu, 18 Dec 2014 18:10:05 -0500 From: Andrew Allen To: Robert Sparks , "dispatch@ietf.org" Thread-Topic: [dispatch] Observations on process after reviewing the iotl draft Thread-Index: AQHQGwiEb+G/biZV60WpT8/CICl+FJyV9cjw Date: Thu, 18 Dec 2014 23:10:05 +0000 Message-ID: References: <5493452C.7060908@nostrum.com> In-Reply-To: <5493452C.7060908@nostrum.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/HopJXt6IDu95bWo5RovFwMx1NCE Subject: Re: [dispatch] Observations on process after reviewing the iotl draft 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, 18 Dec 2014 23:10:28 -0000 +1 to changing URI parameters registration requirements to only require spe= cification with expert review. I never understood why the bar was so high f= or IANA registration of URI parameters when other things like media feature= tags only require expert review and can have as great if not greater impac= t on the protocol. -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Robert Spark= s Sent: Thursday, December 18, 2014 4:21 PM To: dispatch@ietf.org Subject: [dispatch] Observations on process after reviewing the iotl draft All - I just sent in a gen-art LC review on the iotl draft. While putting that re= view together, I went back through the email discussion of the draft, and w= hen taking it in all at once like that I saw a few things I think we should= discuss. First, Christer has worked very hard to do the right thing, and to get the = IETF community to do the right thing with this draft. Thank you Christer. P= lease keep doing that. Our response as a community was underwhelming, and very slow. I don't think= we need to beat any individuals up about that, but I do think we have an o= pportunity to study how this went, so we can do better with other things. There were concerns raised early (last May) about the design (URI parameter= vs header field parameter) that I don't think were well resolved on list. = When that discussion came up, I think we should have taken it as a flag tha= t this would have benefited from a WG discussing it with a chair driving th= e discussion. When we decide to send something off to AD sponsorship in the= future, the AD should watch for similar conversations and send it back to = us (and we should help the AD of the time recognize what's happening). Agai= n, I'm not trying to call what's in this document into question at this poi= nt. I just wish we had done better back in May. Much of the discussion danced around URI parameters requiring standards-tra= ck, and header parameters only requiring informational, rather than which o= f those things (or something else) might have the most technical merit (and= based on the conversation, there were implementors vested in the choice th= at had been made before the draft came here). As we've often seen, this poi= nts to bringing the problem here earlier, rather than the solution. It also points out that the current standards-track requirement for URI par= ameters is probably overkill. I'd like to suggest we change that to specifi= cation required with expert review. The expert would not allow parameters t= hat changed the semantics of the protocol unless the specification happened= to be an IETF stream standards track document. It was an interesting experiment using the dispatch list to refine the docu= ment's technical content. In my opinion, we should not do that again. RjS _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Dec 18 15:13:48 2014 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 489F31A90EC for ; Thu, 18 Dec 2014 15:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJOONfMcjDw9 for ; Thu, 18 Dec 2014 15:13:44 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E651A90E7 for ; Thu, 18 Dec 2014 15:13:44 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBINDhl5059071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 18 Dec 2014 17:13:44 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54935FA2.6080601@nostrum.com> Date: Thu, 18 Dec 2014 17:13:38 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> In-Reply-To: <5493594F.602@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/A33Wm7ih8me80J1LUVmEg2CuFho Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt 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, 18 Dec 2014 23:13:46 -0000 On 12/18/14 4:46 PM, Paul Kyzivat wrote: > On 12/18/14 4:09 PM, Robert Sparks wrote: >> >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> >> . >> >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: draft-holmberg-dispatch-iotl-03 >> Reviewer: Robert Sparks >> Review Date: 18-Dec-2014 >> IETF LC End Date: 8-Jan-2015 >> IESG Telechat date: Not on an upcoming telechat agenda >> >> Summary: Almost ready for publication as a Proposed Standard but has >> issues that need to be addressed >> >> There are only a few issues to address: >> >> Major Issue 1: It makes no sense to publish a standards track RFC that >> says behavior on general networks is undefined. I've reviewed all of the >> list traffic about this document, and I understand how the text that's >> currently in the document got there, but it's not the best way to deal >> with the concern that caused it to be introduced. The original concern >> was that the document didn't provide enough detail to tell what the >> presence or absence of the values meant, and whether there was an >> associate d change to the semantics of the protocol. While the >> description is thin, I think there has been enough shown to know that >> the semantics of the protocol are not being changed. >> >> So, instead, the document should just recognize that devices that don't >> implement this specification will do what RFC 3261 requires them to do >> with unknown URI parameters: ignore them. This document sufficiently >> describes what the values it defines means to elements that _do_ >> implement this specification. They provide additional information to >> upper layers (ultimately, transaction users as 3261 defines them), and >> those upper layers might make forwarding decisions using it, just like >> they can use _anything_ at their disposal. The basic semantics of the >> SIP protocol are unaffected. >> >> To resolve this issue, I suggest removing the text that occurs in >> several places saying that this is applicable only to 3gpp networks, and >> add a short sentence reminding the reader that RFC3261 expects new URI >> parameters to be standardized and defines how unknown URI parameters are >> handled. > > My problem with this is that IMO the semantics of traffic legs, and > the particular types of traffic legs, is not defined in a way that > makes any sense outside of an IMS network. I understand that, but, really, so what? This does no harm to non-IMS networks. If other relations of hops make sense in some other deployment, they can use the value extension point to say something sensical for that deployment. I think what you're looking it is a version of "the things that know and care about this thing are the things that know and care about this thing." > > Thanks, > Paul > >> Major Issue 2: The document suggests that implementations violate what >> RFC3261 requires them to do. Specifically, it says "An entity that >> understands the 'iotl' parameter MUST NOT, from a SIP request, remove >> 'iotl' parameters from SIP URIs associated with other entities, unless >> the entity has means to determine that the 'iotl' parameter does not >> represent a valid traffic leg." RFC3261 requires that MUST NOT, and it >> does not allow the "unless" clause. It is not ok for an entity to change >> some other entities URIs in, say, Route, Service-Route, Path, and >> similar places under any circumstances. >> >> My suggested resolution is to remove the unless clause, and change the >> first part of the sentence to note that this is what 3261 requires. >> >> Major issue 3: The Security considerations section is incomplete. Please >> discuss the ramifications of something maliciously providing an >> incorrect value in the parameter. What are the ramifications if someone >> does violate protocol and changes or removes a value in transit? >> >> Minor issue 1: It is unclear where you expect these URIs to occur. I >> have a good feel only after reading the list traffic. I suggest you be >> explicit in 5.1 that you expect these to be placed in Service-Route and >> Path header field values, hence to occur in Route header field values, >> and Request-URIs. >> >> Minor issue 2: Why do you say "This document does not specify the usage >> of the 'iotl' parameter within a SIP URI of a Record-Route header field. >> Would it create an interoperability problem if someone put one there? >> Because if they do, it will end up in Route header fields later. If >> that's ok, please strike the sentence. If it's not, then you need to say >> MUST NOT place the parameter in URIs in Record-Route header field >> values. >> >> Nits/editorial comments: >> >> Since you are providing an extension point for other values, someone >> will ask if you need a registry for those values. I suggest explicitly >> saying we are not creating a registry at this time but expect to do so >> if the extension point is ever used to head that conversation off. >> >> "dialogue" appears in a couple of places. Since we're talking about the >> 3261 term, I suggest using "dialog" consistently. >> >> The sentence (which occurs in the abstract and introduction) "The >> directionality in traffic legs relates to a SIP request creating a >> dialogue and stand-alone SIP request." does not parse. What is it trying >> to say, and why is it important? >> >> _______________________________________________ >> 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 Dec 19 05:39:49 2014 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 A363C1A894C for ; Fri, 19 Dec 2014 05:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlzQb6Xh8FKC for ; Fri, 19 Dec 2014 05:39:45 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903E61A8875 for ; Fri, 19 Dec 2014 05:39:44 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-54-54942a9e173d Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3D.88.24955.E9A24945; Fri, 19 Dec 2014 14:39:42 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 14:39:41 +0100 From: Christer Holmberg To: Robert Sparks , "dispatch@ietf.org" Thread-Topic: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt Thread-Index: AQHQGwb53ofl7MuT60KWnMJ4/zU9oJyV4iaAgAAHigCAAP6eAA== Date: Fri, 19 Dec 2014 13:39:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D60C4BB@ESESSMB209.ericsson.se> References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> In-Reply-To: <54935FA2.6080601@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje48rSkhBhNapC2WTlrAanFtTiOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJXRdm4Oe8F06Yp7fT/YGxgbxLoYOTkkBEwk vk3sZoSwxSQu3FvP1sXIxSEkcIRRYsEGGGcJo8T6G9tYuxg5ONgELCS6/2mDNIgIBEtcatjE AmILC/hKTD6/kwWkREQgQOL663oI00li4R0ukAoWAVWJ+a+nsoHYvEDVO6fNZAaxhQTSJX71 /GIHsTkFtCUmvrkNZjMCnfP91BomEJtZQFzi1pP5TBBnCkgs2XOeGcIWlXj5+B8rhK0ocXX6 cqh6HYkFuz+xQdjaEssWvmaG2CsocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGIULU4tTspN NzLWSy3KTC4uzs/Ty0st2cQIjJGDW36r7mC8/MbxEKMAB6MSD++GKZNDhFgTy4orcw8xSnOw KInzLjw3Lxjo3cSS1OzU1ILUovii0pzU4kOMTBycUg2M8abfdLLXcucL33t5foWX4M9lm+44 RWyvNwzZYR0z763jdz+fH8yLf+8WM2m9/F8jMHhGvEtdacBNxfNXLbJ2vFZWrTq0ofb290/i rtvbVhopFkQyBfzfvOwZ021Vs9hj9ZuZ8sxzmy6trCrpDGiZfJHT5NlaS5Wzz7cVfhc+c3tS Qsbun2nnlViKMxINtZiLihMB43kTJnICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/iCpFx_9_JUmY0unlUZQbVo8OK2A Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt 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, 19 Dec 2014 13:39:47 -0000 Hi, Afaik, one of the reasons we chose to progress the draft as AD sponsored wa= s because of the 3GPP scope. Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Robert Spark= s Sent: 19. joulukuuta 2014 1:14 To: dispatch@ietf.org Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.t= xt On 12/18/14 4:46 PM, Paul Kyzivat wrote: > On 12/18/14 4:09 PM, Robert Sparks wrote: >> >> I am the assigned Gen-ART reviewer for this draft. For background on=20 >> Gen-ART, please see the FAQ at >> >> . >> >> Please resolve these comments along with any other Last Call comments=20 >> you may receive. >> >> Document: draft-holmberg-dispatch-iotl-03 >> Reviewer: Robert Sparks >> Review Date: 18-Dec-2014 >> IETF LC End Date: 8-Jan-2015 >> IESG Telechat date: Not on an upcoming telechat agenda >> >> Summary: Almost ready for publication as a Proposed Standard but has=20 >> issues that need to be addressed >> >> There are only a few issues to address: >> >> Major Issue 1: It makes no sense to publish a standards track RFC=20 >> that says behavior on general networks is undefined. I've reviewed=20 >> all of the list traffic about this document, and I understand how the=20 >> text that's currently in the document got there, but it's not the=20 >> best way to deal with the concern that caused it to be introduced.=20 >> The original concern was that the document didn't provide enough=20 >> detail to tell what the presence or absence of the values meant, and=20 >> whether there was an associate d change to the semantics of the=20 >> protocol. While the description is thin, I think there has been=20 >> enough shown to know that the semantics of the protocol are not being ch= anged. >> >> So, instead, the document should just recognize that devices that=20 >> don't implement this specification will do what RFC 3261 requires=20 >> them to do with unknown URI parameters: ignore them. This document=20 >> sufficiently describes what the values it defines means to elements=20 >> that _do_ implement this specification. They provide additional=20 >> information to upper layers (ultimately, transaction users as 3261=20 >> defines them), and those upper layers might make forwarding decisions=20 >> using it, just like they can use _anything_ at their disposal. The=20 >> basic semantics of the SIP protocol are unaffected. >> >> To resolve this issue, I suggest removing the text that occurs in=20 >> several places saying that this is applicable only to 3gpp networks,=20 >> and add a short sentence reminding the reader that RFC3261 expects=20 >> new URI parameters to be standardized and defines how unknown URI=20 >> parameters are handled. > > My problem with this is that IMO the semantics of traffic legs, and=20 > the particular types of traffic legs, is not defined in a way that=20 > makes any sense outside of an IMS network. I understand that, but, really, so what? This does no harm to non-IMS netwo= rks. If other relations of hops make sense in some other deployment, they can us= e the value extension point to say something sensical for that deployment. I think what you're looking it is a version of "the things that know and ca= re about this thing are the things that know and care about this thing." > > Thanks, > Paul > From nobody Fri Dec 19 05:42:51 2014 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 128061ACC83 for ; Fri, 19 Dec 2014 05:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cO9Bhztt1XSH for ; Fri, 19 Dec 2014 05:42:48 -0800 (PST) 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 033071AC42E for ; Fri, 19 Dec 2014 05:42:47 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-11-54942b55cadb Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AA.2C.04076.55B24945; Fri, 19 Dec 2014 14:42:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 14:42:45 +0100 From: Christer Holmberg To: Robert Sparks , "dispatch@ietf.org" Thread-Topic: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt Thread-Index: AQHQGwb53ofl7MuT60KWnMJ4/zU9oJyV4iaAgAAHigCAAP6eAIAABKsA Date: Fri, 19 Dec 2014 13:42:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D60C508@ESESSMB209.ericsson.se> References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C4BB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D60C4BB@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+JvjW6o9pQQg60zrS2WTlrAanFtTiOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJWxcXNZwW/5isbHTWwNjE1SXYycHBICJhLH n89mgrDFJC7cW88GYgsJHGGUmNQLZHMB2UsYJe5c7gQq4uBgE7CQ6P6nDVIjIhAscalhEwuI LSzgKzH5/E4WkBIRgQCJ66/rIUrcJO7uW8UOYrMIqErcOvCJHaSEF6h8+dxgiOmrGSVWPO1g BqnhFPCTOLruHNhIRqBzvp9aA3Yas4C4xK0n86HOFJBYsuc8M4QtKvHy8T9WCFtR4ur05VD1 OhILdn9ig7C1JZYtfA1WzysgKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFC1OLS7OTTcy 0kstykwuLs7P08tLLdnECIyQg1t+W+1gPPjc8RCjAAejEg/vhimTQ4RYE8uKK3MPMUpzsCiJ 8y48Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2OX+f2Jxi9WZKgum6j5KHzn9dSekx/f WHTJ+nUZFDqf3sTENUHl1s0HvYnvphy07GBOCVrgaqSh0HO6oEjGS/vBcb2QaFYb9aud5+c8 i1bU+3qJsSGjgzc9O97iBv8Mi/nyp7/JMVrJ+r5ZUfe+ouPL5tzSnICFTFc5L9z0EhF5dDbg iuj1x0osxRmJhlrMRcWJAOt4XIFxAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/CZGRG8PPGSROJt51xsT-4hkHamc Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt 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, 19 Dec 2014 13:42:50 -0000 Hi, Having said that, I can in any case add a sentence, as suggested by Robert,= clarifying that SIP entities that do not support the uri parameter will si= mply ignore it. Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Hol= mberg Sent: 19. joulukuuta 2014 15:40 To: Robert Sparks; dispatch@ietf.org Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.t= xt Hi, Afaik, one of the reasons we chose to progress the draft as AD sponsored wa= s because of the 3GPP scope. Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Robert Spark= s Sent: 19. joulukuuta 2014 1:14 To: dispatch@ietf.org Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.t= xt On 12/18/14 4:46 PM, Paul Kyzivat wrote: > On 12/18/14 4:09 PM, Robert Sparks wrote: >> >> I am the assigned Gen-ART reviewer for this draft. For background on=20 >> Gen-ART, please see the FAQ at >> >> . >> >> Please resolve these comments along with any other Last Call comments=20 >> you may receive. >> >> Document: draft-holmberg-dispatch-iotl-03 >> Reviewer: Robert Sparks >> Review Date: 18-Dec-2014 >> IETF LC End Date: 8-Jan-2015 >> IESG Telechat date: Not on an upcoming telechat agenda >> >> Summary: Almost ready for publication as a Proposed Standard but has=20 >> issues that need to be addressed >> >> There are only a few issues to address: >> >> Major Issue 1: It makes no sense to publish a standards track RFC=20 >> that says behavior on general networks is undefined. I've reviewed=20 >> all of the list traffic about this document, and I understand how the=20 >> text that's currently in the document got there, but it's not the=20 >> best way to deal with the concern that caused it to be introduced. >> The original concern was that the document didn't provide enough=20 >> detail to tell what the presence or absence of the values meant, and=20 >> whether there was an associate d change to the semantics of the=20 >> protocol. While the description is thin, I think there has been=20 >> enough shown to know that the semantics of the protocol are not being ch= anged. >> >> So, instead, the document should just recognize that devices that=20 >> don't implement this specification will do what RFC 3261 requires=20 >> them to do with unknown URI parameters: ignore them. This document=20 >> sufficiently describes what the values it defines means to elements=20 >> that _do_ implement this specification. They provide additional=20 >> information to upper layers (ultimately, transaction users as 3261=20 >> defines them), and those upper layers might make forwarding decisions=20 >> using it, just like they can use _anything_ at their disposal. The=20 >> basic semantics of the SIP protocol are unaffected. >> >> To resolve this issue, I suggest removing the text that occurs in=20 >> several places saying that this is applicable only to 3gpp networks,=20 >> and add a short sentence reminding the reader that RFC3261 expects=20 >> new URI parameters to be standardized and defines how unknown URI=20 >> parameters are handled. > > My problem with this is that IMO the semantics of traffic legs, and=20 > the particular types of traffic legs, is not defined in a way that=20 > makes any sense outside of an IMS network. I understand that, but, really, so what? This does no harm to non-IMS netwo= rks. If other relations of hops make sense in some other deployment, they can us= e the value extension point to say something sensical for that deployment. I think what you're looking it is a version of "the things that know and ca= re about this thing are the things that know and care about this thing." > > Thanks, > Paul > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri Dec 19 07:56:00 2014 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 9E7421A8A43 for ; Fri, 19 Dec 2014 07:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5YMOTx8nUzr for ; Fri, 19 Dec 2014 07:55:50 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD901A8A4A for ; Fri, 19 Dec 2014 07:55:48 -0800 (PST) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-11v.sys.comcast.net with comcast id VTuT1p00C2PT3Qt01TvofB; Fri, 19 Dec 2014 15:55:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-14v.sys.comcast.net with comcast id VTvn1p00U3Ge9ey01TvnCq; Fri, 19 Dec 2014 15:55:48 +0000 Message-ID: <54944A83.3070400@alum.mit.edu> Date: Fri, 19 Dec 2014 10:55:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <5493452C.7060908@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1419004548; bh=gYt3dYgAkwPKMgk/stJG53zbil/mdNJ2TvHY/ywIoZU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kwoGOsYxxdi+NcDaS2dBpTp+7isVoEIhcQyT/x5URiNhM+nmtEFA/gIKtg8tqU98H oA9n2+urE/re946axgb3V6ZAv8MbwH/xYN2AEO63Lk7nCExU8Uv1cXk3oA9Il/WUkg 25iSgXiT7Rc8DugZeGquTRHjmXKcybYGw4CHDQY41/pLat5yk3J69TgJ94YdEJ/4vL +GgZDKTOdNGSThwa+6iLAB43m0IlV0V8YLcH3two65eSdirXkNe+r1xLvBC8gUzXjg si7cI8OLQAEchyhVWHTDdYrBSPidOigNMlvpDZlHmBDutcSDZkY/UvK3kkzxfRON80 YfE02gfi+Zl8g== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/8QrsTjp4HrfsR24jCz-sGxWhlzU Subject: Re: [dispatch] Observations on process after reviewing the iotl draft 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, 19 Dec 2014 15:55:53 -0000 On 12/18/14 6:10 PM, Andrew Allen wrote: > +1 to changing URI parameters registration requirements to only require specification with expert review. I never understood why the bar was so high for IANA registration of URI parameters when other things like media feature tags only require expert review and can have as great if not greater impact on the protocol. I think this could work. The key, which we usually don't do well, is to specify clear criteria for the expert to use when evaluating a new parameter. Thanks, Paul > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Robert Sparks > Sent: Thursday, December 18, 2014 4:21 PM > To: dispatch@ietf.org > Subject: [dispatch] Observations on process after reviewing the iotl draft > > All - > > I just sent in a gen-art LC review on the iotl draft. While putting that review together, I went back through the email discussion of the draft, and when taking it in all at once like that I saw a few things I think we should discuss. > > First, Christer has worked very hard to do the right thing, and to get the IETF community to do the right thing with this draft. Thank you Christer. Please keep doing that. > > Our response as a community was underwhelming, and very slow. I don't think we need to beat any individuals up about that, but I do think we have an opportunity to study how this went, so we can do better with other things. > > There were concerns raised early (last May) about the design (URI parameter vs header field parameter) that I don't think were well resolved on list. When that discussion came up, I think we should have taken it as a flag that this would have benefited from a WG discussing it with a chair driving the discussion. When we decide to send something off to AD sponsorship in the future, the AD should watch for similar conversations and send it back to us (and we should help the AD of the time recognize what's happening). Again, I'm not trying to call what's in this document into question at this point. I just wish we had done better back in May. > > Much of the discussion danced around URI parameters requiring standards-track, and header parameters only requiring informational, rather than which of those things (or something else) might have the most technical merit (and based on the conversation, there were implementors vested in the choice that had been made before the draft came here). As we've often seen, this points to bringing the problem here earlier, rather than the solution. > > It also points out that the current standards-track requirement for URI parameters is probably overkill. I'd like to suggest we change that to specification required with expert review. The expert would not allow parameters that changed the semantics of the protocol unless the specification happened to be an IETF stream standards track document. > > It was an interesting experiment using the dispatch list to refine the document's technical content. In my opinion, we should not do that again. > > RjS > > > _______________________________________________ > 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 Dec 19 08:22:53 2014 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 078481A89A8 for ; Fri, 19 Dec 2014 08:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fldlf808xVSQ for ; Fri, 19 Dec 2014 08:22:48 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B401A879C for ; Fri, 19 Dec 2014 08:22:48 -0800 (PST) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-06v.sys.comcast.net with comcast id VUNb1p00927uzMh01UNn7t; Fri, 19 Dec 2014 16:22:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-02v.sys.comcast.net with comcast id VUNn1p00B3Ge9ey01UNn6l; Fri, 19 Dec 2014 16:22:47 +0000 Message-ID: <549450D7.6010800@alum.mit.edu> Date: Fri, 19 Dec 2014 11:22:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> In-Reply-To: <54935FA2.6080601@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1419006167; bh=e9wxmtr2eWbGDLNk+NmBiRlIiXNFL7IM+hss9XBT3+0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ba7bMHTBUmhMubkwUTEBnBJB68oHWzXBwdi0CBnZNN8LPtOqJuQvXSymE3I6oRThX 289Fzay2RqOIwSyBlqkJxxatsUiz9vYnKvXLfnfjgXPd8bSIV2FNy7vJtvgju1GIzk 7r0UQpI4Dn025nMMdhF+fzEXii1+Kh+umcVYsGe9ndjF/ZfVST8DpJ+J+ZPpht27vV uQ8j/AcrJWMizLgDXSMP/MiSnBmaXM0WYOf3SnPA+QP1kW6yUe3QoPwWsdxdSRtlGA Vjg3a24PkcrvlGeM8AWtXjXR3SbDg+VIEZltRBSi7GpqxI/lFo+1tZ+enPE+rTRM9s E5TBJo85EEf4A== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/KoMueiHYUnAFdiKrAAM6DPHqQoU Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt 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, 19 Dec 2014 16:22:51 -0000 On 12/18/14 6:13 PM, Robert Sparks wrote: >>> Major Issue 1: It makes no sense to publish a standards track RFC that >>> says behavior on general networks is undefined. I've reviewed all of the >>> list traffic about this document, and I understand how the text that's >>> currently in the document got there, but it's not the best way to deal >>> with the concern that caused it to be introduced. The original concern >>> was that the document didn't provide enough detail to tell what the >>> presence or absence of the values meant, and whether there was an >>> associate d change to the semantics of the protocol. While the >>> description is thin, I think there has been enough shown to know that >>> the semantics of the protocol are not being changed. >>> >>> So, instead, the document should just recognize that devices that don't >>> implement this specification will do what RFC 3261 requires them to do >>> with unknown URI parameters: ignore them. This document sufficiently >>> describes what the values it defines means to elements that _do_ >>> implement this specification. They provide additional information to >>> upper layers (ultimately, transaction users as 3261 defines them), and >>> those upper layers might make forwarding decisions using it, just like >>> they can use _anything_ at their disposal. The basic semantics of the >>> SIP protocol are unaffected. >>> >>> To resolve this issue, I suggest removing the text that occurs in >>> several places saying that this is applicable only to 3gpp networks, and >>> add a short sentence reminding the reader that RFC3261 expects new URI >>> parameters to be standardized and defines how unknown URI parameters are >>> handled. >> >> My problem with this is that IMO the semantics of traffic legs, and >> the particular types of traffic legs, is not defined in a way that >> makes any sense outside of an IMS network. > I understand that, but, really, so what? This does no harm to non-IMS > networks. > If other relations of hops make sense in some other deployment, they can > use the value extension point to say something sensical for that > deployment. > I think what you're looking it is a version of "the things that know and > care about this thing are the things that know and care about this thing." My concern is that this smells like a do-what-I-mean thing - syntax without semantics. I especially could not understand when it would make sense to define new traffic leg types. Could the new types coexist in the same call, or the same network, with the existing ones? Or must you define new *collections* of traffic leg types that work with one another? ISTM that traffic leg transitions ought to constitute a sort of state machine. But Christer didn't think so. I can live with this state of affairs while the scope is limited to IMS. But if it is opened up then I think those issues need to be sorted out. But nobody outside the IMS community could see a use for this, so there was no interest in doing to work to define it more generally. Thanks, Paul From nobody Fri Dec 19 09:22:44 2014 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 CB25E1A8AB2 for ; Fri, 19 Dec 2014 09:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGPVOHjQfMrP for ; Fri, 19 Dec 2014 09:22:25 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5CD81A1B83 for ; Fri, 19 Dec 2014 09:22:24 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id BE9DCC1303; Fri, 19 Dec 2014 18:22:22 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id A7ED3C808D; Fri, 19 Dec 2014 18:22:22 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Fri, 19 Dec 2014 18:22:22 +0100 From: To: =?iso-8859-1?Q?J=F6rgen_Axell?= , "dispatch@ietf.org" Thread-Topic: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 Thread-Index: AQHQEJSIGydbZasT4UWtnWTOSslfmJyVgKqAgAEvlAA= Date: Fri, 19 Dec 2014 17:22:22 +0000 Message-ID: <13909_1419009742_54945ECE_13909_7457_1_8B970F90C584EA4E97D5BAAC9172DBB8142CA97F@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <15139_1417707803_5480811A_15139_368_1_8B970F90C584EA4E97D5BAAC9172DBB8142C6B0F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <1E97FFD1485F1142BC075FF145A53A1E043D532D@A04067.BGC.NET> <14147_1417788307_5481BB93_14147_9260_1_8B970F90C584EA4E97D5BAAC9172DBB8142C7104@PEXCVZYM12.corporate.adroot.infra.ftgroup> <5AEA7B339C0B944BB33A6939249264AD1A203ACD@ESESSMB305.ericsson.se> In-Reply-To: <5AEA7B339C0B944BB33A6939249264AD1A203ACD@ESESSMB305.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB8142CA97FPEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.19.123921 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/uVfCAFJcU6PtTjXrBfOkls5X4AE Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 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, 19 Dec 2014 17:22:41 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB8142CA97FPEXCVZYM12corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi J=F6rgen, Many thanks for your review. I already saw some of your comments (eg. 480 i= nstead of 380) and I will take them into account in the draft update. Concerning the following point: >Section 3: "mp" tag seems to be a pre-requisite for the "cause" SIP URI pa= rameter. Is this always true? Can't the number translation be seen as a rep= lacement of the dialled number without changing the target user? It sounds like a pending discussion we have in sipcore and indeed (I think = we agree on that) we need to have this discussion and take the opportunity = to provide clear statements concerning the History-Info header usage for th= e use case this draft is trying to solve. Writing the draft, I chosen not to provide a complete call-flow in the exam= ple because of this weakness in RFC7044 I wanted to discuss before. We have 3 possible solutions, the choice we will make, will impact the hi-t= arget-param inserted in the History-info header by entities defined by this= new draft: 1) The service access number translation is considered as a replacement of = the dialed number (as an alias) without changing the target user (the conta= cted service) =3D> In the hi-targeted-to entry: use of the "rc" param (+new= index level ".1" and cause=3D"380") 2) The service access number translation is considered as a retargeting (ne= w target user) =3D> In the hi-targeted-to entry: use of the "mp" param (+ne= w index level ".1" and cause=3D"380") 3) Nothing is stated in the draft and both can be possible depending on the= implementor's interpretation...except if 3GPP decide to make a choice betw= een 1 and 2 afterward. ;-) My first thought was option 1) but my first action has been to check in RFC= 7131 and in section 3.11 (Toll-Free Number) it is option 2) that has been r= etained. >From RFC7131: To find the service number, the UAS can extract the hi-entry whose index matches the value of the first hi-entry with an "mp" tag. Technically, the call can be forwarded to these "special" numbers from non-special numbers; however, that is uncommon based on the way these services authorize translations. On the other hand, in the same example it is mentioned the following: In the telephone network, toll-free numbers are just aliases to actual numbers that are used for routing of the call. Regarding RFC7044, for aliases it is more "rc" to be used... Finally, my idea is more to choose option 2) only to be consistent with the= example in RFC7131. I would like to have people thought about this point to move forward and ha= ve a clear statement in this draft to avoid any further ambiguity and imple= mentation troubles. Best Regards, Marianne De : J=F6rgen Axell [mailto:jorgen.axell@ericsson.com] Envoy=E9 : jeudi 18 d=E9cembre 2014 16:43 =C0 : MOHALI Marianne IMT/OLN; dispatch@ietf.org Objet : RE: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 Bonjour Marianne, I believe this is a useful case and Ihave some minor comments: Please be consistent in specifying that it is the "cause" URI parameter (or= SIP URI parameter). The confusion with the "cause" in Reason headers is we= ll-known. Section 2: " URIs that are issued form a retargeting" from a retargeting? Section 3: "mp" tag seems to be a pre-requisite for the "cause" SIP URI par= ameter. Is this always true? Can't the number translation be seen as a repl= acement of the dialled number without changing the target user? In section 3 you change to cause-param and target-param instead of "cause" = SIP URI... Section 4 hte-->the Section 5: " new value for the "cause" parameter: 480" I thought 380 ;-), 4= 80 is deflection immediate response. Regards, J=F6rgen From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of marianne.moh= ali@orange.com Sent: 05 December 2014 15:05 To: VAN GEEL Jan (SPC/CSP); dispatch@ietf.org Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-number-= 00 Hi Jan, It is right, I saw it after submitted the draft. I will correct it for the next version. Thank you, Kind Regards, Marianne De : VAN GEEL Jan (SPC/CSP) [mailto:jan.van.geel@proximus.com] Envoy=E9 : vendredi 5 d=E9cembre 2014 07:47 =C0 : MOHALI Marianne IMT/OLN; dispatch@ietf.org Objet : RE: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 Marianne, My only comment is an editorial one: "tool free service" should be "toll fr= ee service" Kind regards Jan Van Geel IT and Network Specialist Belgacom CIS/SCC/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of marianne.moh= ali@orange.com Sent: Thursday 4 December 2014 16:43 To: dispatch@ietf.org Subject: [dispatch] New draft-mohali-dispatch-cause-for-service-number-00 Hi, I re-send my fist email with the correct draft title as subject. I already plan to improve the text of the draft by defining a clear definit= ion with a new wording to describe the scope of usage of the new cause URI = parameter value. This new vocabulary could be something like "service access number translat= ion" with a definition that will be somewhere between a retargeting while t= he target user remain the same and a redirection to a new target. Indeed, f= or premium/toll-free services users are trying to contact a service which i= s the target service and not a particular user behind a UA as a "target use= r" as defined in RFC7044. The service access number could be seen as a supe= r-alias pointing out to a set of UAs and a UAs could be pointed out by seve= ral service access numbers. Comments and review are still welcome. BR, Marianne ------ This draft defines a new value for the SIP URI parameter "cause", which can= be used to associate a SIP URI to a service access number that has been tr= anslated by a specific application. Abstract: RFC4458 defines a "cause" URI parameter as having predefined values for Red= irecting reasons as a mapping from ITU-T Q.732.2-5 Redirecting Reasons. Th= e "cause" URI parameter is to be used in SIP or SIPs URI. In particular, it= may appear in the History-Info header defined in RFC7044 that must be adde= d in retargeted requests. This specification creates a new predefined value= for cases when the retargeting is caused by a specific service action lead= ing to a called number translation. This document updates RFC4458. This draft is needed for 3GPP, but we've tried to write it in a way so that= it can also be applied to other environments. A first version of the draft can be seen under: http://www.ietf.org/internet-drafts/draft-mohali-dispatch-cause-for-service= -number-00.txt This version is a very first version and for sure needs improvement. Your comments are welcome. Regards, Marianne Mohali ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ________________________________ ***** Disclaimer ***** http://www.proximus.be/maildisclaimer ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8B970F90C584EA4E97D5BAAC9172DBB8142CA97FPEXCVZYM12corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi J=F6rgen,

 

Many thanks fo= r your review. I already saw some of your comments (eg. 480 instead of 380)= and I will take them into account in the draft update.

 

Concerning the= following point:

>Section 3: "mp" tag seems to be a =
pre-requisite for the "cause" SIP URI parameter. Is this always t=
rue? Can't the number translation be seen as a replacement of the dialled n=
umber without changing the target user?

 

It sounds like= a pending discussion we have in sipcore and indeed (I think we agree on th= at) we need to have this discussion and take the opportunity to provide clear statements concerning the History-Info header usage for t= he use case this draft is trying to solve.

Writing the dr= aft, I chosen not to provide a complete call-flow in the example because of= this weakness in RFC7044 I wanted to discuss before.

 

We have 3 poss= ible solutions, the choice we will make, will impact the hi-target-param in= serted in the History-info header by entities defined by this new draft:  

1) The service= access number translation is considered as a replacement of the dialed num= ber (as an alias) without changing the target user (the contacted service) =3D> In the hi-targeted-to entry: use of the "rc" pa= ram (+new index level ".1" and cause=3D"380")<= /o:p>

2) The service= access number translation is considered as a retargeting (new target user)= =3D> In the hi-targeted-to entry: use of the "mp" param (+= ;new index level ".1" and cause=3D"380")<= /p>

3) Nothing is = stated in the draft and both can be possible depending on the implementor&#= 8217;s interpretation…except if 3GPP decide to make a choice between 1 and 2 afterward. ;-)

 

My first thoug= ht was option 1) but my first action has been to check in RFC7131 and in se= ction 3.11 (Toll-Free Number) it is option 2) that has been retained.

 

From RFC7131:<= o:p>

To find the service= number, the UAS can extract the hi-entry whose

   index = matches the value of the first hi-entry with an "mp" tag.

   Techni= cally, the call can be forwarded to these "special" numbers<= /o:p>

   from n= on-special numbers; however, that is uncommon based on the way

   these = services authorize translations.

 

On the other h= and, in the same example it is mentioned the following:

In the telephone ne= twork, toll-free numbers are just aliases to

   actual= numbers that are used for routing of the call.

 

Regarding RFC7= 044, for aliases it is more "rc" to be used…

Finally, my id= ea is more to choose option 2) only to be consistent with the example in RF= C7131.  

 

I would like t= o have people thought about this point to move forward and have a clear sta= tement in this draft to avoid any further ambiguity and implementation troubles.

 

Best Regards,

Marianne<= /o:p>

 

De : J=F6rgen Axell [mailto:jorgen.a= xell@ericsson.com]
Envoy=E9 : jeudi 18 d=E9cembre 2014 16:43
=C0 : MOHALI Marianne IMT/OLN; dispatch@ietf.org
Objet : RE: [dispatch] New draft-mohali-dispatch-cause-for-serv= ice-number-00

 

Bonjour= Marianne,

&n= bsp;

I belie= ve this is a useful case and Ihave some minor comments:

&n= bsp;

Please = be consistent in specifying that it is the "cause" URI parameter = (or SIP URI parameter). The confusion with the "cause" in Reason = headers is well-known.

Section 2: "<=
span lang=3D"EN-GB"> URIs that a=
re issued form a retargeting"=
; from a retargeting?
Section 3: "mp"=
 tag seems to be a pre-requisite for the "cause" SIP URI paramete=
r. Is this always true? Can't the number translation be seen as a replaceme=
nt of the dialled number without changing the target user?
In section 3 you change t=
o cause-param and target-param instead of "cause" SIP URI...=

Section 4 hte-->the
Section 5: "<=
span lang=3D"EN-GB"> new value for the "cause" parameter: 480" I thought 380 ;-), 480 is deflection immed=
iate response.

&n= bsp;

Regards= ,

J=F6rge= n

From:= dispatch [mailto:dispatch-bounces@ietf= .org] On Behalf Of marianne.= mohali@orange.com
Sent: 05 December 2014 15:05
To: VAN GEEL Jan (SPC/CSP); dis= patch@ietf.org
Subject: Re: [dispatch] New draft-mohali-dispatch-cause-for-service-= number-00

 

Hi Jan,

 

It is right, I= saw it after submitted the draft.

I will correct= it for the next version.

 <= o:p>

Thank you,

 <= o:p>

Kind Regards,<= /span>

Marianne

 <= o:p>

De : VAN GEEL Jan (SPC/CSP) [mailto:jan.van.geel@proximus.com]
Envoy=E9 : vendredi 5 d=E9cembre 2014 07:47
=C0 : MOHALI Marianne IMT/OLN; dispatch@ietf.org
Objet : RE: [dispatch] New draft-mohali-dispatch-cause-for-serv= ice-number-00

 

Mariann= e,

 <= /span>

My only= comment is an editorial one: “tool free service” should be = 220;toll free service”

 <= /span>

Kind re= gards

 <= /span>

Jan Van Geel
IT a= nd Network Specialist
Belg= acom CIS/SCC/FVC
Tel:= +32 2 202 1035
Tel:= +32 2 207 9032
Emai= l : jan.van.geel@belgacom.be

 <= /span>

From:= dispatch [mailto:dispatch-bounces@ietf= .org] On Behalf Of marianne.= mohali@orange.com
Sent: Thursday 4 December 2014 16:43
To: dispatch@ietf.org
Subject: [dispatch] New draft-mohali-dispatch-cause-for-service-numb= er-00

 

Hi,<= o:p>

 

I re-send m= y fist email with the correct draft title as subject.

 

I already p= lan to improve the text of the draft by defining a clear definition with a = new wording to describe the scope of usage of the new cause URI parameter value.

This new vo= cabulary could be something like "service access number translation&qu= ot; with a definition that will be somewhere between a retargeting while the target user remain the same and a redirection to a new target. Indeed,= for premium/toll-free services users are trying to contact a service which= is the target service and not a particular user behind a UA as a "tar= get user" as defined in RFC7044. The service access number could be seen as a super-alias pointing out to a set= of UAs and a UAs could be pointed out by several service access numbers.

 

Comments an= d review are still welcome.

 

BR,<= o:p>

Marianne

------

This draft = defines a new value for the SIP URI parameter "cause", which can = be used to associate a SIP URI to a service access number that has been translated by a specific application.

 

Abstract:

RFC4458 def= ines a "cause" URI parameter as having predefined values for Redi= recting reasons as a mapping from ITU-T Q.732.2-5 Redirecting Reasons.  The "cause" URI parameter is to be used in SIP or SIPs URI. In p= articular, it may appear in the History-Info header defined in RFC7044 that= must be added in retargeted requests. This specification creates a new pre= defined value for cases when the retargeting is caused by a specific service action leading to a called number translat= ion. This document updates RFC4458.

 

This draft = is needed for 3GPP, but we’ve tried to write it in a way so that it c= an also be applied to other environments.

 

A first ver= sion of the draft can be seen under:

http://www.ietf.org/internet-drafts/draft-mohali-disp= atch-cause-for-service-number-00.txt

 

This versio= n is a very first version and for sure needs improvement.=

Your commen= ts are welcome.

 

Regards,

Marianne Mo= hali

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s 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 conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout 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 fo=
r messages that have been modified, changed or falsified.=

Thank you.

 


***** Disclaimer *****
http://www.proximus.be/ma= ildisclaimer

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s 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 conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout 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 fo=
r messages that have been modified, changed or falsified.=

Thank you.
______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_8B970F90C584EA4E97D5BAAC9172DBB8142CA97FPEXCVZYM12corpo_-- From nobody Fri Dec 19 11:51:05 2014 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 C74A71ACD92 for ; Fri, 19 Dec 2014 11:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbDGwb7KZXGt for ; Fri, 19 Dec 2014 11:51:01 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451D91A6FFC for ; Fri, 19 Dec 2014 11:51:01 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-5c-549481a26215 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 76.3B.29772.2A184945; Fri, 19 Dec 2014 20:50:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 20:50:58 +0100 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Observations on process after reviewing the iotl draft Thread-Index: AQHQGxfU5ol8/cx2C06fHS8Vsyy2bJyXAY6AgABSinA= Date: Fri, 19 Dec 2014 19:50:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D60E219@ESESSMB209.ericsson.se> References: <5493452C.7060908@nostrum.com> <54944A83.3070400@alum.mit.edu> In-Reply-To: <54944A83.3070400@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje7ixikhBvMuc1ksnbSA1WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGtX0nmAp2yVW8P7STrYHxkUQXIyeHhICJ xNeHb1ggbDGJC/fWs4HYQgJHGCXm/43oYuQCspcwSny9MIe1i5GDg03AQqL7nzZIjYhAsMTB wztZQMLCAgES75v8IMKBEnMP/WWBsK0kLt25BtbJIqAq8XudN0iYV8BX4sb1V8wQ07sZJZ6s m84IkuAU0JGYcPEZmM0IdM73U2uYQGxmAXGJW0/mM0GcKSCxZM95ZghbVOLl43+sELaSxKLb n6HqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsopRtDi1OCk3 3chIL7UoM7m4OD9PLy+1ZBMjMEYObvltsIPx5XPHQ4wCHIxKPLwbpkwOEWJNLCuuzD3EKM3B oiTOu/DcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjFb1vzZy+zFekLXvWL71S+azIxfz biW1GtiFcHyMXrotTCmpSf2cTkKot+q8XftsXe1naBZwPM3iO8yeV1KVd2X/KoEZJmGt61tW 3rkUd2hv6Lqvrgr6fMenPFu9Q2xa4VfJB6k8fib2rksf5c7MNZe31A5hcr50e07NRX6JyqNb /J/NfrOwU4mlOCPRUIu5qDgRAG69pfdyAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/OY1CkhI_gzNNNoF9pZISGPydlkI Subject: Re: [dispatch] Observations on process after reviewing the iotl draft 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, 19 Dec 2014 19:51:04 -0000 +1 Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 19 December 2014 17:56 To: dispatch@ietf.org Subject: Re: [dispatch] Observations on process after reviewing the iotl dr= aft On 12/18/14 6:10 PM, Andrew Allen wrote: > +1 to changing URI parameters registration requirements to only require s= pecification with expert review. I never understood why the bar was so high= for IANA registration of URI parameters when other things like media featu= re tags only require expert review and can have as great if not greater imp= act on the protocol. I think this could work. The key, which we usually don't do well, is to spe= cify clear criteria for the expert to use when evaluating a new parameter. Thanks, Paul > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Robert=20 > Sparks > Sent: Thursday, December 18, 2014 4:21 PM > To: dispatch@ietf.org > Subject: [dispatch] Observations on process after reviewing the iotl=20 > draft > > All - > > I just sent in a gen-art LC review on the iotl draft. While putting that = review together, I went back through the email discussion of the draft, and= when taking it in all at once like that I saw a few things I think we shou= ld discuss. > > First, Christer has worked very hard to do the right thing, and to get th= e IETF community to do the right thing with this draft. Thank you Christer.= Please keep doing that. > > Our response as a community was underwhelming, and very slow. I don't thi= nk we need to beat any individuals up about that, but I do think we have an= opportunity to study how this went, so we can do better with other things. > > There were concerns raised early (last May) about the design (URI paramet= er vs header field parameter) that I don't think were well resolved on list= . When that discussion came up, I think we should have taken it as a flag t= hat this would have benefited from a WG discussing it with a chair driving = the discussion. When we decide to send something off to AD sponsorship in t= he future, the AD should watch for similar conversations and send it back t= o us (and we should help the AD of the time recognize what's happening). Ag= ain, I'm not trying to call what's in this document into question at this p= oint. I just wish we had done better back in May. > > Much of the discussion danced around URI parameters requiring standards-t= rack, and header parameters only requiring informational, rather than which= of those things (or something else) might have the most technical merit (a= nd based on the conversation, there were implementors vested in the choice = that had been made before the draft came here). As we've often seen, this p= oints to bringing the problem here earlier, rather than the solution. > > It also points out that the current standards-track requirement for URI p= arameters is probably overkill. I'd like to suggest we change that to speci= fication required with expert review. The expert would not allow parameters= that changed the semantics of the protocol unless the specification happen= ed to be an IETF stream standards track document. > > It was an interesting experiment using the dispatch list to refine the do= cument's technical content. In my opinion, we should not do that again. > > RjS > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri Dec 19 12:10:43 2014 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 22DB31A7D82 for ; Fri, 19 Dec 2014 12:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tB3Us_SvgNr for ; Fri, 19 Dec 2014 12:10:36 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7DE31A7009 for ; Fri, 19 Dec 2014 12:10:35 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-bb-54948639a4c9 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FC.DC.29772.93684945; Fri, 19 Dec 2014 21:10:33 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 21:10:33 +0100 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt Thread-Index: AQHQGwb53ofl7MuT60KWnMJ4/zU9oJyV4iaAgAAHigCAAR+LgIAASxfQ Date: Fri, 19 Dec 2014 20:10:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D60E2F8@ESESSMB209.ericsson.se> References: <54934283.5090905@nostrum.com> <5493594F.602@alum.mit.edu> <54935FA2.6080601@nostrum.com> <549450D7.6010800@alum.mit.edu> In-Reply-To: <549450D7.6010800@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvja5l25QQg7NLFSyWTlrAarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj+t0OtoLdwhX7V0Y3MO7m72Lk5JAQMJH4 8v0CI4QtJnHh3nq2LkYuDiGBI4wS825fYoJwljBKLNx5F6iKg4NNwEKi+582SIOIQLDEwcM7 WUBsYQFficnnQWwOoHiAxPXX9RAlbhIXjx9hBbFZBFQl9kzrZAaxeYHK97YuZYUY384ocWXa VnaQBKeAjsSW9xvAbEagg76fWsMEYjMLiEvcejKfCeJQAYkle84zQ9iiEi8f/2OFsJUkFt3+ DFWvI7Fg9yc2CFtbYtnC11CLBSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjKLFqcVJuelG RnqpRZnJxcX5eXp5qSWbGIFRcnDLb4MdjC+fOx5iFOBgVOLh3TBlcogQa2JZcWXuIUZpDhYl cd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDcptr52SX3R+ispQWrX/mUTRa14Zrc GvWqqMm5atrfTpPYsHWLCz2/cb/P5ay58PZV8Jk9vUyKoVp3VyobxrzuiNCs19au95q93HSv zI9Pj+0kqudn7Zz0bsajE44ee3cldDpXZ3BPkrPQTdwx4RWr6oSdy+7efu1/zavy5kH1UFa1 g1tEL21SYinOSDTUYi4qTgQARTRTRXMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/tL22Vqc7GfWWOwBQD9qqndGyzwQ Subject: Re: [dispatch] Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt 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, 19 Dec 2014 20:10:41 -0000 Hi, .... >>>> To resolve this issue, I suggest removing the text that occurs in=20 >>>> several places saying that this is applicable only to 3gpp networks,=20 >>>> and add a short sentence reminding the reader that RFC3261 expects=20 >>>> new URI parameters to be standardized and defines how unknown URI=20 >>>> parameters are handled. >>> >>> My problem with this is that IMO the semantics of traffic legs, and=20 >>> the particular types of traffic legs, is not defined in a way that=20 >>> makes any sense outside of an IMS network. >> >> I understand that, but, really, so what? This does no harm to non-IMS=20 >> networks. >> If other relations of hops make sense in some other deployment, they=20 >> can use the value extension point to say something sensical for that=20 >> deployment. >> I think what you're looking it is a version of "the things that know=20 >> and care about this thing are the things that know and care about this t= hing." > > My concern is that this smells like a do-what-I-mean thing - syntax witho= ut semantics. Just to clarify, as I've also said before, in the 3GPP usage there is absol= utely no do-what-I-mean about iotl. The starting entity of a traffic leg ty= pically has no idea, and makes no assumptions, about what/if the ending ent= ity (and/or any mid-traffic leg entity) is going to do with the information= - especially if the traffic leg spans multiple operators. > I especially could not understand when it would make sense to define new = traffic leg types. Could the new types coexist in the same call, or the sam= e network, with the existing ones? Or must you define new > *collections* of traffic leg types that work with one another? > >The only reason I can think of is some completely new call model is define= d. You need to, for the environment where you use iotl, define each traffic= leg for that environment. > > ISTM that traffic leg transitions ought to constitute a sort of state mac= hine. But Christer didn't think so. > > I can live with this state of affairs while the scope is limited to IMS.= =20 > But if it is opened up then I think those issues need to be sorted out.=20 > But nobody outside the IMS community could see a use for this, so there w= as no interest in doing to work to define it more generally. Personally I also think we should keep the current 3GPP scope. We did discu= ss it in DISPATCH, and that was the outcome. Regards, Christer From nobody Fri Dec 19 12:59:20 2014 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 5171F1A7032 for ; Fri, 19 Dec 2014 12:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, 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 5ZrrEzbvzVWT for ; Fri, 19 Dec 2014 12:59:16 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5C11A1BC5 for ; Fri, 19 Dec 2014 12:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=88; q=dns/txt; s=iport; t=1419022756; x=1420232356; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=SCIHl9MgKXUvGIymYSwjrcBhsQUrHE2S5diXl+Tw6uY=; b=h5wnbKrtzeqMlbIMI54pHdZtfNyUrOB7IJ7K7Y3NSJfo6Rjgk3646Op5 S12ubtxoiWRG3bs7nWFeiGb5A7gFEu/2yru8FDWYyRXwGwKp6nBZKlTdW yuOPxNxMWx4kKDNjRGUBayj/SQ1bmBgzsnybXh/mL8kTSTxkAomrRygFz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4FAHiQlFStJA2D/2dsb2JhbABagmQiUho/A4Nrwj2HChYBAQEBAX2EEzpRAT5CJwQciCMBDKsipXQgkw+BEwWODYhykUgig26CNH4BAQE X-IronPort-AV: E=Sophos;i="5.07,608,1413244800"; d="scan'208";a="107058249" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP; 19 Dec 2014 20:59:15 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBJKxE7c029058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 19 Dec 2014 20:59:15 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 14:59:14 -0600 From: "Cullen Jennings (fluffy)" To: IETF Dispatch Thread-Topic: Draft minutes from IETF 91 Thread-Index: AQHQG86lxK89e8eTdEO2geXh8hYjQg== Date: Fri, 19 Dec 2014 20:59:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/444JC29cunRiN9WumpCtQhJoQ5M Subject: [dispatch] Draft minutes from IETF 91 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, 19 Dec 2014 20:59:17 -0000 Can be found at=20 http://www.ietf.org/proceedings/91/minutes/minutes-91-dispatch From nobody Tue Dec 23 13:38:52 2014 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 3EAE11AC39C for ; Tue, 23 Dec 2014 13:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTkfy8zVojIq for ; Tue, 23 Dec 2014 13:38:48 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 174BF1A7032 for ; Tue, 23 Dec 2014 13:38:47 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-10v.sys.comcast.net with comcast id X9dy1p0012JGN3p019en5Z; Tue, 23 Dec 2014 21:38:47 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-10v.sys.comcast.net with comcast id X9em1p00E1KKtkw019emAK; Tue, 23 Dec 2014 21:38:47 +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 sBNLckAe015538; Tue, 23 Dec 2014 16:38:46 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sBNLcjKg015535; Tue, 23 Dec 2014 16:38:45 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Robert Sparks In-Reply-To: <5493452C.7060908@nostrum.com> (rjsparks@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 23 Dec 2014 16:38:45 -0500 Message-ID: <87r3vqhwre.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1419370727; bh=p9QgqjJjx5YNznLBiltGDnHcF58RfbQUUDGmi/RTWUY=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=tHQljcU9F93i/gB03HjTZl1Hw2Sh6+ezFFmR83IFlVQZlFChXLdd10hMT0X8iaoJY e7+SkeK0ZH3JjD2FFMr7dOjhMopc1cBvLlZ0QgLcz6BZhaVStoRYkEWxav0Rem2O50 2kXHnPgRmf2fRYEvz4DMd6ntlNhKCr2Xum1cZg89+/QS55gIAeRGDJAROovipncqRE BstJpGhixUAJJDQD37YZsgIYmGUVKnIZ5L1uzMUeCWCEvkxQgD6VAcCI7webq1uhcw TmIt9GD/i2eYWYQUpGhISR2ZxVG6oLCbZBUpuQ5oqIRWzNh8VjBzCB87q/BnFDn9g8 BI2rAj8q7yVXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/8J38ZypTTgs5EO6nzZZmvBJLWv0 Cc: dispatch@ietf.org Subject: Re: [dispatch] Observations on process after reviewing the iotl draft 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, 23 Dec 2014 21:38:49 -0000 Robert Sparks writes: > Our response as a community was underwhelming, and very slow. I don't > think we need to beat any individuals up about that, but I do think we > have an opportunity to study how this went, so we can do better with > other things. My response was hindered by certain unusual features of this draft, and I suspect that other people were affected in the same way. The mechanism is 3GPP-specific, to the point where people had no idea how it could be generalized to wider use. The need for some mechanism of this nature is clear. The mechanism itself is (IMO) not an entirely proper use of URI parameters -- but there is no better alternative. So I've not opposed the draft, but the circumstances inhibited me from giving it the review it needed. > It also points out that the current standards-track requirement for URI > parameters is probably overkill. I'd like to suggest we change that to > specification required with expert review. The expert would not allow > parameters that changed the semantics of the protocol unless the > specification happened to be an IETF stream standards track document. I agree with that. SIP systems seem to all be organized to ignore any URI parameters that they don't understand. As far as I know, there's no standard that says that, but it seems to be the universal practice. That principle minimizes the risk of malfunction if a URI containing a parameter "leaks" outside of the systems which implement the parameter. That means that we do not have to be deeply careful about introducing new URI parameters. Dale