From nobody Thu May 1 08:17: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 449981A6F77 for ; Thu, 1 May 2014 08:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMzoRqtXR0Ks for ; Thu, 1 May 2014 08:17:01 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCE91A07B3 for ; Thu, 1 May 2014 08:16:59 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-dc-53626569c591 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 4E.30.04199.96562635; Thu, 1 May 2014 17:16:57 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Thu, 1 May 2014 17:16:56 +0200 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAxuudP Date: Thu, 1 May 2014 15:16:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> In-Reply-To: <53612FCC.7000705@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+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvjW5malKwwZN+MYulkxawWqzYcIDV gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4ceosS8F7oYr2xUsZGxj/8XUxcnBICJhI LNso1sXICWSKSVy4t56ti5GLQ0jgKKPEn+63zCAJIYHFjBLt28VB6tkELCS6/2mDhEUEgiUO Ht7JAmILCzhL/Du8gR0i7iKx63M3lO0msfXXMzYQm0VAReLNg89MIDavgK/E/eU9jBC7LjNK nF/zmgVkPqeAjsSCpwogNYxA93w/tQasnllAXOLWk/lMEHcKSCzZc54ZwhaVePn4HyuErSjR /rSBEaIeaMzuT2wQtrbEsoWvmSH2CkqcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGEWLU4uT ctONjPRSizKTi4vz8/TyUks2MQJj5OCW3wY7GF8+dzzEKMDBqMTDW/wlMliINbGsuDL3EKM0 B4uSOO+3s+7BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjzzokWOj5QvcGcepnpoS/Ll/eX mQN+ZR6cPGHn60/a7Kunca2efqPssVuS0NdFDTGKfAVde70a3z1XD3WevlWtSSKeccHifr2N +xnfeSfWz1De65Wz/fV0t4Tf7Nc+f/3H8T5qaffRr8kNxk+6bXPeSnzYxdd3pFI1zkmkPL6O f0Kw4dXktweVWIozEg21mIuKEwH+Rx18cgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/6wBkyzZJIbnez1z6ropnh9TLtgM Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 01 May 2014 15:17:02 -0000 Hi Paul, >>> Then, the description of the parameter says the uri with the parameter = is the *end* of a traffic leg with that name. It says nothing about which n= ode or URI *starts* each leg. >> >> The each value description, the text says between which 3GPP nodes the t= raffic leg spans. There is no need to indicate the *start* in the signaling= . > > There is no need because it is implicit? > Or because it is not needed for the uses you have in mind? Correct. The purpose of the parameter is to inform entities about the traff= ic leg. But, for 3GPP, the value definition implicitly DO provide information betwe= en what types of entities the traffic leg span. >>> If B2BUAs (especially SBCs) are involved, is it important whether the i= otl parameters are preserved e2e? >> >> The iotl parameter only needs to be preserved until it is "consumed" at = the end of the traffic leg. > > That seems to open up another discussion. It is a continuation of the > question I had above who uses the iotl parameter values, and for what. > > When you say that the parameter identifies the end of a leg, and is > consumed at the end of the leg, that implies to me that this serves as a > request that the node identified by the URI perform some action implied > by the iotl value. The node identified by the URI, AND intermediaries on the traffic leg, that= perform actions based on the value. This is NOT a parameter used to request nodes to perform specific actions, = and whatever entities do what the information is outside the scope of the d= ocument. The purpose of the parameter is to inform nodes about the traffic leg, and = whatever (if any) actions taken are based on local/operator policy. > If that is what this is about, then it should be spelled out clearly. The Introduction contains some text, including the following paragraph: "The traffic leg information can be used by intermediary entities to make policy decisions, related to e.g. media anchoring, signalling policy, insertion of media functions (e.g. transcoder) and charging." But, if more text is needed, we can of course add that. However, I don't think we should copy/paste the 3GPP specification into the= draft. The 3GPP specification is available for anyone who wants detailed i= nformation on what actions nodes take in certain scenarios etc. Regards, Christer= From nobody Thu May 1 08:20:46 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 F081F1A0684 for ; Thu, 1 May 2014 08:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 ku4PMoeFanz5 for ; Thu, 1 May 2014 08:20:35 -0700 (PDT) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA6B1A6F7D for ; Thu, 1 May 2014 08:20:35 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Thu, 1 May 2014 08:20:33 -0700 From: Michael Hammer To: "christer.holmberg@ericsson.com" , "pkyzivat@alum.mit.edu" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAjA0EAACAyugAAO9xaAAAuIoOAAA6QCWA= Date: Thu, 1 May 2014 15:20:32 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF7B3E1@EX2K10MB1.corp.yaanatech.com> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.161] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00D1_01CF652F.5CF2FB90" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/PNeOvBD4TuDny3UbmbwT9o2ZHGE Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 01 May 2014 15:20:41 -0000 ------=_NextPart_000_00D1_01CF652F.5CF2FB90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Will the 3GPP spec change if the manifestation of this parameter changes? ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Thursday, May 01, 2014 11:17 AM To: Paul Kyzivat; dispatch@ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Hi Paul, >>> Then, the description of the parameter says the uri with the parameter is the *end* of a traffic leg with that name. It says nothing about which node or URI *starts* each leg. >> >> The each value description, the text says between which 3GPP nodes the traffic leg spans. There is no need to indicate the *start* in the signaling. > > There is no need because it is implicit? > Or because it is not needed for the uses you have in mind? Correct. The purpose of the parameter is to inform entities about the traffic leg. But, for 3GPP, the value definition implicitly DO provide information between what types of entities the traffic leg span. >>> If B2BUAs (especially SBCs) are involved, is it important whether the iotl parameters are preserved e2e? >> >> The iotl parameter only needs to be preserved until it is "consumed" at the end of the traffic leg. > > That seems to open up another discussion. It is a continuation of the > question I had above who uses the iotl parameter values, and for what. > > When you say that the parameter identifies the end of a leg, and is > consumed at the end of the leg, that implies to me that this serves as > a request that the node identified by the URI perform some action > implied by the iotl value. The node identified by the URI, AND intermediaries on the traffic leg, that perform actions based on the value. This is NOT a parameter used to request nodes to perform specific actions, and whatever entities do what the information is outside the scope of the document. The purpose of the parameter is to inform nodes about the traffic leg, and whatever (if any) actions taken are based on local/operator policy. > If that is what this is about, then it should be spelled out clearly. The Introduction contains some text, including the following paragraph: "The traffic leg information can be used by intermediary entities to make policy decisions, related to e.g. media anchoring, signalling policy, insertion of media functions (e.g. transcoder) and charging." But, if more text is needed, we can of course add that. However, I don't think we should copy/paste the 3GPP specification into the draft. The 3GPP specification is available for anyone who wants detailed information on what actions nodes take in certain scenarios etc. Regards, Christer _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_00D1_01CF652F.5CF2FB90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8DCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBmAwggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJ KoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAw MDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFu dGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2Fm TDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNN RNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0aNomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZ BP+gfz+j25FFdmaja/OFI15O2YVddaegFffBAHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6kl QrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gz AgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJLTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9v YIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMp IDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcC ARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5z eW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEFBQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVn Mc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGiSNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlU zd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5sZ8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs 1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAq WDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7eDROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gu d1wnwTkwggdrMIIGU6ADAgECAhAG/Klcm5J55TO42VB6L0Z2MA0GCSqGSIb3DQEBBQUAMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1l ZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE0MDMwNzAwMDAwMFoXDTE2MDMwNjIzNTk1 OVoweTEXMBUGA1UEAwwOTWljaGFlbCBIYW1tZXIxDzANBgNVBAsMBlMvTUlNRTEgMB4GA1UECgwX WWFhbmEgVGVjaG5vbG9naWVzLCBMTEMxKzApBgkqhkiG9w0BCQEWHG1pY2hhZWwuaGFtbWVyQHlh YW5hdGVjaC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDhrIoj3DQK9mYQmnm LZZey2IE3CFgP3uwRoHY3jUUGhoGkiUgBNLpJiZBvHE3LQDs5PTWE/sdZfdmabLzsDX3gk2bRbV1 3NQL0NmUdGjgP+ecdjgsUiZaiL5DwrM5aZajHnRkUyvaK/8YRholSnhdZBLCxDVMM9nziHeuuezB V+fenpY3Qe8NmEKHeYyXX2VSXKyFaQRBG+hW/c4XVxtq55Ja9DoC2yN9HEHT1Dxbp1J7MU8mJxZ2 sqLnuq9w8IIfx6hnP1gxESiylWao3IEYd9fESIVxQ+P3YOOzAvp2+zqwwQnBYGlfFgnohVFbeTP1 bqZ1U9i52w98bmGGypm3AgMBAAGjggOcMIIDmDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF oDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFFaFSmgtcRDwfRFi qt3Vq8LJCLn5MCcGA1UdEQQgMB6BHG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20wHwYDVR0j BBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFxBggrBgEFBQcBAQSCAWMwggFfMCcGCCsGAQUF BzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5jb20wggEyBggrBgEFBQcwAoaCASRsZGFwOi8v ZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUzRCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIw U2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUz RCUyMENsYXNzJTIwMiUyME1hbmFnZWQlMjBQS0klMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUy MENBJTJDT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBT eW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5 MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0 NzdjZjRmNmJlOTZhZjFiMzZjYWJkMzE2L0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgB hvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEF BQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqG SIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUB EAMEHjAcBhJghkgBhvhFARABAgIBAYabp24WBjE4NzIwOTA5BgpghkgBhvhFARAFBCswKQIBABYk YUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQCb gnr/+BTv731e1vnbp5CumpK9um2FK5+6QQRkOknq48NjC4HcluiLkNJZNFc6lNUnDiaPFBGzAMFI FBZ55Io939W3O+q15R9PfXfZ18vkg/eRVr3ejw1jlD4DimLSb9xMtflheEzpTo4PmNBQOcbR6OQs EwrSlWWk6fhnPXHvuF9xJ+wlXKWFqP/BTiKH7i3weq3dcZn83HO4l1XhcxYPv5zSP+lFqCjh9Gu9 2NAvGhtegMbJ82IlM3edN+q8G890bnavQWhk/pO4bEqDKkLOKgr3ir6qZ6/qxhp8m3ADDHTcGv5n l4E9gG8v7NrV5iqBglGQYZoOA8RqKWpjGJMTMYIE+zCCBPcCAQEwgd4wgckxCzAJBgNVBAYTAlVT MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkCEAb8qVybknnlM7jZUHovRnYwCQYFKw4DAhoFAKCCAvEwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNTAxMTUyMDMxWjAjBgkqhkiG 9w0BCQQxFgQUZvjztrEIwQ+gvG6/JJ9It1khfOEwgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgB ZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgIC AIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZI AWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwge8GCSsGAQQBgjcQBDGB4TCB3jCByTEL MAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1h bnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UEAxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJt ZWRpYXRlIENlcnRpZmljYXRlIEF1dGhvcml0eQIQBvypXJuSeeUzuNlQei9GdjCB8QYLKoZIhvcN AQkQAgsxgeGggd4wgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5h Z2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNz IDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEAb8qVybknnlM7jZ UHovRnYwDQYJKoZIhvcNAQEBBQAEggEAgYXSy1E6k80RoPYZFqFStLtAgYiOAU2F88Ln3W8spwIJ nsd14Xof6ev4S1v85gPk98MjJcDqNZmqnyF5LvuH7GwxvjWbZtQw9BH7wjRgMedFX7U7u9Is/G6J YJrBTReKJcM0mZbwpjnygQ9IBrTSTLqCzdkdqPB2ru+8lB8dp3I1nQC+pO2bE4Vn3SiAKQkmK+eP wc0rwUOrZgFRSED37/44rQLN4VZYfjCLM45dsvKzHzWCXIf6Ny/BjxO9a6/GKrnTFyKMAJgBi95y Ez29C8mmbBhcFZAUvd4ijiQ9xTAlyp/rOn6fIRWVkJOkERbNFdeVc36yGBT6VK2tUQzKsQAAAAAA AA== ------=_NextPart_000_00D1_01CF652F.5CF2FB90-- From nobody Thu May 1 08:21: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 A349A1A6F2F for ; Thu, 1 May 2014 08:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NCVxwaHeV-34 for ; Thu, 1 May 2014 08:21:15 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2B51A08ED for ; Thu, 1 May 2014 08:21:14 -0700 (PDT) X-AuditID: c1b4fb3a-f79106d0000013ca-3b-536266670769 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 41.5A.05066.76662635; Thu, 1 May 2014 17:21:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Thu, 1 May 2014 17:21:11 +0200 From: Christer Holmberg To: "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAH73g3ACposi8= Date: Thu, 1 May 2014 15:21:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2E795B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu>, <201404301901.s3UJ1Awf013148@hobgoblin.ariadne.com> In-Reply-To: <201404301901.s3UJ1Awf013148@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjW56WlKwwZRLFhZLJy1gtXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgyth9vp+pYDpfRd+SqgbGBdxdjJwcEgImEs2z n7FC2GISF+6tZ+ti5OIQEjjKKLF+7T9WCGcxo8TRnyeYuhg5ONgELCS6/2mDNIgIhEh8ntbJ CGILCzhL/Du8gR0i7iKx63M3lO0n8WDWK2YQm0VAReL76XNgNq+Ar8SnTXNYIOZ3MknsudfF BpLgFHCQ6Ji2nQnEZgS66PupNWA2s4C4xK0n85kgLhWQWLLnPDOELSrx8vE/qA8UJdqfNjBC 1OtILNj9iQ3C1pZYtvA11GJBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRWjaHFqcXFuupGR XmpRZnJxcX6eXl5qySZGYJQc3PLbagfjweeOhxgFOBiVeHiLv0QGC7EmlhVX5h5ilOZgURLn nbTIPVhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY2yU+JI1mYffWqaxz9J01e+8ufWlj/6N nwdXCXfbnVQ4LBz2Qtiiznr/9iXPZ/N+m2p53isouv9L86OjrHPtj22aXRNt1J06bxcfM8+U m0suHv2Tce/1EnXPpZGhOcuEzGtcfuy5xymmvmVeupT07gNrAw7xyl7sfGA9X2rnQ4/NlXPc rZZyTVdiKc5INNRiLipOBACXqLXPcwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/dpLMeptaTnolaheUnQBzveGGtK8 Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 01 May 2014 15:21:18 -0000 Hi, >As far as I can tell, the draft refers to "signaling path", but it >does not distinguish whether the signaling path is the routing of a >single dialog, or whether it is broken into multiple dialogs by >B2BUAs. I don't think this changes the proposal technologically, but >it should probably be stated explicitly somewhere. It *is* a >requirement of the solution. Sure, we can add text about that. >It seems that the intention is that at any point, a progressing >dialog-establishing or out-of-dialog request is labeled regarding >which call leg it is within by the iotl parameter of the URI currently >used for routing (the topmost Route or the request URI). This is a >bit incorrect categorically, because: > >1. it's not a property of the destination, its a property of the > dialog, or part of the dialog It depends on the traffic leg. Some traffic legs end at the destination. >2. overlooking that, it's not really a property of the URI, its a > modifier of how the URI is *used* I am not really sure what you mean by that. We are not suggesting any chang= es to how URIs are used. The parameter simply provides additional informati= on to the consumer of the URI. >(1) suggests that there should be a separate header to label the >request. But that might be even more complex to define in order to be >able to have a single dialog contain several call legs. > >(2) suggests that the iotl data should not be a URI parameter, but >rather a header parameter. The Route header has header parameters, >but the request-URI doesn't; I suppose the analogous item is the To >header, which does have header parameters. The parameter can, based on the use-case, be used both in the SIP URI of a = Route header, or in the Request-URI. Regards, Christer= From nobody Thu May 1 08:26: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 5BA391A6FAB for ; Thu, 1 May 2014 08:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XcSztyh_xK04 for ; Thu, 1 May 2014 08:26:49 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id E0B841A6F83 for ; Thu, 1 May 2014 08:26:48 -0700 (PDT) X-AuditID: c1b4fb3a-f79106d0000013ca-b2-536267b6be2a Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C6.DA.05066.6B762635; Thu, 1 May 2014 17:26:46 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Thu, 1 May 2014 17:26:45 +0200 From: Christer Holmberg To: Michael Hammer , "pkyzivat@alum.mit.edu" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAxuudP///kPwCAACHtbw== Date: Thu, 1 May 2014 15:26:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2E796D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <00C069FD01E0324C9FFCADF539701DB3BBF7B3E1@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF7B3E1@EX2K10MB1.corp.yaanatech.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje629KRgg1VPFCyWTlrAarFu5TcW ixUbDrA6MHv8ff+ByWPJkp9MHtcP9jAGMEdx2aSk5mSWpRbp2yVwZfzefIC5oE+qYvbKFWwN jD2iXYycHBICJhLdb3awQthiEhfurWfrYuTiEBI4yiix8OpMdghnMaPEqbsrGbsYOTjYBCwk uv9pg8RFBHoZJX6uOsQM0i0s4Czx7/AGdhBbRMBFYtfnbig7TGLTqw9MIL0sAioS7x6lgIR5 BXwl2i9sZISY/4hJoutPJ1g9p0CIxIKmiYwgNiPQRd9PrWECsZkFxCVuPZnPBHGpgMSSPeeZ IWxRiZeP/0F9oCjR/rSBEaJeR2LB7k9sELa2xLKFr5khFgtKnJz5hGUCo+gsJGNnIWmZhaRl FpKWBYwsqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECo+fglt9WOxgPPnc8xCjAwajEw1v8 JTJYiDWxrLgy9xCjNAeLkjjvpEXuwUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYFzb4re5L LXl6UPyUntee49+KNFZebTnH80v9zMlTzc6TmPz3ST74EGT8xT/oiVXPpe4NcZcEmCLeSS7d +C32RSPHke/uBjPfpB4I3vXQUMN2vtsNZfPVSnyyp+pzmXJ1syIjIt+c/P7A8ahAgM9zZR2W Q6c6zEOr7vX2M93ZYHV1394gkT03lViKMxINtZiLihMBwvJdhH8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/hVSYivGrtWuRW3A9c3QDN_9a3zw Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 01 May 2014 15:26:51 -0000 Hi, >Will the 3GPP spec change if the manifestation of this parameter changes? This is needed for the current 3GPP release, and there are requests for thi= s to be implemented, so therefor I hope we can agree on the basics relative= ly fast. We can then always make sure we have enough text, clarifications etc in the= draft. Regards, Christer ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Thursday, May 01, 2014 11:17 AM To: Paul Kyzivat; dispatch@ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Hi Paul, >>> Then, the description of the parameter says the uri with the parameter is the *end* of a traffic leg with that name. It says nothing about which node or URI *starts* each leg. >> >> The each value description, the text says between which 3GPP nodes the traffic leg spans. There is no need to indicate the *start* in the signaling. > > There is no need because it is implicit? > Or because it is not needed for the uses you have in mind? Correct. The purpose of the parameter is to inform entities about the traffic leg. But, for 3GPP, the value definition implicitly DO provide information between what types of entities the traffic leg span. >>> If B2BUAs (especially SBCs) are involved, is it important whether the iotl parameters are preserved e2e? >> >> The iotl parameter only needs to be preserved until it is "consumed" at the end of the traffic leg. > > That seems to open up another discussion. It is a continuation of the > question I had above who uses the iotl parameter values, and for what. > > When you say that the parameter identifies the end of a leg, and is > consumed at the end of the leg, that implies to me that this serves as > a request that the node identified by the URI perform some action > implied by the iotl value. The node identified by the URI, AND intermediaries on the traffic leg, that perform actions based on the value. This is NOT a parameter used to request nodes to perform specific actions, and whatever entities do what the information is outside the scope of the document. The purpose of the parameter is to inform nodes about the traffic leg, and whatever (if any) actions taken are based on local/operator policy. > If that is what this is about, then it should be spelled out clearly. The Introduction contains some text, including the following paragraph: "The traffic leg information can be used by intermediary entities to make policy decisions, related to e.g. media anchoring, signalling policy, insertion of media functions (e.g. transcoder) and charging." But, if more text is needed, we can of course add that. However, I don't think we should copy/paste the 3GPP specification into the draft. The 3GPP specification is available for anyone who wants detailed information on what actions nodes take in certain scenarios etc. Regards, Christer _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch= From nobody Thu May 1 09:14: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 21E9E1A08F2 for ; Thu, 1 May 2014 09:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eflw2flPY20x for ; Thu, 1 May 2014 09:14:53 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDC01A08D0 for ; Thu, 1 May 2014 09:14:52 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta02.westchester.pa.mail.comcast.net with comcast id wg8k1n00516LCl051gEqDU; Thu, 01 May 2014 16:14:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id wgEq1n00p3ZTu2S3SgEqQX; Thu, 01 May 2014 16:14:50 +0000 Message-ID: <536272FA.9070100@alum.mit.edu> Date: Thu, 01 May 2014 12:14:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Christer Holmberg , "dispatch@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2E7936@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=1398960891; bh=mC9/81s0iXdkVkf7oNSP3zvlgxPwtyXTwTrAMpef5ns=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mPgVQYR9fBNRKYoo2StMQo84CelHVofRCBzAYQq1AyEFrW7ziGJF0FA/Q8ICvaEoN wJSiM/TD2zeLUHdmxW35txjRNwyLJZn7Lj2PkbXdxmQZyU6/sLrjYnwPIn/3jjVhkn yBBIgBi6vhrtXCjuBTIJKti+vNMqstwKHI7SdT4w+DvL9CQFbsPYu+wHXFO8FUoSM9 P0gkwhT8oPAKlzOQ1XM169ydRsdBVR/UuKomKy7k+JdQOY++M41tRzUFGb8mOYMSui 845AlZi11P0CymYPgm/3bu2wHiJB6Fic7POSb4TvLFpCjSojq0h3a4hylev/VbuUxy hv9kZgL79vmTg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/qtuCWZBIvXj5ylzLYGjDHXeLfH0 Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 01 May 2014 16:14:54 -0000 On 5/1/14 11:16 AM, Christer Holmberg wrote: > Hi Paul, > >>>> Then, the description of the parameter says the uri with the parameter is the *end* of a traffic leg with that name. It says nothing about which node or URI *starts* each leg. >>> >>> The each value description, the text says between which 3GPP nodes the traffic leg spans. There is no need to indicate the *start* in the signaling. >> >> There is no need because it is implicit? >> Or because it is not needed for the uses you have in mind? > > Correct. The purpose of the parameter is to inform entities about the traffic leg. > > But, for 3GPP, the value definition implicitly DO provide information between what types of entities the traffic leg span. > >>>> If B2BUAs (especially SBCs) are involved, is it important whether the iotl parameters are preserved e2e? >>> >>> The iotl parameter only needs to be preserved until it is "consumed" at the end of the traffic leg. >> >> That seems to open up another discussion. It is a continuation of the >> question I had above who uses the iotl parameter values, and for what. >> >> When you say that the parameter identifies the end of a leg, and is >> consumed at the end of the leg, that implies to me that this serves as a >> request that the node identified by the URI perform some action implied >> by the iotl value. > > The node identified by the URI, AND intermediaries on the traffic leg, that perform actions based on the value. > > This is NOT a parameter used to request nodes to perform specific actions, and whatever entities do what the information is outside the scope of the document. > > The purpose of the parameter is to inform nodes about the traffic leg, and whatever (if any) actions taken are based on local/operator policy. (I'm still trying to understand.) I *think* you are defining a new state machine for requests - that the request transitions among states as it is routed from the source to the destination. the iotl parameter identifies the current value of that state, and that when the request reaches the server responsible for the URI the parameter is attached to then the request leaves that state, and will enter some new state defined by the state machine. And then servers along the path can observe the current state value and adjust their behavior. Is that about right? But if I have this right, why does this need to be attached to a URI? Why is it necessary to identify the end node for this state? Surely the ending node knows that it does that. >> If that is what this is about, then it should be spelled out clearly. > > The Introduction contains some text, including the following paragraph: > > "The traffic leg information can be used by intermediary entities to > make policy decisions, related to e.g. media anchoring, signalling > policy, insertion of media functions (e.g. transcoder) and charging." > > But, if more text is needed, we can of course add that. Explanation of the abstract model of how this is intended to work is what I have in mind. Like the state model I mention above. > However, I don't think we should copy/paste the 3GPP specification into the draft. The 3GPP specification is available for anyone who wants detailed information on what actions nodes take in certain scenarios etc. No. If that is required then the scope of this draft should be narrowed to just 3gpp. > Regards, > > Christer > From nobody Thu May 1 14:14:17 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 029CF1A0971 for ; Thu, 1 May 2014 14:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 C2vlgnM5hogP for ; Thu, 1 May 2014 14:14:13 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id 055EE1A081F for ; Thu, 1 May 2014 14:14:12 -0700 (PDT) X-AuditID: c1b4fb3a-f79106d0000013ca-7d-5362b9227bb8 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3F.AA.05066.229B2635; Thu, 1 May 2014 23:14:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Thu, 1 May 2014 23:14:09 +0200 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAxuudP///zawCAAG22oA== Date: Thu, 1 May 2014 21:14:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> In-Reply-To: <536272FA.9070100@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvja7SzqRgg8eTFC2WTlrAarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj69R31oIPvBXfp/awNzC+5Opi5OSQEDCR mPFzDQuELSZx4d56ti5GLg4hgaOMEtO3/GWEcBYzSnxfc4y9i5GDg03AQqL7nzZIg4hAsMTB wzvBmoUFnCX+Hd7ADhF3kdj1uRvKDpO4/vozI4jNIqAi0Xf+GBuIzSvgK7F02T+oZduZJG6s Pc8KkuAU0JF49fsS2FBGoIu+n1rDBGIzC4hL3HoynwniUgGJJXvOM0PYohIvH/9jhbAVJXae bWeGqNeRWLD7ExuErS2xbOFrZojFghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRtHi1OLi 3HQjI73Uoszk4uL8PL281JJNjMBIObjlt9UOxoPPHQ8xCnAwKvHwFn+JDBZiTSwrrsw9xCjN waIkzjtpkXuwkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkarNocSxixxztnVaYzlb552mvb9 63Bq3bN+k3mJ80HnS5WcL4X9BKf5xm38vtjn3+kO3QsL9L49Dg0wVhE9lSzHsND+YLhFjE5b wuK8LJ0JM3g7d9+w+SutfO7Gr/fuHUt6ZhhJrDGf9H39Yb63sxn2vPnRan/l34zghgq3TnYF hcez+D5xVimxFGckGmoxFxUnAgANbsYadQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/eqgRGMZilj1qEfaZRjuT1RTm0FU Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 01 May 2014 21:14:15 -0000 Hi, > (I'm still trying to understand.) > > I *think* you are defining a new state machine for requests - that the > request transitions among states as it is routed from the source to the > destination. the iotl parameter identifies the current value of that > state, and that when the request reaches the server responsible for the > URI the parameter is attached to then the request leaves that state, and > will enter some new state defined by the state machine. > > And then servers along the path can observe the current state value and > adjust their behavior. > > Is that about right? I don't think so :) This is not so much about the request it self. It is simply about providing= information to other nodes about the traffic leg type on which the request= is sent, and to indicate the end of the traffic leg. So, I don't see why this would be associated with a state machine for reque= sts. > But if I have this right, why does this need to be attached to a URI? Because the end of the traffic leg is associated with the URI. > Why is it necessary to identify the end node for this state? Surely the > ending node knows that it does that. A node may not act as ending node for all types of traffic leg types. And, = if a node can act as ending node for different traffic leg types, it needs = to with which a given request is associated with. >> However, I don't think we should copy/paste the 3GPP specification into = the draft. The 3GPP specification is available for anyone who wants detaile= d information on what actions nodes take in certain scenarios etc. > > No. If that is required then the scope of this draft should be narrowed t= o just 3gpp. I have no problem with that. Regards, Christer= From nobody Thu May 1 15:25:42 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 EEEB21A066A for ; Thu, 1 May 2014 15:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EQTh7KzsUS6 for ; Thu, 1 May 2014 15:25:41 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id DBB4F1A06DB for ; Thu, 1 May 2014 15:25:40 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta08.westchester.pa.mail.comcast.net with comcast id wjj81n0030vyq2s58mRePn; Thu, 01 May 2014 22:25:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id wmRe1n00C3ZTu2S3RmReA7; Thu, 01 May 2014 22:25:38 +0000 Message-ID: <5362C9E2.1040306@alum.mit.edu> Date: Thu, 01 May 2014 18:25:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Christer Holmberg , "dispatch@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2E81D4@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=1398983138; bh=hXc4gvjABQiO6ZDqTs+03xa1Ed2+a3IxyxY5naKSPxQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mGyXWpiEkk/5RunBaTMqylRTSDV+EPddeCABhL4TRWteAGEvy8T+PBZYvwgCxc0+e lBFs/tj4ZvJifqablH19Ors/VpbCdB6MkXdSUhQo9xIUEhEpx25NXqB/m4oI2VJiTW C4TDnMltrfs4LiEz5nhePmkP719WlN4to219ANn441vja4570EAEDQFS0ASqmEDXlX t4Kmv7K+jADbUCGq5cvviCZv8wmycvqsDH56aTIsNQQGcYGxLdVZfLVWoa2EjiutaN W/wLZI/5S6Sy3xzUg4CxKSHVlFEfK7AQyvNg7b0+xSwedhoJ1ttGVCnwv+Uzq/OpDX GlBol3XhNJM0A== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/QoJlu_80wPxBa-9Xvm0WIU6wYt0 Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 01 May 2014 22:25:42 -0000 On 5/1/14 5:14 PM, Christer Holmberg wrote: > Hi, > >> (I'm still trying to understand.) >> >> I *think* you are defining a new state machine for requests - that the >> request transitions among states as it is routed from the source to the >> destination. the iotl parameter identifies the current value of that >> state, and that when the request reaches the server responsible for the >> URI the parameter is attached to then the request leaves that state, and >> will enter some new state defined by the state machine. >> >> And then servers along the path can observe the current state value and >> adjust their behavior. >> >> Is that about right? > > I don't think so :) Then I'm *still* trying to understand!!! When I look at Figure 1 I see evidence for a state machine. Certain sequences of values from section 4.2 are possible, and others are not. > This is not so much about the request it self. It is simply about providing information to other nodes about the traffic leg type on which the request is sent, and to indicate the end of the traffic leg. How do other nodes determine the traffic leg type? What I can infer from the draft is: 1) if the parameter is on the R-URI, then that determines the current traffic leg type. 2) else, if one or more URIs in the Route header field have this parameter, then the first one that does *might* determine the traffic leg type. (Not certain until that URI moves from the Route header to the R-URI. Until then a parameter with another value *might* be inserted so as to preempt this one.) 3) Presence in Path or Service-Route doesn't determine the traffic leg type. It is (2) that raises many questions. Can that situation ever legitimately happen? If so, isn't that a problem for any node that makes a decision based on a value that is later preempted? Or maybe only the R-URI is to be used to make decisions? > So, I don't see why this would be associated with a state machine for requests. > >> But if I have this right, why does this need to be attached to a URI? > > Because the end of the traffic leg is associated with the URI. > >> Why is it necessary to identify the end node for this state? Surely the >> ending node knows that it does that. > > A node may not act as ending node for all types of traffic leg types. And, if a node can act as ending node for different traffic leg types, it needs to with which a given request is associated with. I find that very confusing. I presume you mean something like an S-CSCF? That it may be visited many times by the same request, performing different roles each time. AFAIK, even in that case at each visit the server has information that allows it to determine what it is doing. But I don't have a full understanding of that. >>> However, I don't think we should copy/paste the 3GPP specification into the draft. The 3GPP specification is available for anyone who wants detailed information on what actions nodes take in certain scenarios etc. >> >> No. If that is required then the scope of this draft should be narrowed to just 3gpp. > > I have no problem with that. That is a decision for you to make. If you want to narrow the scope to just 3gpp then the draft will follow a different track - not dispatch. If it is to be viewed as applicable to the internet as a whole, then it needs to specify the semantics well enough that others can decide *if* it would be generally useful, and if so, then *how* it should be used. Thanks, Paul From nobody Fri May 2 00:41: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 05A591A6F47 for ; Fri, 2 May 2014 00:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiLwGHDt6JZR for ; Fri, 2 May 2014 00:41:30 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3B21A6EEF for ; Fri, 2 May 2014 00:41:30 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-99-53634c27060c Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8B.77.04199.72C43635; Fri, 2 May 2014 09:41:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0174.001; Fri, 2 May 2014 09:41:27 +0200 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAxuudP///zawCAAG22oP//+eQA//9KsDA= Date: Fri, 2 May 2014 07:41:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> In-Reply-To: <5362C9E2.1040306@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvja66T3Kwwb+TmhZLJy1gtVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWx9fVBxoIXEhXb+q6zNzBuF+5i5OSQEDCR 2L98BTOELSZx4d56ti5GLg4hgaOMErM+TmeFcBYzSjw69Iqxi5GDg03AQqL7nzZIg4hAsMTB wztZQGxhAWeJf4c3sEPEXSR2fe6GspMk3nZ2s4C0sgioSLQuqAMJ8wr4SizaMJMZYvxcZon3 C++CzeEU0JHYMuseK4jNCHTQ91NrmEBsZgFxiVtP5jNBHCogsWTPeaijRSVePv7HCmErSuw8 284MUa8jsWD3JzYIW1ti2cLXzBCLBSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjKLFqcVJ uelGRnqpRZnJxcX5eXp5qSWbGIFxcnDLb4MdjC+fOx5iFOBgVOLhLf4SGSzEmlhWXJl7iFGa g0VJnPfbWfdgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxJMb4fj2ee13MqNYuNZHQ8oqF2 54DH54VH9Np/9wVe3s79Mn0O7/Z9F7dYTD6W8jN6klnZZLfTe9ViTBb0Sh/M2Cra6ZgWo1Kt qq7971jtkhVZtWeWuS9PMuD3nj2jZtkJzxnRC/sW2xtFbuF68EN7g2Phm7gzW3cyvLT1fLPg tYRe98wL/3cosRRnJBpqMRcVJwIABzmgznQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/MD7uStOjJG7hGTQ0pn3O0Qo9bBo Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 02 May 2014 07:41:32 -0000 Hi, > What I can infer from the draft is: > > 1) if the parameter is on the R-URI, then that determines the current tra= ffic leg type. > > 2) else, if one or more URIs in the Route header field have this paramete= r, then the first one=20 > that does *might* determine the traffic leg type. (Not certain until that= URI moves from the Route header=20 > to the R-URI. Until then a parameter with another value *might* be insert= ed so as to preempt this one.) In the 3GPP scenarios, there will always only be at most one iotl parameter= in either the R-URI or in one of the Route header fields, and whenever suc= h parameter is present the request is traversing the indicated traffic leg = type. So, if we limit the draft to 3GPP, that should not be an issue. And, we do intend to provide more call flow information etc in the next ver= sion, which hopefully makes things more clear. > 3) Presence in Path or Service-Route doesn't determine the traffic leg ty= pe. Correct.=20 During registration, when a node inserts a Path, if the node knows that it = will act as an endpoint for requests traversing the registration path, it c= an insert the parameter in its URI. But, the URI will have no meaning until= it is actually used in a request (e.g. an initial INVITE) sent on the regi= stration path. > It is (2) that raises many questions. Can that situation ever legitimatel= y happen? If so, isn't that a problem for any node that makes a decision ba= sed on a value that is later preempted? > > Or maybe only the R-URI is to be used to make decisions? See above. >> A node may not act as ending node for all types of traffic leg types. An= d, if a node can act as ending node=20 >> for different traffic leg types, it needs to with which a given request = is associated with. > > I find that very confusing. I presume you mean something like an S-CSCF?= =20 > That it may be visited many times by the same request, performing differe= nt roles each=20 > time. AFAIK, even in that case at each visit the server has information t= hat allows it to determine=20 > what it is doing. But I don't have a full understanding of that. It is not so much about a given request visiting the same node multiple tim= es. It is more about a node receiving multiple different requests (for differen= t calls etc), and each time the traffic leg type may be different. A typica= l example are IBCFs (3GPP network border entities), which may be parts of d= ifferent traffic leg types. >>>> However, I don't think we should copy/paste the 3GPP specification int= o the draft. The 3GPP specification is available for anyone who wants detai= led information on what actions nodes take in certain scenarios etc. >>> >>> No. If that is required then the scope of this draft should be narrowed= to just 3gpp. >> >> I have no problem with that. > > That is a decision for you to make. If you want to narrow the scope to ju= st 3gpp then the draft will follow a different track - not dispatch. So, what is the right path, then? Should 3GPP define the parameter themselv= es? Regards, Christer From nobody Fri May 2 12:05:42 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 EFFA21A7022 for ; Fri, 2 May 2014 12:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nopXxz6Pz4GG for ; Fri, 2 May 2014 12:05:40 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id CD3FA1A6FFD for ; Fri, 2 May 2014 12:05:39 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta06.westchester.pa.mail.comcast.net with comcast id wzkm1n0041GhbT85675daR; Fri, 02 May 2014 19:05:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id x75c1n00d3ZTu2S3T75cKf; Fri, 02 May 2014 19:05:37 +0000 Message-ID: <5363EC80.9010709@alum.mit.edu> Date: Fri, 02 May 2014 15:05:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Christer Holmberg , "dispatch@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2E90B6@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=1399057537; bh=Hbm84/vBFzLxMCFr9/4rcGf4I9l2MXaBJnrTz3YaYj4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=b8jdqzJ1NQ5YuEK7kNPUFoFBHHvrc3FF2aMrtIsNgtD8OyvCuUPf0Fd8j3qkZm1KQ 0MzdQaqo4VdTdMzS4OUHHI1P+39vPzpjN1W8RWvnWH3/wrGzD9vUfcb5iJexLXeuZC GHM0RZBnFe3MvCCsOAQlUiSmp6ulwQ93PhSgxpAOuvgc+3pZjym8/hgjw76TRX8oVc IBn/i5Ywlafa3DJXMHgdt4smpD67HaTyA79gFEBRck/H8oibORhHXesNPrNTxptLvk WgJU/oBDhJfwQejxxLjR6rUN0goUVKsLC7QhB8nqIutQT2Js5JeTiT0oRkwtmeUZop NoQ0YqGIvGqOw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/XwR5wGOIMT5LH0i46uL0YHaaWWw Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 02 May 2014 19:05:41 -0000 On 5/2/14 3:41 AM, Christer Holmberg wrote: > Hi, > >> What I can infer from the draft is: >> >> 1) if the parameter is on the R-URI, then that determines the current traffic leg type. >> >> 2) else, if one or more URIs in the Route header field have this parameter, then the first one >> that does *might* determine the traffic leg type. (Not certain until that URI moves from the Route header >> to the R-URI. Until then a parameter with another value *might* be inserted so as to preempt this one.) > > In the 3GPP scenarios, there will always only be at most one iotl parameter in either the R-URI or in one of the Route header fields, and whenever such parameter is present the request is traversing the indicated traffic leg type. > > So, if we limit the draft to 3GPP, that should not be an issue. Well, if this is to be more generally applicable, then ISTM there needs to be a general mechanism to determine what leg type is in effect. The easy way seems to be to identify this as a restriction - only one instance of the iotl parameter across the Route header and the R-URI. > And, we do intend to provide more call flow information etc in the next version, which hopefully makes things more clear. > >> 3) Presence in Path or Service-Route doesn't determine the traffic leg type. > > Correct. > > During registration, when a node inserts a Path, if the node knows that it will act as an endpoint for requests traversing the registration path, it can insert the parameter in its URI. But, the URI will have no meaning until it is actually used in a request (e.g. an initial INVITE) sent on the registration path. > > >> It is (2) that raises many questions. Can that situation ever legitimately happen? If so, isn't that a problem for any node that makes a decision based on a value that is later preempted? >> >> Or maybe only the R-URI is to be used to make decisions? > > See above. > >>> A node may not act as ending node for all types of traffic leg types. And, if a node can act as ending node >>> for different traffic leg types, it needs to with which a given request is associated with. >> >> I find that very confusing. I presume you mean something like an S-CSCF? >> That it may be visited many times by the same request, performing different roles each >> time. AFAIK, even in that case at each visit the server has information that allows it to determine >> what it is doing. But I don't have a full understanding of that. > > It is not so much about a given request visiting the same node multiple times. > > It is more about a node receiving multiple different requests (for different calls etc), and each time the traffic leg type may be different. A typical example are IBCFs (3GPP network border entities), which may be parts of different traffic leg types. > > >>>>> However, I don't think we should copy/paste the 3GPP specification into the draft. The 3GPP specification is available for anyone who wants detailed information on what actions nodes take in certain scenarios etc. >>>> >>>> No. If that is required then the scope of this draft should be narrowed to just 3gpp. >>> >>> I have no problem with that. >> >> That is a decision for you to make. If you want to narrow the scope to just 3gpp then the draft will follow a different track - not dispatch. > > So, what is the right path, then? Should 3GPP define the parameter themselves? New SIP/SIPS URI Parameters require Standards Action, which means it must come from a WG or be AD sponsored. AD sponsored might be better for something specific to 3gpp, if an AD is willing to do so. Else I guess it must go through a WG such as this one. But first you might make an effort to "sell" this mechanism as generally useful. (So far I'm having trouble seeing that.) Or you might want to seek some other mechanism where the iana registration is less restrictive. Thanks, Paul From nobody Fri May 2 14:16: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 7C44A1A0A7B for ; Fri, 2 May 2014 14:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 Cc0eF8tVUnr9 for ; Fri, 2 May 2014 14:16:20 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id D21C51A093A for ; Fri, 2 May 2014 14:16:19 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta15.westchester.pa.mail.comcast.net with comcast id x8mH1n0071YDfWL5F9GHRx; Fri, 02 May 2014 21:16:17 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta20.westchester.pa.mail.comcast.net with comcast id x9GG1n00Y1KKtkw3g9GHoz; Fri, 02 May 2014 21:16:17 +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 s42LGGT7007947; Fri, 2 May 2014 17:16:16 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s42LGGad007946; Fri, 2 May 2014 17:16:16 -0400 Date: Fri, 2 May 2014 17:16:16 -0400 Message-Id: <201405022116.s42LGGad007946@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D2E795B@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu>, <201404301901.s3UJ1Awf013148@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2E795B@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399065377; bh=T7wwJpSozIAIcDIJDsaulR5e0Y4S0maApgPfaJ9299w=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=KI5iNBi06wL0uarVmIn7SJM0SjG7nrluYxb15xCSGc336n4KiY2brQk8UBElCkPlz HFRH35c1uHUHvzY16pcDZbDghmuVMxgvDYkW2aVSz0TFyE4fO7DI4ijbZzWnlitrbd zMWl7pZDu+cR7LUzWM2EIJk8SnlLtChPkKGkBk8wPEvB1S2XM2prscJCj8U5zrfo2+ NyBZv1q1wfg3TTI1owbq/EsQcVNA87stRKoRIjqAVbj1vcTjwfYWKMomz5OKN3CxMF SsnWanW7gO3k5+uBg1SmK0bqW3Gx5KpGm+gHqjlN6C/2pdXJgOSODrEhtGWWeuDfu4 1cdpM719nJZ3Q== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/Ab6rVv99Ery9Re_8dRf54D1DtzU Cc: dispatch@ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 02 May 2014 21:16:21 -0000 > From: Christer Holmberg > >2. overlooking that, it's not really a property of the URI, its a > > modifier of how the URI is *used* > > I am not really sure what you mean by that. We are not suggesting > any changes to how URIs are used. The parameter simply provides > additional information to the consumer of the URI. What you said is actually my point -- the iotl value isn't *part* of the URI, it's information to be used *in addition* to the URI. And URI parameters are *part* of the URI, among other things, they should be opaque except to the SIP entity that they name. Since iotl is *additional* to the URI, it really ought to be in a header parameter, not a URI parameter. Dale From nobody Sat May 3 06:51: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 7D4821A00C0 for ; Sat, 3 May 2014 06:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Nplx1KHIY6Bo for ; Sat, 3 May 2014 06:51:17 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id 1E95D1A00B6 for ; Sat, 3 May 2014 06:51:16 -0700 (PDT) X-AuditID: c1b4fb3a-f79106d0000013ca-df-5364f4515cc9 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 19.CD.05066.154F4635; Sat, 3 May 2014 15:51:13 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Sat, 3 May 2014 15:51:13 +0200 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAxuudP///zawCAAG22oP//+eQA//9KsDCAAg/BAIABWf9p Date: Sat, 3 May 2014 13:51:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> In-Reply-To: <5363EC80.9010709@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+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjW7gl5Rgg/bvWhZLJy1gtVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJUxY/FcloI2oYruKbPZGhi7+boYOTkkBEwk lv17ygRhi0lcuLeerYuRi0NI4CijROuSVewQzmJGiYWP+lm6GDk42AQsJLr/aYM0iAgESxw8 vJMFxBYWcJb4d3gDO0TcRWLX5252kHIRgTyJ3ZeUQMIsAioSc/onMoLYvAK+EtO//2WEGN/I IjGvdTcrSIJTQEdi+7a7zCA2I9BB30+tATuOWUBc4taT+VCHCkgs2XOeGcIWlXj5+B8ryC4J AUWJ5f1yEOU6Egt2f2KDsLUlli18zQyxV1Di5MwnLBMYRWchmToLScssJC2zkLQsYGRZxSha nFpcnJtuZKSXWpSZXFycn6eXl1qyiREYJQe3/LbawXjwueMhRgEORiUe3uIvkcFCrIllxZW5 hxilOViUxHknLXIPFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cAYoBllopMz/WqGaNz33AZb 6Uz9ehnZ193Mlg0dn+Onz+cLrsl69NNiaXO1xNu9u9U8Zu36//56ZfsrH7kHE2rmuKzZGvrh 7s271Xv00/ojTN9cXi2lEl+SWHL0Sre4n/9GXrmCnSxmU5Nt1Tdp/fx6X+bWCelZBd5vUs3F bNPfnFQ4wTx172ElluKMREMt5qLiRADlZcuAcwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/-PDxvBalv_hw7DzbHPyrYKGTeuk Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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: Sat, 03 May 2014 13:51:19 -0000 Hi, >>> What I can infer from the draft is: >>> >>> 1) if the parameter is on the R-URI, then that determines the current t= raffic leg type. >>> >>> 2) else, if one or more URIs in the Route header field have this parame= ter, then the first one >>> that does *might* determine the traffic leg type. (Not certain until th= at URI moves from the Route header >>> to the R-URI. Until then a parameter with another value *might* be inse= rted so as to preempt this one.) >> >> In the 3GPP scenarios, there will always only be at most one iotl parame= ter in either the R-URI or in one of the Route header fields, and whenever = such parameter is present the request is traversing the indicated traffic l= eg type. >> >> So, if we limit the draft to 3GPP, that should not be an issue. > > Well, if this is to be more generally applicable, then ISTM there needs > to be a general mechanism to determine what leg type is in effect. The > easy way seems to be to identify this as a restriction - only one > instance of the iotl parameter across the Route header and the R-URI. I agree. And, we can say that the starting node of a traffic leg MUST verif= y this. ... >>> That is a decision for you to make. If you want to narrow the scope to = just 3gpp then the draft will follow a different track - not dispatch. >> >> So, what is the right path, then? Should 3GPP define the parameter thems= elves? > > New SIP/SIPS URI Parameters require Standards Action, which means it > must come from a WG or be AD sponsored. AD sponsored might be better for > something specific to 3gpp, if an AD is willing to do so. Else I guess > it must go through a WG such as this one. > But first you might make an effort to "sell" this mechanism as generally > useful. (So far I'm having trouble seeing that.) If people from the non-3GPP community doesn't see a need in this I am not g= oing to try to convince them :) > Or you might want to seek some other mechanism where the iana registratio= n is less restrictive. There were discussions in 3GPP to e.g. use feature capability indicators, b= ut it was realized that the semantics don't fit. The outcome was that a URI= parameter is the best solution, and I personally also support that view. Regards, Christer= From nobody Sat May 3 06:59:41 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 66F251A00C0 for ; Sat, 3 May 2014 06:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_bdfWDvUat2 for ; Sat, 3 May 2014 06:59:37 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 86F211A00B6 for ; Sat, 3 May 2014 06:59:36 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-bc-5364f6457de2 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FC.D4.04199.546F4635; Sat, 3 May 2014 15:59:33 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Sat, 3 May 2014 15:59:32 +0200 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAH73g3ACposi8APtMEfwAiwTKp Date: Sat, 3 May 2014 13:59:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2EA90C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu>, <201404301901.s3UJ1Awf013148@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2E795B@ESESSMB209.ericsson.se>, <201405022116.s42LGGad007946@hobgoblin.ariadne.com> In-Reply-To: <201405022116.s42LGGad007946@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvja7rt5Rgg64VYhZLJy1gtXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgypjx6T5zwQa2iiU3nzE3MP5m6WLk5JAQMJGY +e4JM4QtJnHh3nq2LkYuDiGBo4wSp6e0sUM4ixklnt6+wNrFyMHBJmAh0f1PG8QUEdCU6FiQ A9LLLKAt8f/6OkYQW1jAWeLf4Q3sILaIgIvErs/dUHaUxIXNs8BqWARUJM63nAW7gVfAV6L1 y0aoVY3MEuunHgJbxSngIHHjjT9IDSPQbd9PrWGC2CUucevJfCaImwUkluw5D3W/qMTLx//A WiUEFCWW98tBlOtILNj9iQ3mzGULXzNDrBWUODnzCcsERrFZSKbOQtIyC0nLLCQtCxhZVjGK FqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIERs7BLb8NdjC+fO54iFGAg1GJh7f4S2SwEGtiWXFl 7iFGaQ4WJXHeb2fdg4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwLny81U+//YLgjPg9N9zC Tl2KuvXi4jxbPZ/6lZuvFi2/acOkXKPGrL/zU1+Iymx1tsBr3uv/zJ48jyXohL7A3ZjLomoO n2+lnORhNvvx457ruT0O7vuNmtncms9uLdgYtZolzO5B1fmJMy6Fpttpatx7dMC0bW3bpmib yxWLr6ge/H35sMXx20osxRmJhlrMRcWJABKZ1959AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/j-9XZwcOKc0MB5Y5-Bj_yJkybw4 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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: Sat, 03 May 2014 13:59:39 -0000 Hi, >>>2. overlooking that, it's not really a property of the URI, its a >>> modifier of how the URI is *used* >> >> I am not really sure what you mean by that. We are not suggesting >> any changes to how URIs are used. The parameter simply provides >> additional information to the consumer of the URI. > > What you said is actually my point -- the iotl value isn't *part* of > the URI, it's information to be used *in addition* to the URI. And > URI parameters are *part* of the URI, among other things, they should > be opaque except to the SIP entity that they name. Since iotl is > *additional* to the URI, it really ought to be in a header parameter, > not a URI parameter. URI parameters can be used to provide additional information associated wit= h an URI. Regards, Christer= From nobody Sun May 4 18:38: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 6C8D71A01FE for ; Sun, 4 May 2014 18:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 QMEWaNsKn_Uf for ; Sun, 4 May 2014 18:38:23 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id BD3C41A01FA for ; Sun, 4 May 2014 18:38:22 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA11.westchester.pa.mail.comcast.net with comcast id y1Zx1n0031GhbT85B1eKn3; Mon, 05 May 2014 01:38:19 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta07.westchester.pa.mail.comcast.net with comcast id y1eJ1n0151KKtkw3T1eJ4l; Mon, 05 May 2014 01:38:19 +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 s451cIPE002930 for ; Sun, 4 May 2014 21:38:18 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s451cIJ7002929; Sun, 4 May 2014 21:38:18 -0400 Date: Sun, 4 May 2014 21:38:18 -0400 Message-Id: <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399253899; bh=JJIAAjgi364DYj1a3EmflUoiN2AlObQYLu/rc0DM74A=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=Mj/iQMYFmMnas2Ro9kB4DpJ1IiVvZwoBSiX7dWTs9f3Y6zKChIwDCcznpGSAZfFjb JPxqjiUwPinTV6UHbmemSNJvfbHDzsynLKXB4piPPfS6Al49/qaAxaItpxLP4Y0D39 H2oZfSBOr0osW9Iw3v/0pgcZq3vC7opHlfi/UecfNLJZLsPkUqguNY2T/o88DenATX rCUpao6DI/jF4r69Y/2xgxY6XGd7m9DiOfYJ76YLALmfJvainzNIDT34YiGzAUHp3u c6d//eD52ZmG7MOic7AYTTr1LS/3kLwirmTNaCQfVmI0aXf/5CKF+/WxcqlOMbtVNI WSQXpChgYCQFA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/CzRNkDf95nD6L7yojSpP9Rs5C0I Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 05 May 2014 01:38:24 -0000 I think that the proper way to deal with "iotl" is not as a proposed standard, but as an informational RFC. For a long list of reasons, I think that the benefit from trying to handle this as a standardization question will be small relative to the amount of work needed. But it would be useful to document the solution the IMS people have implemented to their problem. Dale From nobody Sun May 4 23:37:41 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 02BCA1A0267 for ; Sun, 4 May 2014 23:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2ZIsKmjuo5n for ; Sun, 4 May 2014 23:37:36 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 960EE1A0164 for ; Sun, 4 May 2014 23:37:35 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-49-536731ab531e Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 64.1D.04714.BA137635; Mon, 5 May 2014 08:37:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Mon, 5 May 2014 08:37:31 +0200 From: Christer Holmberg To: "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAxuudP///zawCAAG22oP//+eQA//9KsDCAAg/BAIABWf9pgAJZ9Wf//60lgA== Date: Mon, 5 May 2014 06:37:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2EC27C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> In-Reply-To: <201405050138.s451cIJ7002929@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje5qw/Rgg9apJhZLJy1gtXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgyph09yhTwVuOimcdT9kbGKezdzFyckgImEg8 eLCAFcIWk7hwbz1bFyMXh5DAUUaJB/ePMUI4ixklJi35B+RwcLAJWEh0/9MGaRARCJH4PK2T EcQWFnCW+Hd4AztE3EVi1+duKLtOYn7HIyYQm0VAReL59iUsIDavgK/ExK1/WCHmt7BKrOo/ AlbEKeAg8b9/PdhQRqCLvp9aAxZnFhCXuPVkPhPEpQISS/acZ4awRSVePv4H9YGixM6z7cwQ 9ToSC3Z/YoOwtSWWLXzNDLFYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKFqcWlycm25k rJdalJlcXJyfp5eXWrKJERgnB7f81t3BuPq14yFGAQ5GJR7e4i+RwUKsiWXFlbmHGKU5WJTE edvuegcLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYOybt33XjaJatdCYhMqfk8uauM1+Rqa8 Nn6m2SgbUhanN4VJJKLpPHONjcWblK0N5R3r5kQ6PP55zdnIg1PY8ai+4NndoufkLU/8nKzD u736NEP8zY2hxXWPwvo8J9aoLDq5Yte8+8fFvtXF2UVZ+HjzZhTk1Ts8rp9ruZ3N33qi+t6j tcm/lViKMxINtZiLihMBWeznFXQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/gP4XZ5k8-4PyClqwBWVIG3zxfMk Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 05 May 2014 06:37:38 -0000 Hi, Based on the comments so far, some more text would be needed, but in genera= l I think most of the work is already done - especially if we scope the sol= ution to 3GPP. But, having said that, I don't have any strong feelings how it's documented= . Standards track, informational, documented in 3GPP - you tell me - I do := ) Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Dale R. Worl= ey Sent: 5. toukokuuta 2014 4:38 To: dispatch@ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 I think that the proper way to deal with "iotl" is not as a proposed standa= rd, but as an informational RFC. For a long list of reasons, I think that = the benefit from trying to handle this as a standardization question will b= e small relative to the amount of work needed. But it would be useful to d= ocument the solution the IMS people have implemented to their problem. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon May 5 06:45: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 08AC71A0334 for ; Mon, 5 May 2014 06:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 DiXd2JKbnIEY for ; Mon, 5 May 2014 06:45:05 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id C703D1A032D for ; Mon, 5 May 2014 06:45:04 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id yCtw1n0010cZkys53Dl1xE; Mon, 05 May 2014 13:45:01 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta10.westchester.pa.mail.comcast.net with comcast id yDl01n00b1KKtkw3WDl0us; Mon, 05 May 2014 13:45:01 +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 s45Dix47016586 for ; Mon, 5 May 2014 09:44:59 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s45Dixmj016585; Mon, 5 May 2014 09:44:59 -0400 Date: Mon, 5 May 2014 09:44:59 -0400 Message-Id: <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-reply-to: <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> (md3135@att.com) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399297501; bh=CePjVbbpmORfbvuGfCZnNU8HInKfw7qXJScI4hlNcRU=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=miVTLQbYvrVM4DlJjnAK48YmRZTG+E7cM5JB9cbvvSsm3Sa990QChxGAHSeb2CGOf qonyR7q5ucAgBn2X/XNjE+XvDg16t9ppVoQRcwyZMIOdnwzA0kEOszyIkzquyH954r /OHxVtWIb6iqA1ogRJn/6PcuV8fZHbth+SSw3HvDeUuO+4NN4h++yJdGIXrMJwNQ4E J/E9vG4ctFC0AQvVJzfQhEpJRopoylmkluJyvSLWA93CXuymsBVnfER2gLyJ+CCNjj po2Lkn7++6XWLVAKUOhQpUg6otcrMVv/xwqX75M4q0ALfTVyhMoPvcBFaoaPrqMvQI TNH9cEUbtPfvQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/40IVsk69PGSl_ThcCCSDT9GTyig Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 05 May 2014 13:45:07 -0000 > From: "DOLLY, MARTIN C" > > > On May 4, 2014, at 9:38 PM, "Dale R. Worley" wrote: > > For a long list of reasons, I > > think that the benefit from trying to handle this as a standardization > > question will be small relative to the amount of work needed. > And those reasons are? It's not clear what the general problem is for which the 3GPP solution is a specific solution. Thus, clarifying the general problem and its requirements would take considerable work. Nobody other than 3GPP has expressed that they have a problem of this nature. Thus, getting people to work on the problem may be difficult. There don't seem to be any scenarios where interoperation is needed, either between supporting and non-supporting SIP implementations or between supporting SIP implementations that use different definitions of the "call leg" structure. If all usage is within "walled gardens" where technical uniformity can be enforced administratively, there is no practical need for a global standard. Doubts have been expressed in the IETF that the current implementation is the best solution from an architectural point of view. Nonetheless, 3GPP is unlikely to obtain significant additional benefit if the IETF finds a "better" solution, and it seems 3GPP would be unlikely to change their implementation if the IETF were to decree a "better" standard. Taking all of this together, it seems that the IETF is unlikely to complete a proper standards effort for this problem and that there would be little benefit obtained from developing a proper standard. The IETF has a longstanding policy against declaring that something is a standard just because it has been implemented, so we can't declare this a standard simply because 3GPP is using it. OTOH, it would be useful to document that this is how 3GPP solves this problem. The only difficulty I see is that the IANA registry "SIP/SIPS URI Parameters" ( http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-11 ) is marked "Registration Procedure(s): Standards Action", and we'd really like to have a pointer from the registry to the informational RFC. I suppose we could just ask the IESG to make the update. Dale From nobody Mon May 5 07:00:58 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 7A74D1A034E for ; Mon, 5 May 2014 07:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tU3nhefWqy4m for ; Mon, 5 May 2014 07:00:54 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8AC1A0320 for ; Mon, 5 May 2014 07:00:54 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta02.westchester.pa.mail.comcast.net with comcast id yDHn1n0061vXlb851E0q7h; Mon, 05 May 2014 14:00:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id yE0q1n00W3ZTu2S3dE0qW4; Mon, 05 May 2014 14:00:50 +0000 Message-ID: <53679992.5060404@alum.mit.edu> Date: Mon, 05 May 2014 10:00:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> In-Reply-To: <201405051344.s45Dixmj016585@hobgoblin.ariadne.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=1399298450; bh=df5FkEnAiK93BbeQSYJi35ULqPQfp/90rkjYHMw3q/U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WsQ34SYX/HcRd27GsUE1glGB2umKDhYbmNWVaRI6aaaZO1CVi/eKXepxY3I6DbD8D 5WszHOvFHmy7cau98kM+nS5mEnuL3L2R5nE0356H7Q19HagqBCB2az4XK5JzUOZ0S3 ajmCglKinF/z7B/ai6dbu9GlE9JNv9B5LQdkEJly94k+jNuNScQRFz6IKEGlRyb2gn JFJXhiwo9vgVRTBpiQe4R0rYC5Uj7Y7b0jHSxFvNAtj5qb07dikldvIcsE0I/v2LKC 1LPmpJQq73y7J769fmeHtzkKpvHHD1aVWcyc7ktdlhmKQCUnBUsXszyCNCq88C5PxI 9HNV+kKVP3uhQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/3Vnr8HukNuPwuMRr1xTiZshfz6g Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 05 May 2014 14:00:55 -0000 On 5/5/14 9:44 AM, Dale R. Worley wrote: >> From: "DOLLY, MARTIN C" >> >>> On May 4, 2014, at 9:38 PM, "Dale R. Worley" wrote: >>> For a long list of reasons, I >>> think that the benefit from trying to handle this as a standardization >>> question will be small relative to the amount of work needed. > >> And those reasons are? > > It's not clear what the general problem is for which the 3GPP solution > is a specific solution. Thus, clarifying the general problem and its > requirements would take considerable work. > > Nobody other than 3GPP has expressed that they have a problem of this > nature. Thus, getting people to work on the problem may be difficult. > > There don't seem to be any scenarios where interoperation is needed, > either between supporting and non-supporting SIP implementations or > between supporting SIP implementations that use different definitions > of the "call leg" structure. If all usage is within "walled gardens" > where technical uniformity can be enforced administratively, there is > no practical need for a global standard. > > Doubts have been expressed in the IETF that the current implementation > is the best solution from an architectural point of view. > Nonetheless, 3GPP is unlikely to obtain significant additional benefit > if the IETF finds a "better" solution, and it seems 3GPP would be > unlikely to change their implementation if the IETF were to decree a > "better" standard. > > Taking all of this together, it seems that the IETF is unlikely to > complete a proper standards effort for this problem and that there > would be little benefit obtained from developing a proper standard. > The IETF has a longstanding policy against declaring that something is > a standard just because it has been implemented, so we can't declare > this a standard simply because 3GPP is using it. OTOH, it would be > useful to document that this is how 3GPP solves this problem. > > The only difficulty I see is that the IANA registry "SIP/SIPS URI > Parameters" ( > http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-11 > ) is marked "Registration Procedure(s): Standards Action", and we'd > really like to have a pointer from the registry to the informational > RFC. I suppose we could just ask the IESG to make the update. I'm not sure I follow what you are suggesting. As you note, the registration procedure requires "Standards Action" and that requires a "Standards Track" RFC. IIUC an Informational RFC isn't Standards Track. Is that the point you are making? Are you suggesting that the IESG could override this? Thanks, Paul From nobody Mon May 5 10:20: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 2602F1A03B3 for ; Mon, 5 May 2014 10:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ayUQKbxF6Ep for ; Mon, 5 May 2014 10:20:43 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 149D81A02F6 for ; Mon, 5 May 2014 10:20:42 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-b9-5367c8660feb Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A8.D6.04714.668C7635; Mon, 5 May 2014 19:20:39 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Mon, 5 May 2014 19:20:38 +0200 From: Christer Holmberg To: "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAxuudP///zawCAAG22oP//+eQA//9KsDCAAg/BAIABWf9pgAJZ9Wf//+JMgAAdF7Gz///LdJA= Date: Mon, 5 May 2014 17:20:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2ECF30@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> In-Reply-To: <201405051344.s45Dixmj016585@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.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjW76ifRgg+Xf2S2WTlrAavHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbHuZQt7QZd4xeofa9gaGFcIdTFyckgImEhs ff2QCcIWk7hwbz1bFyMXh5DAUUaJ5rUPmEESQgKLGSUefsjtYuTgYBOwkOj+pw0SFhEIkfg8 rZMRxBYWcJb4d3gDO0TcRWLX524ou4tR4n0X2C4WARWJTdf3gNXzCvhKXL/+kAVi1xtWiUd3 P4MlOAUcJPoXbWEDsRmBDvp+ag3YccwC4hK3nsyHOlRAYsme88wQtqjEy8f/WCFsJYkV2y8x QtTrSCzY/YkNwtaWWLbwNTPEYkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNocWpxcW66 kbFealFmcnFxfp5eXmrJJkZglBzc8lt3B+Pq146HGAU4GJV4eAsnpwcLsSaWFVfmHmKU5mBR Eudtu+sdLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRneHX+pXdtXYblv/7ZmMkP1+okfuK eMqu4iPXen/qdhUxfEg2mnhTr/yPYFud/pVZv39eP158xOXrnf+ve2bu8fl1ke3V36kbLq58 +lrmQNb2Dx+jY1aU3n0lk6Mg59RhuvL0OfOWG9PEFit5Bf3d1vlB4aSu5wQL6Y+q5gtaLTTV XLvMLyUGK7EUZyQaajEXFScCAOU/qk9zAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/IG7vKLSgCLkDNO1p26H7hvDWF3o Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 05 May 2014 17:20:46 -0000 Hi, >>> For a long list of reasons, I think that the benefit from trying to han= dle this as a=20 >>> standardization question will be small relative to the amount of work n= eeded. >> >> And those reasons are? > > It's not clear what the general problem is for which the 3GPP solution is= a specific solution. Thus,=20 > clarifying the general problem and its requirements would take considerab= le work. As far as I know, based on the agreement between 3GPP and IETF, there doesn= 't have to be a general problem.=20 ... > Doubts have been expressed in the IETF that the current implementation is= the best solution from > an architectural point of view. I am not sure what you mean by that. You have claimed that a URI parameter has to "be part of" a URI. I disagree= with that. Take a look at the existing URI parameters. For example, do you= consider the commonly used "lr" parameter being "part of" a URI? In my opi= nion, it provides additional information about the URI - in the same way as= "iotl" does. (Also note that the URI parameters (the only exception being the user param= eter) are not part of the canonical representation of the URI). > Nonetheless, 3GPP is unlikely to obtain significant additional benefit if= the IETF finds a "better"=20 > solution, and it seems 3GPP would be unlikely to change their implementat= ion if the IETF were to=20 > decree a "better" standard. > > Taking all of this together, it seems that the IETF is unlikely to comple= te a proper standards effort=20 > for this problem and that there would be little benefit obtained from dev= eloping a proper=20 > standard. > The IETF has a longstanding policy against declaring that something is a = standard just because it has > been implemented, so we can't declare this a standard simply because 3GPP= is using it. OTOH, it=20 > would be useful to document that this is how 3GPP solves this problem. I don't think I have claimed that this has already been implemented. I HAVE= said, however, that 3GPP needs to for the current release (Rel-12), so the= re IS a time aspect. If the suggested solution doesn't work, or there is another reason it can't= be used, of course we have to come up with something else.=20 But, I don't understand why the first task should be to look for another so= lution, just for the sake of looking for another solution...=20 > The only difficulty I see is that the IANA registry "SIP/SIPS URI Paramet= ers" ( > http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-p= arameters-11 > ) is marked "Registration Procedure(s): Standards Action", and we'd reall= y like to have a pointer=20 > from the registry to the informational RFC. I suppose we could just ask = the IESG to make the=20 > update. Personally, I don't have any strong opinion regarding that. I just want to = do the work :) Regards, Christer From nobody Mon May 5 10:24:41 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 12ED71A03EC for ; Mon, 5 May 2014 10:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89T_Wpw1KotA for ; Mon, 5 May 2014 10:24:37 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 63C611A03D5 for ; Mon, 5 May 2014 10:24:37 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-59-5367c951633b Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 64.17.04714.159C7635; Mon, 5 May 2014 19:24:33 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0174.001; Mon, 5 May 2014 19:24:32 +0200 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAxuudP///zawCAAG22oP//+eQA//9KsDCAAg/BAIABWf9pgAJZ9Wf//+JMgAAdF7GzAAOkqAD//+A7kA== Date: Mon, 5 May 2014 17:24:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2ECF6D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> In-Reply-To: <53679992.5060404@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.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvjW7gyfRggyPT5SyWTlrAarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj2tyfrAVP2SruzfnG3MB4iLWLkZNDQsBE YvGqf+wQtpjEhXvr2boYuTiEBI4ySuyb9JYVwlnMKHFk9SUgh4ODTcBCovufNkiDiECwxMHD O1lAbGEBZ4l/hzewQ8RdJHZ97mYH6RURmMQocazzIxtIgkVAReJpaxuYzSvgC7RtHTvEgj42 iUMTtzKDLOAU0JHoXeYOUsMIdNH3U2uYQGxmAXGJW0/mM0FcKiCxZM95ZghbVOLl439Q3yhJ rNh+iRGiXkdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYRYtT i4tz042M9VKLMpOLi/Pz9PJSSzYxAiPl4JbfujsYV792PMQowMGoxMNbODk9WIg1say4MvcQ ozQHi5I4b9td72AhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjMutZyQtLlvPbu1/WTRCpusO J9u9X6++S4mXfHL2+/LUJKKCcUHSvidHzT5syhaz3prhtyfHwu6M7bRT97X9jsfcnshXcXJ1 N1dYmob79yjegrDopHMfPKQl7N3WPTmoKfuwa1ugYinXs0k7S1pWsvazxO22X7duYeIOl27Z Uz939BzalyzxRomlOCPRUIu5qDgRABTXFC11AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/D7HhQpyFAY7uxmtk4xFpsHMNqkg Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 05 May 2014 17:24:40 -0000 Hi, >> The only difficulty I see is that the IANA registry "SIP/SIPS URI=20 >> Parameters" ( >> http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#si >> p-parameters-11 >> ) is marked "Registration Procedure(s): Standards Action", and we'd=20 >> really like to have a pointer from the registry to the informational=20 >> RFC. I suppose we could just ask the IESG to make the update. > > I'm not sure I follow what you are suggesting. > > As you note, the registration procedure requires "Standards Action" and t= hat requires a "Standards > Track" RFC. IIUC an Informational RFC isn't Sta= ndards Track. Is that the point you are making? Are=20 > you suggesting that the IESG could override this? Or, is the suggestion to document the solution in an Informational RFC, but= to NOT register the parameter? Regards, Christer From nobody Mon May 5 10:32: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 87EBB1A03F7 for ; Mon, 5 May 2014 10:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 jFbSstgOMp_g for ; Mon, 5 May 2014 10:32:13 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id B1FA01A03EC for ; Mon, 5 May 2014 10:32:13 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id a1bc7635.2ab028149940.2042765.00-2407.5377258.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 05 May 2014 17:32:10 +0000 (UTC) X-MXL-Hash: 5367cb1a0e5f19de-34d4669dde9dc15d84e5276547908ae00ab6915e Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id b0bc7635.0.2042634.00-2347.5376876.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 05 May 2014 17:32:03 +0000 (UTC) X-MXL-Hash: 5367cb131e357af7-dc0de007ed8e27150cdc408566df72482f65dd1c Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s45HVtcm022427; Mon, 5 May 2014 13:31:55 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s45HViNi022137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2014 13:31:51 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (MISOUT7MSGHUB9A.itservices.sbc.com [144.151.223.62]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 5 May 2014 17:31:28 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.03.0174.001; Mon, 5 May 2014 13:31:27 -0400 From: "DOLLY, MARTIN C" To: "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgFLHsxOAAB6Qi8AGOcLbAAH2vuQ Date: Mon, 5 May 2014 17:31:27 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> In-Reply-To: <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.83.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=BfxvJMR2 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=DnKKg6jW7NIA:10 a=ofMgfj31e3cA:10 a=fxDfQciDRaQA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=wh29FQHvAAAA:8 a=I0CVDw5ZAAAA:8 ] X-AnalysisOut: [a=U6sCIiSmTFqK-Eg72GEA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:] X-AnalysisOut: [10 a=Hz7IrDYlS0cA:10 a=T0GrRU3177cA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/wYQJ7gusUH2ag7MxFOdP5y1PBX0 Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 05 May 2014 17:32:18 -0000 Dale, Thank you for responding to the list for a "private" question I sent you. Regards, Martin -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Dale R. Worl= ey Sent: Monday, May 05, 2014 9:45 AM To: dispatch@ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 > From: "DOLLY, MARTIN C" >=20 > > On May 4, 2014, at 9:38 PM, "Dale R. Worley" wrote= : > > For a long list of reasons, I > > think that the benefit from trying to handle this as a standardization > > question will be small relative to the amount of work needed. > And those reasons are? It's not clear what the general problem is for which the 3GPP solution is a specific solution. Thus, clarifying the general problem and its requirements would take considerable work. Nobody other than 3GPP has expressed that they have a problem of this nature. Thus, getting people to work on the problem may be difficult. There don't seem to be any scenarios where interoperation is needed, either between supporting and non-supporting SIP implementations or between supporting SIP implementations that use different definitions of the "call leg" structure. If all usage is within "walled gardens" where technical uniformity can be enforced administratively, there is no practical need for a global standard. Doubts have been expressed in the IETF that the current implementation is the best solution from an architectural point of view. Nonetheless, 3GPP is unlikely to obtain significant additional benefit if the IETF finds a "better" solution, and it seems 3GPP would be unlikely to change their implementation if the IETF were to decree a "better" standard. Taking all of this together, it seems that the IETF is unlikely to complete a proper standards effort for this problem and that there would be little benefit obtained from developing a proper standard. The IETF has a longstanding policy against declaring that something is a standard just because it has been implemented, so we can't declare this a standard simply because 3GPP is using it. OTOH, it would be useful to document that this is how 3GPP solves this problem. The only difficulty I see is that the IANA registry "SIP/SIPS URI Parameters" ( http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-par= ameters-11 ) is marked "Registration Procedure(s): Standards Action", and we'd really like to have a pointer from the registry to the informational RFC. I suppose we could just ask the IESG to make the update. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon May 5 14:28:29 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 30D8B1A01C1 for ; Mon, 5 May 2014 14:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 Y3ovahVwPCzS for ; Mon, 5 May 2014 14:28:26 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 626B11A011A for ; Mon, 5 May 2014 14:28:26 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta12.westchester.pa.mail.comcast.net with comcast id yKvu1n0050QuhwU5CMUNkD; Mon, 05 May 2014 21:28:22 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta02.westchester.pa.mail.comcast.net with comcast id yMUN1n00B1KKtkw3NMUNrW; Mon, 05 May 2014 21:28:22 +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 s45LSLYF031862; Mon, 5 May 2014 17:28:21 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s45LSLN5031861; Mon, 5 May 2014 17:28:21 -0400 Date: Mon, 5 May 2014 17:28:21 -0400 Message-Id: <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <53679992.5060404@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399325302; bh=9im/NPKdNWU4BofPjfQICNulVExDZptxm+tulR6zkfg=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=vzy6WzUjob5rJ+NaBAA1j/SnTmYDOhy6LLir0SmQtHt33U2mEn7Zdq53tLEMPAYDL iu6fjzAlq5RZVSTgTv7RuxxhCc2DPlITNdusBB7mNlzHyALcvbI2qLDM+yWp0iMW5n jb3zUhopUwcMLJXjPlqCK/LxeAYZRTioFUcpCjS5o00iqD+/Zxc1KqZFvgB+MlDpl6 hvEuKg07bAWSwPCH0uxz7UO2S+FZts2flQEi/7Nyh31v/KbUdo+1iAkc5Y82pByDiN pS+Qy8y9K8Zie3pdKsTEwkF8r1ZWKwIoDl9vHGisXsMrsPkTr8P97uNzu1N9+N5M3F fwPcrFFk+/GlQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/G2Eg414Z9PIsov9c6VTQfRhio68 Cc: dispatch@ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 05 May 2014 21:28:28 -0000 > From: Paul Kyzivat > > I'm not sure I follow what you are suggesting. > > As you note, the registration procedure requires "Standards Action" and > that requires a "Standards Track" RFC. IIUC an Informational RFC isn't > Standards Track. Is that the point you are making? Yes. If we're going to document iotl at all, it should go into the table of URI parameters. But strictly speaking, it seems that an informational RFC can't add an entry to this registry. > Are you suggesting that the IESG could override this? I don't know for certain, but it seems to me to be likely that it can, and that would be a way around the apparent problem. Dale From nobody Mon May 5 23:30: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 2118E1A071D for ; Mon, 5 May 2014 23:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_fyynbVBKGc for ; Mon, 5 May 2014 23:30:54 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 42F1D1A025A for ; Mon, 5 May 2014 23:30:54 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-f2-53688199ef1f Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 46.1D.04199.99188635; Tue, 6 May 2014 08:30:50 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Tue, 6 May 2014 08:30:48 +0200 From: Christer Holmberg To: "Dale R. Worley" , Paul Kyzivat Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAxuudP///zawCAAG22oP//+eQA//9KsDCAAg/BAIABWf9pgAJZ9Wf//+JMgAAdF7GzAAOkqAAADIn1rf//aP0A Date: Tue, 6 May 2014 06:30:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> In-Reply-To: <201405052128.s45LSLN5031861@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.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM+Jvje6sxoxggxW1FtPP/GW02PpiNYvF 0kkLWC1WbDjAajG1z9bi5YkyBzaPv+8/MHlM3v+V2ePLk5dMHkuW/ARyN85i8fhy+TNbAFsU l01Kak5mWWqRvl0CV8a677cZC5ZwViy98Z+tgfE0excjJ4eEgInEv20PoGwxiQv31rN1MXJx CAkcZZTouzWNHcJZzChx9vsh1i5GDg42AQuJ7n/aIA0iAoES27pOs4LUMAscZ5T4/rUFbJKw gLPEv8Mb2CGKXCR2fe4GGyQiMI1RYsLLvywgCRYBFYm7fR+ZQWxeAV+Jjb9vsEJsO8Imcf3A BbAEp4CDxMc1N8AmMQLd9/3UGiYQm1lAXOLWk/lMEHcLSCzZc54ZwhaVePn4HyuErShxdfpy qHodiQW7P7FB2NoSyxa+hlosKHFy5hOWCYxis5CMnYWkZRaSlllIWhYwsqxiFC1OLU7KTTcy 0kstykwuLs7P08tLLdnECIzHg1t+G+xgfPnc8RCjAAejEg9v4eT0YCHWxLLiytxDjNIcLEri vN/OugcLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYAyKii0NcvqXvIvPtv9sfb32jorv1at5 lu2YajpPRnG/aT5bZ+K2K3utgpNMZTpeBIQta0+avvnubwnnhT+06i6evlK6fyKb5MGgXcz7 05N3uU+9O6vzKUuOxV9V60nxK58ZHtu86v4KjhMneKL47ks6LP0n2VpzaLtFYPeLANma6ufn VoafXqzEUpyRaKjFXFScCABMjBx+qAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/TJnsfOCiZlgAVMi7waxOnfNRpXs Cc: "dispatch-chairs@tools.ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 06:30:56 -0000 Perhaps the chairs and/or ADs could give some guidance? Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Dale R. Worl= ey Sent: 6. toukokuuta 2014 0:28 To: Paul Kyzivat Cc: dispatch@ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 > From: Paul Kyzivat >=20 > I'm not sure I follow what you are suggesting. >=20 > As you note, the registration procedure requires "Standards Action"=20 > and that requires a "Standards Track" RFC. IIUC an Informational RFC=20 > isn't Standards Track. Is that the point you are making? Yes. If we're going to document iotl at all, it should go into the table o= f URI parameters. But strictly speaking, it seems that an informational RF= C can't add an entry to this registry. > Are you suggesting that the IESG could override this? I don't know for certain, but it seems to me to be likely that it can, and = that would be a way around the apparent problem. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue May 6 07:31:03 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 297601A0092 for ; Tue, 6 May 2014 07:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 JqGXRg66klUn for ; Tue, 6 May 2014 07:30:59 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5BF1A008D for ; Tue, 6 May 2014 07:30:58 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id u57so2607674wes.32 for ; Tue, 06 May 2014 07:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9EyTVIwVN9azEImIdkok9PRlDQHVFA8I3cBJEFu5aik=; b=n9D/JzxVfl+yyjmv/dlKmcuiRctdlrHDjeYh8lA557idkBf1gLR2Sw7tqUEQJI+4Is 6EssmLmenEYSx0HbJ3s58HOFwSqDIUebCfkn1zxXAODpdG6d7IQXHauWS/Vs0wvJpa5w aLtmA4BKFFVdeB29fRxM4B2FPxBkzPMr71tnrnF2c9VnPFErabRAwe879yYcIpiZcUjl sk9cCs77ULMdnyV67ZmGPAgh0Lydt4JbDxwYiwhU/4CZerKJfbhHDhee2fTCTp1QYz26 vjJ6aDWe6Xc9hRssZlN+Q5HpbS/ffQs/re2IIvG6MEGRr5l1Yj+QbwCWhsbxvDALRCfg ASyQ== MIME-Version: 1.0 X-Received: by 10.180.9.202 with SMTP id c10mr21309834wib.7.1399386654849; Tue, 06 May 2014 07:30:54 -0700 (PDT) Received: by 10.216.93.68 with HTTP; Tue, 6 May 2014 07:30:54 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> Date: Tue, 6 May 2014 09:30:54 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c2abda77415904f8bc18dc Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/nkbmBUeavzaouBxTaLm3am_oJX0 Cc: "dispatch@ietf.org" , "dispatch-chairs@tools.ietf.org" Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 14:31:01 -0000 --001a11c2abda77415904f8bc18dc Content-Type: text/plain; charset=UTF-8 I thinks it's a bad idea to bend the rule and allow registration of SIP URI parameters in an informational document. I haven't considered the problem you're trying to solve in detail, but ISTM that Dale had a good suggestion to use header field parameters. And, if it's unique to 3GPP, you can define a P-header field. Is there a reason why this would not work? Mary On Tue, May 6, 2014 at 1:30 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Perhaps the chairs and/or ADs could give some guidance? > > Regards, > > Christer > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Dale R. > Worley > Sent: 6. toukokuuta 2014 0:28 > To: Paul Kyzivat > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 > > > From: Paul Kyzivat > > > > I'm not sure I follow what you are suggesting. > > > > As you note, the registration procedure requires "Standards Action" > > and that requires a "Standards Track" RFC. IIUC an Informational RFC > > isn't Standards Track. Is that the point you are making? > > Yes. If we're going to document iotl at all, it should go into the table > of URI parameters. But strictly speaking, it seems that an informational > RFC can't add an entry to this registry. > > > Are you suggesting that the IESG could override this? > > I don't know for certain, but it seems to me to be likely that it can, and > that would be a way around the apparent problem. > > Dale > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --001a11c2abda77415904f8bc18dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I thinks it's a bad idea to bend the rule and allow re= gistration of SIP URI parameters in an informational document. =C2=A0 I hav= en't considered the problem you're trying to solve in detail, but I= STM that Dale had a good suggestion to use header field parameters. =C2=A0A= nd, if it's unique to 3GPP, you can define a P-header field. =C2=A0Is t= here a reason why this would not work? =C2=A0

Mary


On Tue, May 6, 2014 at 1:30 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Perhaps the chairs and/or ADs could give som= e guidance?

Regards,

Christer

-----Original Message-----
From: dispatch [mailto:dispatc= h-bounces@ietf.org] On Behalf Of Dale R. Worley
Sent: 6. toukokuuta 2014 0:28
To: Paul Kyzivat
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00

> From: Paul Kyzivat <<= a href=3D"mailto:pkyzivat@alum.mit.edu">pkyzivat@alum.mit.edu>
>
> I'm not sure I follow what you are suggesting.
>
> As you note, the registration procedure requires "Standards Actio= n"
> and that requires a "Standards Track" RFC. IIUC an Informati= onal RFC
> isn't Standards Track. Is that the point you are making?

Yes. =C2=A0If we're going to document iotl at all, it should go into th= e table of URI parameters. =C2=A0But strictly speaking, it seems that an in= formational RFC can't add an entry to this registry.

> Are you suggesting that the IESG could override this?

I don't know for certain, but it seems to me to be likely that it can, = and that would be a way around the apparent problem.

Dale

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

--001a11c2abda77415904f8bc18dc-- From nobody Tue May 6 08:17: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 CF3241A0357 for ; Tue, 6 May 2014 08:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 EiyCAbyp8U8t for ; Tue, 6 May 2014 08:17:52 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 97E1C1A0848 for ; Tue, 6 May 2014 08:17:52 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta03.westchester.pa.mail.comcast.net with comcast id yeqf1n0061HzFnQ53fHoVZ; Tue, 06 May 2014 15:17:48 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta14.westchester.pa.mail.comcast.net with comcast id yfHo1n0061KKtkw3afHo7F; Tue, 06 May 2014 15:17:48 +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 s46FHlNe017749; Tue, 6 May 2014 11:17:47 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s46FHlL1017748; Tue, 6 May 2014 11:17:47 -0400 Date: Tue, 6 May 2014 11:17:47 -0400 Message-Id: <201405061517.s46FHlL1017748@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Mary Barnes In-reply-to: (mary.ietf.barnes@gmail.com) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399389468; bh=VJbIOVtfC80acsOHayTMJvG6xjuQvG2Qpy77Su+5YRU=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=Dpyn47WvzWyPxYrDIDFV9lMxn0rqBTPvlR9QYRTWzaYNNyL4JjnqtRIYOGICKAkME Lle5T/11yy1gp1H6lDBwEMJTKRCzamOu9lofvNJawZndBWjAASaLLghunD3XWXpj0C j7Sm36XwfNOy7DD7LuqBum/NbZz8d4W3m+VCWI/USz6U7DAG875AW+/IkaxR4oFyT9 p0YG1SDSVLEw4EudAWQUKx2yuedeh01FOKedFd4Gg744Jzt/AsSm13qwcx8kHUzQA3 Ywz4scyx4C7Kf3RzpbqGc/lsoOhRQCSGF3EDT10NNkAvbspG2HCBLGZkUN4P9MPeuO f6NMNQYLDOA3g== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/cF8oidsiBt9TsslLIv1A8_PFJow Cc: dispatch@ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 15:17:54 -0000 > From: Mary Barnes > ... use header field parameters ... Hmmm, I wouldn't have expected it, but the registration criterion for "Header Field Parameters and Parameter Values" ( http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-12 ) is "Published RFC (A standards-track RFC is NOT required)". Dale From nobody Tue May 6 08:32:56 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 F25521A0380 for ; Tue, 6 May 2014 08:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 OSED5wTAODKW for ; Tue, 6 May 2014 08:32:48 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 32B801A038C for ; Tue, 6 May 2014 08:32:48 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta05.westchester.pa.mail.comcast.net with comcast id yeRH1n0041uE5Es55fYk41; Tue, 06 May 2014 15:32:44 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta16.westchester.pa.mail.comcast.net with comcast id yfYj1n00v1KKtkw3cfYkg8; Tue, 06 May 2014 15:32:44 +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 s46FWhGo019261 for ; Tue, 6 May 2014 11:32:43 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s46FWhk5019260; Tue, 6 May 2014 11:32:43 -0400 Date: Tue, 6 May 2014 11:32:43 -0400 Message-Id: <201405061532.s46FWhk5019260@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D2ECF6D@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2ECF6D@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399390364; bh=Wry910vIf5bpFirCyyjc7aTwLRuf3awXtxhM53I2haI=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=WWbcjL/doXB7BxWXrHwujAeS6yqn4L37qsYW10CUsKbyr9Jo/Vpyn7zyhZW0aGFqQ 42a2j3uHb2AuQos9VQ5PlrLwUxLwU81dyd+K0vu6pHFoqOLEUppojdjelUsmWp2i5M u9A4p+VnJweWNlhguMFklEtglC0gBeiGK2y46vlxW6xjNfmaxfBY+R1ktzTkF6KJzN 0m5M1CGMwoV5VAs0IeQkejQnTKI/TJAUujv1mrjzPXIHy0I2YG6qaYyQT7OwthGWLp kFBXmB7SQ95FJae2wAWsIufb6egDbsMonLcqNrClHDEUskpJNtMwh4WIn/6DJ7Xxrg VeRzNzxNuO7EQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/33hOW_w7eUywZSQAbbUd8R9swdA Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 15:32:54 -0000 > From: Christer Holmberg > Or, is the suggestion to document the solution in an Informational > RFC, but to NOT register the parameter? I believe that there is significant benefit to having the parameter recorded in the registry, due to the sheer volume of 3GPP usage if nothing else. So whatever path we take should lead to a proper registration. This is one of the conveniences of P- headers, in that I don't see them as output of IETF work, but that the IETF simply catalogs work that was done by 3GPP. > From: Christer Holmberg > You have claimed that a URI parameter has to "be part of" a URI. I > disagree with that. Take a look at the existing URI parameters. For > example, do you consider the commonly used "lr" parameter being > "part of" a URI? In my opinion, it provides additional information > about the URI - in the same way as "iotl" does. I believe that the "lr" URI parameter is an architectural error, and should have been a header field parameter. > (Also note that the URI parameters (the only exception being the > user parameter) are not part of the canonical representation of the > URI). I was not aware that there is a canonical form of SIP URIs, but one is described in 3261: 10.3 Processing REGISTER Requests 5. The registrar extracts the address-of-record from the To header field of the request. If the address-of-record is not valid for the domain in the Request-URI, the registrar MUST send a 404 (Not Found) response and skip the remaining steps. The URI MUST then be converted to a canonical form. To do that, all URI parameters MUST be removed (including the user-param), and any escaped characters MUST be converted to their unescaped form. The result serves as an index into the list of bindings. The 'user' parameter is to be removed as well. As far as I've managed to track it, the only prescribed use of a canonical form is for registration lookups. On the other hand, URI parameters are included in URI comparison (19.1.4). And as far as I can tell, those rules do not lead to a canonical form, because the defined URI equality is not an equivalence relation. (That is, A can compare equal to B and also compare equal to C, but yet B does not compare equal to C.) > I don't think I have claimed that this has already been > implemented. I HAVE said, however, that 3GPP needs to for the > current release (Rel-12), so there IS a time aspect. What is the time frame in calendar terms? Would 3GPP consider "better" solutions to the problem? > But, I don't understand why the first task should be to look for > another solution, just for the sake of looking for another > solution... I take it as central to the IETF's mission to produce standards that not only work, but are as good as we can devise given the knowledge that is available. Within that mandate, minimizing complexity of a protocol ("clean architecture") is an important goal. Saying "this does actually solve the problem" is the least praise that can be given to technical work. Dale From nobody Tue May 6 08:41: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 20E7B1A0389 for ; Tue, 6 May 2014 08:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFGI9Rn7jMGI for ; Tue, 6 May 2014 08:41:05 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 32CF11A0391 for ; Tue, 6 May 2014 08:41:05 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id yfMe1n0051YDfWL53fh1rE; Tue, 06 May 2014 15:41:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id yfh11n00G3ZTu2S3gfh1FG; Tue, 06 May 2014 15:41:01 +0000 Message-ID: <5369028D.1050109@alum.mit.edu> Date: Tue, 06 May 2014 11:41:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <201405061517.s46FHlL1017748@hobgoblin.ariadne.com> In-Reply-To: <201405061517.s46FHlL1017748@hobgoblin.ariadne.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=1399390861; bh=YnjbIi5JiAxp+kC7BOdzpFildW9/xa6O8NaIO3c6kGg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BCbqjr2urI4IJQTGyW3MVdBsyZgDRH0/hNihFS3/iefllhHmZkF5GyRWZc4Y9dqnl ZEo5ehIQgrte8zwqR3DarjNw4oAjD5+f3cNTf+d5QSH4a23sKZBMZvC8n6VJHJ8m4B h5V+xbLPiYjuRxs1iEYjWh5byj4AS9fL7TGX61N47rk9iCRS6TD1by0T0IiXl9CvO0 4/LffPfiZFoV4Tmal2bAPty6j0YCbl3/hqxfiYZgRu9xz9uWSCCXOiyFEArcOiXjjC UAEjBgOzTFY0dSHMDcZtYMYLBhsRZ9EDvOsa6IYyFBvoocNEtr/Wccy562ct/QMY1h +SZWieEyIOdLg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/QVkOukKT4nCitN2-XAB6BjVbpcw Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 15:41:06 -0000 On 5/6/14 11:17 AM, Dale R. Worley wrote: >> From: Mary Barnes > >> ... use header field parameters ... > > Hmmm, I wouldn't have expected it, but the registration criterion for > "Header Field Parameters and Parameter Values" ( > http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-12 > ) is "Published RFC (A standards-track RFC is NOT required)". Convenient! So wouldn't a header field parameter for the Route, Service-Route, and Path headers do the job here? Thanks, Paul From nobody Tue May 6 08:43: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 6C5741A0870 for ; Tue, 6 May 2014 08:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ZCix2AjNP1f0 for ; Tue, 6 May 2014 08:43:39 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B226C1A086D for ; Tue, 6 May 2014 08:43:38 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so8107703wgh.2 for ; Tue, 06 May 2014 08:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KdH1cmH41vQJbxaqXlGvshM6ijkEog77Hy58kFqui8E=; b=DXibbbgmVO+WkYceZkGlF9gInc9Civ7DSsSCoK7N82v0jGaBD+96IYZcqPozStmlFD 0jB7imHXLjh7CqN6Y9S2y9Aes7LxiEUTKocDNvSwTr3UuslyVZ6El9r3ZfZX9KajUyye Gbj8hx/2ajkClG+2PtQjrybCouA5fJvF7RwLNo+OfT/HW8cd7MousYvPSt8lLlatUPOC OTA47Sw5OXMK+jloKU4rr5fcJkrGli+PMbSJibPTnS22BUtGDZNHQvlQQZEPdT29E98m qkhKypS0+7UUsKugxWqWDn6ly6/MoaUsTetE965nKLBa67BP8WVm861s4FsUxr/ajgB5 jajg== MIME-Version: 1.0 X-Received: by 10.194.203.137 with SMTP id kq9mr3078958wjc.55.1399391014421; Tue, 06 May 2014 08:43:34 -0700 (PDT) Received: by 10.216.93.68 with HTTP; Tue, 6 May 2014 08:43:34 -0700 (PDT) In-Reply-To: <201405061517.s46FHlL1017748@hobgoblin.ariadne.com> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <201405061517.s46FHlL1017748@hobgoblin.ariadne.com> Date: Tue, 6 May 2014 10:43:34 -0500 Message-ID: From: Mary Barnes To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=047d7b874f20510ce104f8bd1ca7 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/xZuP6vAraFFaxwx4aTro10sQCgo Cc: DISPATCH Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 15:43:42 -0000 --047d7b874f20510ce104f8bd1ca7 Content-Type: text/plain; charset=UTF-8 On Tue, May 6, 2014 at 10:17 AM, Dale R. Worley wrote: > > From: Mary Barnes > > > ... use header field parameters ... > > Hmmm, I wouldn't have expected it, but the registration criterion for > "Header Field Parameters and Parameter Values" ( > > http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-12 > ) is "Published RFC (A standards-track RFC is NOT required)". > [MB] Exactly. That's why I thought it would be a good option to consider, in particular noting that's where the 3GPP P-headers are registered. [/MB] > > Dale > --047d7b874f20510ce104f8bd1ca7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, May 6, 2014 at 10:17 AM, Dale R. Worley &= lt;worley@ariadne.c= om> wrote:
> From: Mary Barnes <mary.ietf.barnes@gmail.com>

> ... use header field parameters ...

Hmmm, I wouldn't have expected it, but the registration criterion for "Header Field Parameters and Parameter Values" (
http://www.iana.org/assignments/si= p-parameters/sip-parameters.xhtml#sip-parameters-12
) is "Published RFC (A standards-track RFC is NOT required)".
=
[MB] Exactly. That's why I thought it would be a good= option to consider, in particular noting that's where the 3GPP P-heade= rs are registered. [/MB]=C2=A0

Dale

--047d7b874f20510ce104f8bd1ca7-- From nobody Tue May 6 08:44: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 179791A077E for ; Tue, 6 May 2014 08:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 YhofYlFQMOtV for ; Tue, 6 May 2014 08:44:42 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9AA1A0391 for ; Tue, 6 May 2014 08:44:42 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id z12so3979197wgg.24 for ; Tue, 06 May 2014 08:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Lagk/AU5aqcOM6gIjnuhiVKb8lf4+OGWbOvwuwm5Xi8=; b=qdjeHoJaPxSQjnvU5sUCF3XkcAcRCTyvmVjG0bZ2Qjp+4i7UfGXoHfLwQFkmWNYR0O lRpQfRiwrRS2kYZagWpBQwN3zdFo+dyaougHjd5Wk4T2nWcfAnsTjlPNecrmFI6DHDlk F7WVSLR1iErQiWw4ow1/mX5o11v/0arF4wrG2xTgfoaV8LKZuK8FrJP2xFWNH34fCPvG UGrb0Q9TLxRPcvd5dtAcTmtfRozaUgCeVey43vwqcKsJubOZIH2HcloXhPxyYYU+ql39 C0+TRGRfni59kN9a7/c8tzxPpiSwNLjllgHMylRXwQ4EFLybG7iDQcc4l4XF9CKCq6U6 B3UQ== MIME-Version: 1.0 X-Received: by 10.194.203.137 with SMTP id kq9mr3083906wjc.55.1399391078175; Tue, 06 May 2014 08:44:38 -0700 (PDT) Received: by 10.216.93.68 with HTTP; Tue, 6 May 2014 08:44:38 -0700 (PDT) In-Reply-To: <5369028D.1050109@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <201405061517.s46FHlL1017748@hobgoblin.ariadne.com> <5369028D.1050109@alum.mit.edu> Date: Tue, 6 May 2014 10:44:38 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b874f201dfe1f04f8bd20c8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/ywj20S4F2JKwbTayrP6SPjyy4Mc Cc: DISPATCH Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 15:44:47 -0000 --047d7b874f201dfe1f04f8bd20c8 Content-Type: text/plain; charset=UTF-8 On Tue, May 6, 2014 at 10:41 AM, Paul Kyzivat wrote: > On 5/6/14 11:17 AM, Dale R. Worley wrote: > >> From: Mary Barnes >>> >> >> ... use header field parameters ... >>> >> >> Hmmm, I wouldn't have expected it, but the registration criterion for >> "Header Field Parameters and Parameter Values" ( >> http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip- >> parameters-12 >> ) is "Published RFC (A standards-track RFC is NOT required)". >> > > Convenient! > > So wouldn't a header field parameter for the Route, Service-Route, and > Path headers do the job here? > [MB] That's possible as well. We would just need to make sure what's being defined is general or it's clearly specified in which contexts it would be used. [/MB] > > Thanks, > Paul > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --047d7b874f201dfe1f04f8bd20c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 6, 2014 at 10:41 AM= , Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 5= /6/14 11:17 AM, Dale R. Worley wrote:
From: Mary Barnes <mary.ietf.barnes@gmail.com>

... use header field parameters ...

Hmmm, I wouldn't have expected it, but the registration criterion for "Header Field Parameters and Parameter Values" (
http://www.iana.org/assignm= ents/sip-parameters/sip-parameters.xhtml#sip-parameters-12
) is "Published RFC (A standards-track RFC is NOT required)".

Convenient!

So wouldn't a header field parameter for the Route, Service-Route, and = Path headers do the job here?

=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

--047d7b874f201dfe1f04f8bd20c8-- From nobody Tue May 6 09:06: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 3B9081A00A2 for ; Tue, 6 May 2014 09:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ehzxvjitP58 for ; Tue, 6 May 2014 09:06:02 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA221A0875 for ; Tue, 6 May 2014 09:05:56 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta10.westchester.pa.mail.comcast.net with comcast id yf4f1n0021ap0As5Ag5t6W; Tue, 06 May 2014 16:05:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id yg5s1n00h3ZTu2S3ig5skG; Tue, 06 May 2014 16:05:53 +0000 Message-ID: <53690860.1060003@alum.mit.edu> Date: Tue, 06 May 2014 12:05:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Mary Barnes References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <201405061517.s46FHlL1017748@hobgoblin.ariadne.com> <5369028D.1050109@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399392353; bh=vezxsGGDqZiYZUxGFifXWNJ47VX7GPaAAcxF864N9MI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LSc/WvoM9dLn5T17k+5I7OlU68ZZ7uvMT+IGB5yElCpvUmC3WN+CY8UDg+GUTxhdj /Rqz24bDmQZ+a0lC6jl90nYL+y6yX/SG94FUvkPQV1aL/XKTM1DzqEmFDJdPnEa6VC JmxEKwC/cmXfsO7NesnvJqVIMie7u+UteelpyWdNKXq+hMuPpIuqpc44I5eC03jPes aZhTvz3SLi5fir3LdHHKqVTPh8iehn1vIvlDlZjQJB1Bsfl8hd4bvqY8cI+Wf846F6 ubys0v86LJXTIMOli6vXK/QwK9vLIwKL6PeFle4xGeLjhu649YglofSEzpi2WM7OtZ sCz0raNbg69lw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/3vFSTOHLXZk29pFnlIQ4avB-xNY Cc: DISPATCH Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 16:06:07 -0000 On 5/6/14 11:44 AM, Mary Barnes wrote: > On Tue, May 6, 2014 at 10:41 AM, Paul Kyzivat > wrote: > > On 5/6/14 11:17 AM, Dale R. Worley wrote: > > From: Mary Barnes > > > > ... use header field parameters ... > > > Hmmm, I wouldn't have expected it, but the registration > criterion for > "Header Field Parameters and Parameter Values" ( > http://www.iana.org/__assignments/sip-parameters/__sip-parameters.xhtml#sip-__parameters-12 > > ) is "Published RFC (A standards-track RFC is NOT required)". > > > Convenient! > > So wouldn't a header field parameter for the Route, Service-Route, > and Path headers do the job here? > > [MB] That's possible as well. We would just need to make sure what's > being defined is general or it's clearly specified in which contexts it > would be used. [/MB] The reason I suggested this is that the current draft implies that this might be used in a Service-Route it order to get it into Route headers of subsequent requests from the UA. If it is intended only for 3gpp, then it should clearly specify this scope in the draft. Thanks, Paul From nobody Tue May 6 09:11: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 A58F61A0429 for ; Tue, 6 May 2014 09:11:09 -0700 (PDT) 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, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOh8vEPLtxfv for ; Tue, 6 May 2014 09:11:07 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id C40A21A0398 for ; Tue, 6 May 2014 09:11:01 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s46GAus9021807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 May 2014 11:10:57 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s46GAtlf025368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 6 May 2014 18:10:56 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.4]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 6 May 2014 18:10:56 +0200 From: "DRAGE, Keith (Keith)" To: "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: AQHPYyek1AbPA/iB90G/aKEukDfpPJsqaXVugAAeiVyAATIhAIAICVRQ Date: Tue, 6 May 2014 16:10:55 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B196278@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu>, <201404301901.s3UJ1Awf013148@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2E795B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2E795B@ESESSMB209.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.40] 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/P3r40efgj2GcvBaCXYY3uCQAgEA Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 16:11:09 -0000 At the moment there is no normative statement in 3GPP specifications. As id= entified in another mail, there is a technical report examining the possibi= lities, and there is an agreed work item with 3GPP timescales to perform th= e normative work. So yes, providing the response is to reasonably imminent, then any mechanis= m could be supported that fulfils the requirements. Keith=20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf=20 > Of Christer Holmberg > Sent: 01 May 2014 16:21 > To: Dale R. Worley; dispatch@ietf.org > Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 >=20 > Hi, >=20 > >As far as I can tell, the draft refers to "signaling path",=20 > but it does=20 > >not distinguish whether the signaling path is the routing of=20 > a single=20 > >dialog, or whether it is broken into multiple dialogs by B2BUAs. I=20 > >don't think this changes the proposal technologically, but it should=20 > >probably be stated explicitly somewhere. It *is* a=20 > requirement of the=20 > >solution. >=20 > Sure, we can add text about that. >=20 > >It seems that the intention is that at any point, a progressing=20 > >dialog-establishing or out-of-dialog request is labeled=20 > regarding which=20 > >call leg it is within by the iotl parameter of the URI=20 > currently used=20 > >for routing (the topmost Route or the request URI). This is a bit=20 > >incorrect categorically, because: > > > >1. it's not a property of the destination, its a property of the > > dialog, or part of the dialog >=20 > It depends on the traffic leg. Some traffic legs end at the=20 > destination. >=20 > >2. overlooking that, it's not really a property of the URI, its a > > modifier of how the URI is *used* >=20 > I am not really sure what you mean by that. We are not=20 > suggesting any changes to how URIs are used. The parameter=20 > simply provides additional information to the consumer of the URI. >=20 > >(1) suggests that there should be a separate header to label the=20 > >request. But that might be even more complex to define in=20 > order to be=20 > >able to have a single dialog contain several call legs. > > > >(2) suggests that the iotl data should not be a URI parameter, but=20 > >rather a header parameter. The Route header has header=20 > parameters, but=20 > >the request-URI doesn't; I suppose the analogous item is the=20 > To header,=20 > >which does have header parameters. >=20 > The parameter can, based on the use-case, be used both in the=20 > SIP URI of a Route header, or in the Request-URI. >=20 > Regards, >=20 > Christer > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From nobody Tue May 6 09:11: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 3856B1A087E for ; Tue, 6 May 2014 09:11:14 -0700 (PDT) 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, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTwyqqbkq_Rm for ; Tue, 6 May 2014 09:11:10 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 56E9B1A01A5 for ; Tue, 6 May 2014 09:11:03 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s46GAutK005451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 May 2014 11:10:57 -0500 (CDT) 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 s46GAtDh003352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 May 2014 18:10:55 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.4]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 6 May 2014 18:10:56 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: AQHPaTftqayulU54D0OTz3ELt6ofspszqor5///kqYCAACatgA== Date: Tue, 6 May 2014 16:10:54 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B196273@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <201405061517.s46FHlL1017748@hobgoblin.ariadne.com> <5369028D.1050109@alum.mit.edu> In-Reply-To: <5369028D.1050109@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.40] 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/SZvQWjgVikROBDSMI8m4yKKGM-4 Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 16:11:14 -0000 I don't think we should be selecting a solution on the basis of what is the= most convenient approval mechanism. I think we should select the correct mechasism for performing this function= ality, and then worry about the approval regime. I am not convinced the mec= hanism here need to be totally defined as an IMS specific - without the nam= es of particular types of interface, the mechanism becomes fairly general p= urpose and could be useful for other SIP routeing networks outside IMS - in= other words the mechanism could well be justified on standards track on th= at basis, but the registration of types of interface could be on a first co= me first served basis outside of the RFC structure. Regards Keith=20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: 06 May 2014 16:41 > To: dispatch@ietf.org > Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 >=20 > On 5/6/14 11:17 AM, Dale R. Worley wrote: > >> From: Mary Barnes > > > >> ... use header field parameters ... > > > > Hmmm, I wouldn't have expected it, but the registration=20 > criterion for=20 > > "Header Field Parameters and Parameter Values" ( > >=20 > http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#si > > p-parameters-12 > > ) is "Published RFC (A standards-track RFC is NOT required)". >=20 > Convenient! >=20 > So wouldn't a header field parameter for the Route,=20 > Service-Route, and Path headers do the job here? >=20 > Thanks, > Paul >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From nobody Tue May 6 09:11: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 9299F1A0888 for ; Tue, 6 May 2014 09:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yms97P_M93wR for ; Tue, 6 May 2014 09:11:10 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 6B09F1A02F4 for ; Tue, 6 May 2014 09:11:03 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s46GAs99021786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 May 2014 11:10:56 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s46GAqwu025242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 May 2014 18:10:54 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.4]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 6 May 2014 18:10:54 +0200 From: "DRAGE, Keith (Keith)" To: Mary Barnes , Christer Holmberg Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: AQHPaTftqayulU54D0OTz3ELt6ofspszr9hg Date: Tue, 6 May 2014 16:10:53 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B196261FR712WXCHMBA11zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/thH18N9IcIllI-6Yr_kkjFX0z4g Cc: "dispatch-chairs@tools.ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 16:11:18 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B196261FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is worth noting that some extensive analysis of the problem was performe= d in 3GPP over the pros and cons of various options. That document is available at: http://www.3gpp.org/DynaReport/24802.htm I'm sure 3GPP participants would welcome comment, criticism or agreement wi= th any part of that document. I do not guarantee that document will be upda= ted as the study is regarded as essentially complete, but I would expect in= put to be reflected in ongoing work and proposals. I'm fairly confident that as the issue is currently understood, it is infor= mation that relates to a URI, not to a specific header field or a request. regards Keith ________________________________ From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 06 May 2014 15:31 To: Christer Holmberg Cc: dispatch@ietf.org; dispatch-chairs@tools.ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 I thinks it's a bad idea to bend the rule and allow registration of SIP URI= parameters in an informational document. I haven't considered the proble= m you're trying to solve in detail, but ISTM that Dale had a good suggestio= n to use header field parameters. And, if it's unique to 3GPP, you can def= ine a P-header field. Is there a reason why this would not work? Mary On Tue, May 6, 2014 at 1:30 AM, Christer Holmberg > wrote: Perhaps the chairs and/or ADs could give some guidance? Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: 6. toukokuuta 2014 0:28 To: Paul Kyzivat Cc: dispatch@ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 > From: Paul Kyzivat > > > I'm not sure I follow what you are suggesting. > > As you note, the registration procedure requires "Standards Action" > and that requires a "Standards Track" RFC. IIUC an Informational RFC > isn't Standards Track. Is that the point you are making? Yes. If we're going to document iotl at all, it should go into the table o= f URI parameters. But strictly speaking, it seems that an informational RF= C can't add an entry to this registry. > Are you suggesting that the IESG could override this? I don't know for certain, but it seems to me to be likely that it can, and = that would be a way around the apparent problem. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_949EF20990823C4C85C18D59AA11AD8B196261FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
It is worth noting that some exte= nsive analysis of the problem was performed in 3GPP over the pros and cons = of various options.
 
That document is available at:
 
 
I'm sure 3GPP participants would welcome comment, criticism = or agreement with any part of that document. I do not guarantee that docume= nt will be updated as the study is regarded as essentially complete, but I would expect input to be reflected in ongoi= ng work and proposals.
 
I'm fairly confident that as the issue is currently understo= od, it is information that relates to a URI, not to a specific header field= or a request.
 
regards
 
Keith
 =

From: dispatch [mailto:dispatch-bou= nces@ietf.org] On Behalf Of Mary Barnes
Sent: 06 May 2014 15:31
To: Christer Holmberg
Cc: dispatch@ietf.org; dispatch-chairs@tools.ietf.org
Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00
I thinks it's a bad idea to bend the rule and allow regist= ration of SIP URI parameters in an informational document.   I haven't= considered the problem you're trying to solve in detail, but ISTM that Dal= e had a good suggestion to use header field parameters.  And, if it's unique to 3GPP, you can define a P-header f= ield.  Is there a reason why this would not work?  

Mary


On Tue, May 6, 2014 at 1:30 AM, Christer Holmber= g <chr= ister.holmberg@ericsson.com> wrote:
Perhaps the chairs and/or ADs could give some guidance?

Regards,

Christer

-----Original Message-----
From: dispatch [mailto:dispatc= h-bounces@ietf.org] On Behalf Of Dale R. Worley
Sent: 6. toukokuuta 2014 0:28
To: Paul Kyzivat
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00

> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
>
> I'm not sure I follow what you are suggesting.
>
> As you note, the registration procedure requires "Standards Actio= n"
> and that requires a "Standards Track" RFC. IIUC an Informati= onal RFC
> isn't Standards Track. Is that the point you are making?

Yes.  If we're going to document iotl at all, it should go into the ta= ble of URI parameters.  But strictly speaking, it seems that an inform= ational RFC can't add an entry to this registry.

> Are you suggesting that the IESG could override this?

I don't know for certain, but it seems to me to be likely that it can, and = that would be a way around the apparent problem.

Dale

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

--_000_949EF20990823C4C85C18D59AA11AD8B196261FR712WXCHMBA11zeu_-- From nobody Tue May 6 09: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 312C61A0185 for ; Tue, 6 May 2014 09:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND8gXg8icfXY for ; Tue, 6 May 2014 09:33:23 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 0542A1A017E for ; Tue, 6 May 2014 09:33:22 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta13.westchester.pa.mail.comcast.net with comcast id ye3A1n0050QuhwU5DgZKFc; Tue, 06 May 2014 16:33:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id ygZJ1n0143ZTu2S3NgZJpZ; Tue, 06 May 2014 16:33:19 +0000 Message-ID: <53690ECE.4050901@alum.mit.edu> Date: Tue, 06 May 2014 12:33:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , "dispatch@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <201405061517.s46FHlL1017748@hobgoblin.ariadne.com> <5369028D.1050109@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B196273@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B196273@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=1399393999; bh=OjvqOrUpwjnu2+g4vtRLGkadG/wbCnxYJJO4cj5C1vs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OV7mfpoOgQzVNB/NK/0JCOcYgigphyjRQJSITJvHmzD9U7nz0QsAKykXXun3cC7Nl Qke94S6KsX7gpyizPBNSZO55W1h7vLj3pjPgTNOs/+J9LkBPGhGqtd1LbRwZYh5sqN cumhRzjY2jg0R9qPCcaxfPIclWsQ0Bhq6CfsKGZkMHMFJ/cWV6WrUy/L3Uu5TO7cKY pwpb5XqPpbNcRLLuBYDDq/EBarXncsPp5jr8w6UZfVADrIrf0noZ4CE+Ck1G3scVu7 nbI+jDgisbXFkDNwTyyGQbu3ABcVB/LHK06RYr3ep8ReQa2c4o7vFs76YXp7CXPR9Y NJeoPQgzRXJBQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/Bc0lXnSoBHtxSXkReCQI8rdcLdw Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 16:33:24 -0000 On 5/6/14 12:10 PM, DRAGE, Keith (Keith) wrote: > I don't think we should be selecting a solution on the basis of what is the most convenient approval mechanism. > I think we should select the correct mechasism for performing this functionality, and then worry about the approval regime. I hear you. But the question is whether you can get sufficient support to work on a standards track document that is only of interest to 3gpp. If not, then you need to do something you can get done. > I am not convinced the mechanism here need to be totally defined as an IMS specific - without the names of particular types of interface, the mechanism becomes fairly general purpose and could be useful for other SIP routeing networks outside IMS - in other words the mechanism could well be justified on standards track on that basis, but the registration of types of interface could be on a first come first served basis outside of the RFC structure. In principle I agree with you. But then you need to take on the job of making the case that this is of broader relevance. I've been asking questions in the hope of teasing out what that might be, but so far I can't see any general use. Thanks, Paul > Regards > > Keith > >> -----Original Message----- >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 06 May 2014 16:41 >> To: dispatch@ietf.org >> Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 >> >> On 5/6/14 11:17 AM, Dale R. Worley wrote: >>>> From: Mary Barnes >>> >>>> ... use header field parameters ... >>> >>> Hmmm, I wouldn't have expected it, but the registration >> criterion for >>> "Header Field Parameters and Parameter Values" ( >>> >> http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#si >>> p-parameters-12 >>> ) is "Published RFC (A standards-track RFC is NOT required)". >> >> Convenient! >> >> So wouldn't a header field parameter for the Route, >> Service-Route, and Path headers do the job here? >> >> Thanks, >> Paul >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From nobody Tue May 6 09:44:04 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 999B31A0177 for ; Tue, 6 May 2014 09:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tqwk11HGP2sH for ; Tue, 6 May 2014 09:44:00 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 24D451A0173 for ; Tue, 6 May 2014 09:44:00 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta05.westchester.pa.mail.comcast.net with comcast id ygRS1n00C1GhbT855gjwis; Tue, 06 May 2014 16:43:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id ygjv1n00u3ZTu2S3TgjwFB; Tue, 06 May 2014 16:43:56 +0000 Message-ID: <5369114B.20907@alum.mit.edu> Date: Tue, 06 May 2014 12:43:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B196261@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=1399394636; bh=XzN/hzx7eXtmJ236pjDAD7Cix0OmRBozeiEyFucp4J0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=vm6MXZ/XB8HmNIXkv+OWoPopJ0gctf1TPy4H49G6xIY1BgnHvPcV/M3NbEKpXj2N1 AjxPWC4M2SAbD2TcajQgK3KI478SL3LPZjFL6J/jo3laF3+L+mnOrY4tup/5nKIfSU FXJjOkHPFZL5pAcccjTnczJeVQO3OJQtweh3aou81O/U7mATL4ti52XTRgPQ1UgLLa KmqKQTSYbYu6azm0P9Rsg7/5nUF3TcyMGJROguF4EGlFntEG0N4I5a2n52VEYf7vkY dXxZwjMzU2XsbPfx8lUDnpiJXsmP/bJpxTYwLroeT29aMwwiIjULhmZZbgWEElphuY vdjdfv+HSNhKA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/JCXRgdDo_dR_xgXteGZjfq2SEeg Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 16:44:01 -0000 On 5/6/14 12:10 PM, DRAGE, Keith (Keith) wrote: > It is worth noting that some extensive analysis of the problem was > performed in 3GPP over the pros and cons of various options. > That document is available at: > http://www.3gpp.org/DynaReport/24802.htm > I'm sure 3GPP participants would welcome comment, criticism or agreement > with any part of that document. OK. I just took a quick look. (I'm not highly motivated to read through the whole thing in depth.) I see that a number of alternatives were considered, but those did not include a header field parameter for Route, Service-Route and Path. The key seems to be Table 7.3.3.1 (Evaluation of compliance with the requirements in annex B). This table seems to justify the choice of a URI parameter. But I don't find any explanation for how evaluation of each alternative against each of the requirements was done. The values in the table aren't obviously correct to me. AFAICT my header parameter suggestion would get the same evaluation as the URI parameter does. Thanks, Paul > I do not guarantee that document will be > updated as the study is regarded as essentially complete, but I would > expect input to be reflected in ongoing work and proposals. > I'm fairly confident that as the issue is currently understood, it is > information that relates to a URI, not to a specific header field or a > request. > regards > Keith > __ > > ------------------------------------------------------------------------ > *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of > *Mary Barnes > *Sent:* 06 May 2014 15:31 > *To:* Christer Holmberg > *Cc:* dispatch@ietf.org; dispatch-chairs@tools.ietf.org > *Subject:* Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 > > I thinks it's a bad idea to bend the rule and allow registration of > SIP URI parameters in an informational document. I haven't > considered the problem you're trying to solve in detail, but ISTM > that Dale had a good suggestion to use header field parameters. > And, if it's unique to 3GPP, you can define a P-header field. Is > there a reason why this would not work? > > Mary > > > On Tue, May 6, 2014 at 1:30 AM, Christer Holmberg > > wrote: > > Perhaps the chairs and/or ADs could give some guidance? > > Regards, > > Christer > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org > ] On Behalf Of Dale R. Worley > Sent: 6. toukokuuta 2014 0:28 > To: Paul Kyzivat > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 > > > From: Paul Kyzivat > > > > > I'm not sure I follow what you are suggesting. > > > > As you note, the registration procedure requires "Standards > Action" > > and that requires a "Standards Track" RFC. IIUC an > Informational RFC > > isn't Standards Track. Is that the point you are making? > > Yes. If we're going to document iotl at all, it should go into > the table of URI parameters. But strictly speaking, it seems > that an informational RFC can't add an entry to this registry. > > > Are you suggesting that the IESG could override this? > > I don't know for certain, but it seems to me to be likely that > it can, and that would be a way around the apparent problem. > > Dale > > _______________________________________________ > 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 May 6 09:59: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 E32021A0185 for ; Tue, 6 May 2014 09:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iNrsDDyJVMJv for ; Tue, 6 May 2014 09:59:26 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDEA1A0175 for ; Tue, 6 May 2014 09:59:26 -0700 (PDT) X-AuditID: c1b4fb3a-f79106d0000013ca-11-536914e9e113 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 87.80.05066.9E419635; Tue, 6 May 2014 18:59:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Tue, 6 May 2014 18:59:21 +0200 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: AQHPaTfK+XDW89DjUkeYlKBaW9iAB5szqkaR///k7YCAADctIA== Date: Tue, 6 May 2014 16:59:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2EEC9D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <201405061517.s46FHlL1017748@hobgoblin.ariadne.com> <5369028D.1050109@alum.mit.edu> In-Reply-To: <5369028D.1050109@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+Jvje5Lkcxgg68TjS2WTlrAarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjzspDrAXzWCs+b21hamBcwtLFyMkhIWAi cWXSRihbTOLCvfVsXYxcHEICRxklNs36wwaSEBJYzChxf3Z5FyMHB5uAhUT3P22QsIhAsMTB wzvBeoUFnCS23NnJChF3lvjU/ZIFwnaSuNN+DmwMi4CKxOz7C5lAbF4BX4kfN6ayQ+xazCEx t/cKG8h8TgEdiT3Pg0BqGIHu+X5qDVg9s4C4xK0n85kg7hSQWLLnPDOELSrx8vE/VghbSWLR 7c9Q9ToSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKFqcWlyc m25kpJdalJlcXJyfp5eXWrKJERglB7f8ttrBePC54yFGAQ5GJR7eB68ygoVYE8uKK3MPMUpz sCiJ805a5B4sJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdHaOFBH2PKWxN7Ta/Uf/JxbcLnn 0ye1K30uLbpfXr/TEDJ5zLZUrXeWzYLJ/5mfXGA1fDhBlNH3+UJpvX4OmfmlJSszF/I9upRT wWliZqrLfv28slmaz7+XUmf0j858HFXm+HKn3+YVaVr/53oY3+e+Gfzt8FGHD5wifIu5GIV0 HFMqz7z9IqzEUpyRaKjFXFScCAACwokscwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/WEx-co06BTZZl4qsXaNCR9duAtI Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 16:59:28 -0000 Hi, >>> From: Mary Barnes >> >>> ... use header field parameters ... >> >> Hmmm, I wouldn't have expected it, but the registration criterion for=20 >> "Header Field Parameters and Parameter Values" ( >> http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#si >> p-parameters-12 >> ) is "Published RFC (A standards-track RFC is NOT required)". > > Convenient! > > So wouldn't a header field parameter for the Route, Service-Route, and Pa= th headers do the job=20 > here? No, because (as we have discussed) there are cases where the parameter is a= ssociated with the Request-URI. Regards, Christer From nobody Tue May 6 10:09: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 5E4C71A0206 for ; Tue, 6 May 2014 10:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUYBav16tCdO for ; Tue, 6 May 2014 10:09:51 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D1F701A01CE for ; Tue, 6 May 2014 10:09:50 -0700 (PDT) X-AuditID: c1b4fb25-f798c6d000001521-3e-5369175a9c7f Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B0.5B.05409.A5719635; Tue, 6 May 2014 19:09:46 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0174.001; Tue, 6 May 2014 19:09:46 +0200 From: Christer Holmberg To: "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAxuudP///zawCAAG22oP//+eQA//9KsDCAAg/BAIABWf9pgAJZ9Wf//+JMgAAdF7GzAAOkqAD//+A7kP/+TO1q//yBiZA= Date: Tue, 6 May 2014 17:09:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2EECDD@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2ECF6D@ESESSMB209.ericsson.se> <201405061532.s46FWhk5019260@hobgoblin.ariadne.com> In-Reply-To: <201405061532.s46FWhk5019260@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+NgFnrILMWRmVeSWpSXmKPExsUyM+JvjW6UeGawwf81yhZLJy1gtXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgyng6dTJrQSdrxYYNW9gaGP8ydzFyckgImEi8 utHJCGGLSVy4t56ti5GLQ0jgKKPEnK4dYAkhgcWMEtPv+3YxcnCwCVhIdP/TBgmLCIRIfJ4G 0Sss4Czx7/AGdoi4i8Suz93sIHNEBOYxStzb8ANsGYuAisSmbX1gDbwCvhK/fnxhgVjWwS6x /WMfE0iCU8BBorNxDlgRI9BF30+tAYszC4hL3HoynwniUgGJJXvOQ30gKvHy8T9WCFtJYtHt z1D1OhILdn9ig7C1JZYtfM0MsVhQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcUoWpxanJSb bmSsl1qUmVxcnJ+nl5dasokRGCcHt/xW3cF4+Y3jIUYBDkYlHt4HrzKChVgTy4orcw8xSnOw KInzfrnlEywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsWqqyIqe99Ix2XI/nWOkswojrurY uj2YO3Gpw+Ual5aCPz435OLvqP+7s3Cutqqj0qfrkqdZmNekLpjjwTbF55BLQCnfmriPb10c +38tvWFVlFf57eqFgON5FZc1muQXbZGo+dlqVX1ktcPZvR4xt/nF/06/Y7tgsaEK+8r5Ew6X zLkVr/arVomlOCPRUIu5qDgRAOPp7Yp0AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/-U83res6zgXSM6PTNUCGXHvx5eg Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 17:09:52 -0000 Hi, >> You have claimed that a URI parameter has to "be part of" a URI. I=20 >> disagree with that. Take a look at the existing URI parameters. For=20 >> example, do you consider the commonly used "lr" parameter being "part=20 >> of" a URI? In my opinion, it provides additional information about the=20 >> URI - in the same way as "iotl" does. > > I believe that the "lr" URI parameter is an architectural error, and shou= ld have=20 > been a header field parameter. "lr" is just one example. Please take a look at the IANA list, and see whet= her you think all the other parameters are "part of" the URI... Regards, Christer From nobody Tue May 6 10:29:42 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 7DA0E1A0196 for ; Tue, 6 May 2014 10:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL4czFb_EQHi for ; Tue, 6 May 2014 10:29:40 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9141A0206 for ; Tue, 6 May 2014 10:29:40 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-3b-53691bff9a2f Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6A.93.04714.FFB19635; Tue, 6 May 2014 19:29:35 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Tue, 6 May 2014 19:29:35 +0200 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: AQHPaTfK+XDW89DjUkeYlKBaW9iAB5szl4uAgAAJO4CAAC3WoA== Date: Tue, 6 May 2014 17:29:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> In-Reply-To: <5369114B.20907@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+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvje5/6cxgg5fzLCyWTlrAarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSujp20pY8E8loolq66yNDCuZ+5i5OSQEDCR eNx+khXCFpO4cG89WxcjF4eQwFFGif5nPxghnMWMEnvfNwJVcXCwCVhIdP/TBmkQEQiWOHh4 JwuILSzgJLHlzk5WiLizxKfulywQtpPEtXU/wJaxCKhIzLr4D8zmFfCV+DH7FCvE/FkcEreO PQNLcApoSUy+t5wNxGYEuuj7qTVMIDazgLjErSfzmSAuFZBYsuc81AeiEi8f/4P6QEli0e3P UPU6Egt2f2KDsLUlli18DbVYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKFqcWlycm25k rJdalJlcXJyfp5eXWrKJERgpB7f81t3BuPq14yFGAQ5GJR7eB68ygoVYE8uKK3MPMUpzsCiJ 87bd9Q4WEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwDhp4YfepIMpP7/crk879OLq3yOCrzjv mVZrJW/xSIv10c7ZpF32NHWp9IU9evxTle8zfMoXnDrhq2e8zPyzSUKK/5xMe//8M4r/v0RX adIzjzX/9/aWMVQtLD2w5FNcf/sntz9eUUZtmx/kFxp+3Gn9XuXmR0cL1lJJj/CzmfeyFWp6 juVcsFViKc5INNRiLipOBACizGJGdQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/sKuqvi4ZDvxytASQ-hH4fqxnC-A Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 17:29:41 -0000 Hi, >The key seems to be Table 7.3.3.1 (Evaluation of compliance with the requi= rements in annex B). >This table seems to justify the choice of a URI param= eter. But I don't find any explanation for how >evaluation of each alternat= ive against each of the requirements was done. The values in the table >are= n't obviously correct to me. AFAICT my header parameter suggestion would ge= t the same >evaluation as the URI parameter does. It does not work if the iotl is associated with the Request-URI. Regards, Christer From nobody Tue May 6 10:45: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 52CC91A01C4 for ; Tue, 6 May 2014 10:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQdxI4sXAIVD for ; Tue, 6 May 2014 10:45:30 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9088A1A01AE for ; Tue, 6 May 2014 10:45:29 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-2f-53691fb49540 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 59.A8.04199.4BF19635; Tue, 6 May 2014 19:45:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Tue, 6 May 2014 19:45:24 +0200 From: Christer Holmberg To: Paul Kyzivat , "DRAGE, Keith (Keith)" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: AQHPaTfK+XDW89DjUkeYlKBaW9iAB5szqkaR///k7YCAAAhZAIAABkIAgAAxxhA= Date: Tue, 6 May 2014 17:45:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2EEDD6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <201405061517.s46FHlL1017748@hobgoblin.ariadne.com> <5369028D.1050109@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B196273@FR712WXCHMBA11.zeu.alcatel-lucent.com> <53690ECE.4050901@alum.mit.edu> In-Reply-To: <53690ECE.4050901@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+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvje5W+cxgg9a3jBZLJy1gtXjaeJbR YsWGA6wOzB6tz/ayevx9/4HJY8mSn0wBzFFcNimpOZllqUX6dglcGeue7WEreMpSsXnHNtYG xnvMXYycHBICJhKbp1xhgbDFJC7cW8/WxcjFISRwlFFiZcdOJghnMaPE55lTGbsYOTjYBCwk uv9pg8RFBHoYJX5s3QnWLSzgJLHlzk5WEFtEwFniU/dLFgjbT+LxrA9g21gEVCRmP37HCjKH V8BXYt4dSRBTSKCPQ+KHGojJKaAj8baPB6SYEeic76fWMIHYzALiEreezGeCOFNAYsme81Dn i0q8fPyPFcJWklh0+zNUvY7Egt2f2CBsbYllC1+D1fMKCEqcnPmEZQKj6CwkY2chaZmFpGUW kpYFjCyrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQLj5uCW3wY7GF8+dzzEKMDBqMTD+/BV RrAQa2JZcWXuIUZpDhYlcd5vZ92DhQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCGz30apRSY /NvdcWGr/Y7QAv3jWjOm11UKHzTZ9n5b25E5hgcLz7U1TxJXDhf8XrxVXC1V3GnelsKmsMez Cxg6/MUeMNidzuF3OfBcTXJiasLqvbahi7dvkTrhXfnnc9+cpXauXgXfcsLP/3i1VFJu2TXt nWtvvJgp9Pq+5cnI+vWXLY0WcroosRRnJBpqMRcVJwIAZ8DI0XwCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/hpDSa4DS-SnAEZSFnmmFcxUZ8TE Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 17:45:31 -0000 Hi, >> I think we should select the correct mechasism for performing this=20 >> functionality, and then worry about the approval regime. > > I hear you. But the question is whether you can get sufficient support to= =20 > work on a standards track document that is only of interest to 3gpp.=20 Well, that's quite obvious - it's difficult for many people to find time ev= en for things they DO support :) Having said that, I think e.g. YOU have given very useful comments. And, there is support for this in the 3GPP community, which is as good as a= ny other support. Regards, Christer From nobody Tue May 6 11:10: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 017E11A0196 for ; Tue, 6 May 2014 11:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkawRgcFtKVy for ; Tue, 6 May 2014 11:10:23 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id EB4AE1A0192 for ; Tue, 6 May 2014 11:10:22 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta03.westchester.pa.mail.comcast.net with comcast id ygoQ1n0010QuhwU53iAKRp; Tue, 06 May 2014 18:10:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id yiAJ1n00c3ZTu2S3NiAJjE; Tue, 06 May 2014 18:10:19 +0000 Message-ID: <5369258A.6050005@alum.mit.edu> Date: Tue, 06 May 2014 14:10:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Christer Holmberg , "dispatch@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2EED5E@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=1399399819; bh=Fhnv/4eRp8rQ80IL3wOBmwWwJVfprRK5cz1Tx/1H9Gc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Kbk/ITNzFI7BjRzBHeqQB/Hlc/aZdWH58tLFRZiZmfD18sn1ZbFeSHfqVrIJHaknt FEoEpbOnjX0aC8xtR7yMHSKvNomgu2PMKyLCzAHZ/nbA98KaNIoN3L/a4gK/FTbEEx 2qD9dRPIEBvNXHqYP0ZY4+loMHrmrd+SLH3PkVXmsVQMlQhqJjWKipDynIbuGQMbJC Wn5H6ah7pwfo0mVsXCFR0zSZP91osurF7YggWLRh6uROO0IEGpf4v/Gjn2y9r5oRWb gyXioffxHLOji+C/dtQJJBwOa6sOJr0bGMyDk0ADruSFnadQTO683tvafhE0Kbboux s6QFZyQ1Zi3Eg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/ts7t7oO-I0DM08SY7n0vGJNoORI Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 18:10:24 -0000 On 5/6/14 1:29 PM, Christer Holmberg wrote: > Hi, > >> The key seems to be Table 7.3.3.1 (Evaluation of compliance with the requirements in annex B). >This table seems to justify the choice of a URI parameter. But I don't find any explanation for how >evaluation of each alternative against each of the requirements was done. The values in the table >aren't obviously correct to me. AFAICT my header parameter suggestion would get the same >evaluation as the URI parameter does. > > It does not work if the iotl is associated with the Request-URI. There is nothing to prevent having a Route header having the same URI as the R-URI. Thanks, Paul From nobody Tue May 6 11:16:32 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 D37E61A0196 for ; Tue, 6 May 2014 11:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lnp0wOP53pZo for ; Tue, 6 May 2014 11:16:30 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 1759E1A0234 for ; Tue, 6 May 2014 11:16:30 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta03.westchester.pa.mail.comcast.net with comcast id yhdR1n0070QuhwU53iGSfx; Tue, 06 May 2014 18:16:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id yiGM1n00J3ZTu2S3NiGS1B; Tue, 06 May 2014 18:16:26 +0000 Message-ID: <536926F1.3010702@alum.mit.edu> Date: Tue, 06 May 2014 14:16:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Christer Holmberg , "DRAGE, Keith (Keith)" , "dispatch@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <201405061517.s46FHlL1017748@hobgoblin.ariadne.com> <5369028D.1050109@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B196273@FR712WXCHMBA11.zeu.alcatel-lucent.com> <53690ECE.4050901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EEDD6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2EEDD6@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=1399400186; bh=Nl/ZfdpKfsrQXBxDTGhru5etVh2D17HoKgQO6dbix7w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hN5kxERBJEUqUtH4py8MYVoU4Jc2x32Q8GCd1EadynKWRui9VRcv1XSFEPCOhobBb pHL96LnxRt0qiGE4k9A6q77lnVbhRC1wu51abKZeHW3hLrjUJvSk4nJ1Jyqr23+cHh Z43B5XfxA/VnBc2K/pCWJ5wbCrSoeXdT+pI96DytErelOPvZFfiyKM45oK++iWDWrt P0uRx6Jv2fM1t42TWVwkSQpMY3xzou53u+UTlhiHH5XfT4KgC0+mnRTanhTyhxeAVz DY8qr1aUwWncGIcnLyZ+IVdFV8jk+Gdad7wPE/1vtHEGXb45REIc3VuSsrsE2nSeZA fQApWlgaC61XA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/dtLPf7h9ek1XGEtd2575rmm_BO0 Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 18:16:31 -0000 On 5/6/14 1:45 PM, Christer Holmberg wrote: > Hi, > >>> I think we should select the correct mechasism for performing this >>> functionality, and then worry about the approval regime. >> >> I hear you. But the question is whether you can get sufficient support to >> work on a standards track document that is only of interest to 3gpp. > > Well, that's quite obvious - it's difficult for many people to find time even for things they DO support :) > > Having said that, I think e.g. YOU have given very useful comments. You know, *I'll* comment on almost anything. :-) (And I'll always find *something* that can be improved.) > And, there is support for this in the 3GPP community, which is as good as any other support. Yes, it is possible to go that way. It's just that then you will have to subject yourselves to comments from those who object. Getting consensus becomes harder. It is much harder to argue that you reject a "better" approach because it presents logistic problems within 3gpp. Ultimately I think this is a matter for the dispatch chairs and the ADs to decide. Thanks, Paul From nobody Tue May 6 11:25: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 E2F861A0234 for ; Tue, 6 May 2014 11:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUPk-lGdlgQN for ; Tue, 6 May 2014 11:25:18 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4232F1A01BB for ; Tue, 6 May 2014 11:25:17 -0700 (PDT) X-AuditID: c1b4fb25-f798c6d000001521-ad-536929081480 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C4.02.05409.80929635; Tue, 6 May 2014 20:25:13 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Tue, 6 May 2014 20:25:12 +0200 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: AQHPaTfK+XDW89DjUkeYlKBaW9iAB5szl4uAgAAJO4CAAC3WoP//6kwAgAAi7vA= Date: Tue, 6 May 2014 18:25:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> <5369258A.6050005@alum.mit.edu> In-Reply-To: <5369258A.6050005@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+NgFnrILMWRmVeSWpSXmKPExsUyM+JvjS6nZmawwfTljBZLJy1gtVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxeuFb5oJ3nBVrnixlbmD8yN7FyMkhIWAi sWnzYiYIW0ziwr31bCC2kMBRRokHc6u7GLmA7MWMEl+/32TtYuTgYBOwkOj+pw1SIyIQLHHw 8E4WEFtYwEliy52drBBxZ4lP3S9ZIGw/iav3loDZLAIqEq9/P2YEsXkFfCUmfD/IDDF/FofE 3zNXwA7iFNCRuLG2BcxmBDro+6k1YMcxC4hL3HoyH+pQAYkle84zQ9iiEi8f/2OFsJUkFt3+ DFWvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYyixanFSbnp RsZ6qUWZycXF+Xl6eaklmxiBcXJwy2/VHYyX3zgeYhTgYFTi4X3wKiNYiDWxrLgy9xCjNAeL kjjvl1s+wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYXZOND3xRYg+6clttkdyUIrFaq1D1 tJuu6Rvmluq5fr57fElhv/OhvrWhxv1/l8tvuBX3rdNuxTmP65+DNWvOCNvHzuq6yjH3rt4S 2f6zdzN2TmWMMTix9s9MkUO7/xd9PVR7VMB97r9bEZ0v8/yWpvMt3st993Libe1T1qkuj6OY 5Zw3WL3xUWIpzkg01GIuKk4EAFghuKl0AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/CfC8uiZ-FTw-F84ECxqHg5tPtr8 Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 18:25:20 -0000 Hi, >>> The key seems to be Table 7.3.3.1 (Evaluation of compliance with the re= quirements in annex B). >>This table seems to justify the choice of a URI p= arameter. But I don't find any explanation for how >>evaluation of each alt= ernative against each of the requirements was done. The values in the table= >>aren't obviously correct to me. AFAICT my header parameter suggestion wo= uld get the same >>evaluation as the URI parameter does. >> >> It does not work if the iotl is associated with the Request-URI. > > There is nothing to prevent having a Route header having the same URI as = the R-URI. Not sure how that works when the R-URI e.g. addresses an end-user, but is "= consumed" by another node, e.g. the registrar serving the end-user (e.g. th= e home S-CSCF in 3GPP). I think you would have to add a Route header that p= oints to the actual registrar/S-CSCF, and the starting point (which can be = an S-CSCF in another operator network) may not even have that information (= there is no registration path between the S-CSCFs). Maybe it's doable somehow, but I just think it would complicate things, and= would require additional procedures, when you can avoid that by using a UR= I parameter. Regards, Christer From nobody Tue May 6 11:57:11 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 9B7C91A02F5 for ; Tue, 6 May 2014 11:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fS3G51FMqSjZ for ; Tue, 6 May 2014 11:57:08 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 3394A1A02F1 for ; Tue, 6 May 2014 11:57:08 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta12.westchester.pa.mail.comcast.net with comcast id yiiW1n0020xGWP85Cix4KH; Tue, 06 May 2014 18:57:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id yix41n0043ZTu2S3Yix4ps; Tue, 06 May 2014 18:57:04 +0000 Message-ID: <5369307F.6050003@alum.mit.edu> Date: Tue, 06 May 2014 14:57:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Christer Holmberg , "dispatch@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> <5369258A.6050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2EEF04@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=1399402624; bh=LK8wOYaMN4U4/E3rmBi/IgyCU5t0ADrOnVoCgnV655E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jnu7ko3TRg7eROHxqZnxGGxh+2RBSefcPBbR+dGOhYa4iVRPIqN5rKJ0GqPpSCjsR AzEVZWj3ZwUxG5MEbFPoQpxYc74Wg41z3Bj/AqVqTmCiwoZgIeOda2cV8kWn6wvfwf jrtEdWPQVcquXAqho4x1Iw0c2r42DhkhR79I48z1jqZqGVr/CqF//t4wOXUrFMzG7g nb+wphRdhu5KbLleUldgjth8xWfQDlnMG6vh3toNrabhQ5Rloo0H+vUtnN8F1W5SOD J5FazjPW+iBSM0+iWYaS47zJRemyrKPFDM9Pd+M56T2i9pdQ5A5Q/SXSMMFUUz1jdo pyZU9wg5Mdhmg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/HhmuDlsfMemM4cQK4NjHqeAIJjw Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 18:57:09 -0000 On 5/6/14 2:25 PM, Christer Holmberg wrote: > Hi, > >>>> The key seems to be Table 7.3.3.1 (Evaluation of compliance with the requirements in annex B). >>This table seems to justify the choice of a URI parameter. But I don't find any explanation for how >>evaluation of each alternative against each of the requirements was done. The values in the table >>aren't obviously correct to me. AFAICT my header parameter suggestion would get the same >>evaluation as the URI parameter does. >>> >>> It does not work if the iotl is associated with the Request-URI. >> >> There is nothing to prevent having a Route header having the same URI as the R-URI. > > Not sure how that works when the R-URI e.g. addresses an end-user, but is "consumed" by another node, e.g. the registrar serving the end-user (e.g. the home S-CSCF in 3GPP). I think you would have to add a Route header that points to the actual registrar/S-CSCF, and the starting point (which can be an S-CSCF in another operator network) may not even have that information (there is no registration path between the S-CSCFs). I don't follow. The R-URI that is "consumed" by the registrar is the AOR. Are you imagining that this parameter will be present in the AOR all the time? If not, who adds it, and when? Whoever adds it to the AOR could just as easily add a Route header. That Route header could have the full AOR and the header parameter. Or it could just have the domain from the AOR and the header parameter. > Maybe it's doable somehow, but I just think it would complicate things, and would require additional procedures, when you can avoid that by using a URI parameter. I don't know if it complicates things because I don't know what complications will be needed to put this parameter in, independent of the mechanism. I can see how Service-Route could have this added during registration. Other than that I have no clue who would do what. Service-Route won't get anything into the R-URI. Thanks, Paul From nobody Tue May 6 12:22: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 C87541A03A8 for ; Tue, 6 May 2014 12:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pEnHI2qZdD2x for ; Tue, 6 May 2014 12:22:12 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id 91DA91A0332 for ; Tue, 6 May 2014 12:22:11 -0700 (PDT) X-AuditID: c1b4fb3a-f79106d0000013ca-fa-5369365e1dbe Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 62.9D.05066.E5639635; Tue, 6 May 2014 21:22:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Tue, 6 May 2014 21:22:06 +0200 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: AQHPaTfK+XDW89DjUkeYlKBaW9iAB5szl4uAgAAJO4CAAC3WoP//6kwAgAAi7vD//+oigIAAJTIg Date: Tue, 6 May 2014 19:22:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2EF00C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> <5369258A.6050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se> <5369307F.6050003@alum.mit.edu> In-Reply-To: <5369307F.6050003@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+NgFnrELMWRmVeSWpSXmKPExsUyM+JvjW68WWawwdYj/BZLJy1gtVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXRs/sCW8FUsYpLD2axNDCeFuxi5OSQEDCR +L7tPSuELSZx4d56ti5GLg4hgaOMEidWzGeGcBYzSpx7vJm9i5GDg03AQqL7nzZIg4hAsMTB wztZQGxhASeJLXd2skLEnSU+db9kgbCjJM43fgKLswioSCw5PgXM5hXwlfh/fRILxPxZHBKt C7YwgyQ4BXQkvl2DGMQIdNH3U2uYQGxmAXGJW0/mM0FcKiCxZM95ZghbVOLl439QHyhJLLr9 GapeR2LB7k9sELa2xLKFr5khFgtKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxhFi1OLi3PT jYz0Uosyk4uL8/P08lJLNjECI+Xglt9WOxgPPnc8xCjAwajEw/vgVUawEGtiWXFl7iFGaQ4W JXHeSYvcg4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwptTyWV4qfv71VKeYzqTTX16veF99 auoecRdXEzOlok0lxh/CdThsjG7ph600KG2e2TSxtF7+9G+9Y/GFO5Iv/fnWF+iRIV74hnHh pDMXGF229LU1dBTnc3SoOd+uXjG/5Ijztxu+Okb3z/z1V7KcvPLGh+ur6zq/Ot20PFRW4nIz Ib17oW+6EktxRqKhFnNRcSIA+wzzyHUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/zirPNWFOp8KwpBUizpxw-OuHjZ4 Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 19:22:13 -0000 Hi, >>>>> The key seems to be Table 7.3.3.1 (Evaluation of compliance with the = requirements in annex >>>>> B). This table seems to justify the choice of a= URI parameter. But I don't find any explanation >>>>> for how evaluation o= f each alternative against each of the requirements was done. The values >>= >>> in the table aren't obviously correct to me. AFAICT my header parameter= suggestion would get >>>>> the same evaluation as the URI parameter does. >>>> >>>> It does not work if the iotl is associated with the Request-URI. >>> >>> There is nothing to prevent having a Route header having the same URI a= s the R-URI. >> >> Not sure how that works when the R-URI e.g. addresses an end-user, but i= s "consumed" by=20 >> another node, e.g. the registrar serving the end-user (e.g. the home S-C= SCF in 3GPP). I think you >> would have to add a Route header that points t= o the actual registrar/S-CSCF, and the starting=20 >> point (which can be an S-CSCF in another operator network) may not even = have that information >> (there is no registration path between the S-CSCFs= ). > > I don't follow. The R-URI that is "consumed" by the registrar is the AOR.= Are you imagining that this > parameter will be present in the AOR all the= time? If not, who adds it, and when? Whoever adds it > to the AOR could ju= st as easily add a Route header. That Route header could have the full AOR = and > the header parameter. Or it could just have the domain from the AOR a= nd the header parameter. > >> Maybe it's doable somehow, but I just think it would complicate things, = and would require=20 >> additional procedures, when you can avoid that by using a URI parameter. > > I don't know if it complicates things because I don't know what complicat= ions will be needed to put > this parameter in, independent of the mechanis= m. I can see how Service-Route could have this=20 > added during registration. Other than that I have no clue who would do wh= at.=20 > Service-Route won't get anything into the R-URI. Again, perhaps it's doable, but you would have to specify how that extra Ro= ute looks like etc. And, I don't see why one should have to do that, if you= get the same result by using a SIP URI parameter. In addition, there is one use-case where an existing FCI is used to carry a= URI. And, that URI may now also contain an iotl. If we would use something= else to carry the iotl, we would have to re-define that FCI (currently it'= s defined to carry a URI value only), which could cause backward compatibil= ity issues.=20 Of course, if the suggested SIP URI parameter solution doesn't work, we wil= l have to do that, but nobody has said why a SIP URI parameter would not wo= rk. I still also think that it fits semantically. Regards, Christer From nobody Tue May 6 12:47:41 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 273F41A03E1 for ; Tue, 6 May 2014 12:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 vcD3qKIGGO5l for ; Tue, 6 May 2014 12:47:36 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 860D41A03B5 for ; Tue, 6 May 2014 12:47:36 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta12.westchester.pa.mail.comcast.net with comcast id ydiM1n0021vXlb85CjnYck; Tue, 06 May 2014 19:47:32 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta17.westchester.pa.mail.comcast.net with comcast id yjnY1n0031KKtkw3djnYtf; Tue, 06 May 2014 19:47:32 +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 s46JlVGJ012756; Tue, 6 May 2014 15:47:31 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s46JlV5M012755; Tue, 6 May 2014 15:47:31 -0400 Date: Tue, 6 May 2014 15:47:31 -0400 Message-Id: <201405061947.s46JlV5M012755@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "DRAGE\, Keith \(Keith\)" In-reply-to: <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> (keith.drage@alcatel-lucent.com) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399405652; bh=iDOYcn5fiFkbVmh25h8SbEeY0Sbw9TrLJAbG4cA9ols=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=SHhyhJ1o07dWrmbksr6GahSmFtz7kFzt5zCAQ6RzSNFb4W9LCfi4WjkarjXMRn+Ve JpPB/v8YWjU/Y99kEdeYnMCZ1FVuCDs6ptKSu0L9XZRKYszJJWC58tXV2lYTtSqP18 cRxpcSSD87JCCLf2A7DoRUKnOtvPdFzrBa0AxolgQpVwwshuF0NyNLBa+Xo8YzgzCR ZBy1i1fwSTtoZBWLpxAA5DvOPi8mJXNKtQk4frjm3ZnIxZ+bIc3Ck8dhXJn/78TSyQ rWv9TSBhbM9U3SjJLN1Z9EETAigT2lHRVHMnQoWCPJIwEyQWanI+sPOx83/EMDDHeH KUybwN92yamdQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/PlJPVpSDS35C28bGTYN9TkvpSOw Cc: dispatch@ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 06 May 2014 19:47:40 -0000 > From: "DRAGE, Keith (Keith)" > It is worth noting that some extensive analysis of the problem was > performed in 3GPP over the pros and cons of various options. > > That document is available at: > > http://www.3gpp.org/DynaReport/24802.htm Specifically, the latest version (12.0.0) can be obtained at http://www.3gpp.org/ftp/Specs/archive/24_series/24.802/24802-c00.zip . That URL retrieves a ZIP file containing a DOC file named 24802-c00.doc. The list of requirements is in Annex B.2.3. The detailed list of proposals is in section 7. Table 7.3.3.1 comparing the proposals against the requirements is on page 41. Pros and cons of the proposals are listed in section 9. This document really should be a reference in the draft, since it is the technical justification for the draft. A first look: Looking at the comparison table, I see that most entries are "Yes", that is, the proposal satisfies the requirement. Several others are "RFC required", "New IANA procedure required", or similar things -- but I don't see those as a problem, since we are considering an RFC and that can create new IANA procedures. The bulk of the entries that aren't "Yes" are "Local policy based on interoperator agreement is required". I'm not sure where those come from. I suspect that the issue is that the current 3GPP architecture isn't transparent with regard to the new item (header fields, P-Charging-Vector value, feature capability indication), and so the gatewaying specifications between carriers would need to be updated. None of the entries suggest that any of the proposals would not work technically. What seems to be missing is a requirement covering the most interesting feature of the iotl proposal: A route list can be provided that can cause the request to be labelled differently during each of a series of hops between proxies without any special processing required of the proxies. However this benefit is listed in the pro/con analysis of section 9. Contrarily, the analysis of other proposals (e.g., section 7.3.2.4) seems to consider that the CSCFs will know when to insert and remove scenario indicators anyway. So it's not clear that this is truly a requirement. Dale From nobody Wed May 7 09:09:23 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 EC1771A081D for ; Wed, 7 May 2014 09:09:21 -0700 (PDT) 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, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Idl16ZTPW5qd for ; Wed, 7 May 2014 09:09:20 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id AB35D1A0816 for ; Wed, 7 May 2014 09:09:20 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s47G9Djl019894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 May 2014 11:09:13 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s47G9CM3000572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 12:09:13 -0400 Received: from US70TWXCHMBA10.zam.alcatel-lucent.com ([169.254.4.2]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 7 May 2014 12:09:12 -0400 From: "Calme, James A (Jim)" To: Christer Holmberg , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: AQHPaTffMq72SQSkK0+3pwpigVtYBpsz/CCAgAAJO4CAAAzBAIAAC2EAgAAEKYCAASctEA== Date: Wed, 7 May 2014 16:09:12 +0000 Message-ID: <7B8DC1AC12241143921AC7733AF3C17B3B3AFA9A@US70TWXCHMBA10.zam.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> <5369258A.6050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] 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/HKty88hWbJzPtqNYuxJhCzK9FyA Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 07 May 2014 16:09:22 -0000 Hi, Looking at the ABNF for this new parameter it would appear that only a sing= le value is expected to used. iotl-param =3D iotl-tag "=3D" iotl-value iotl-tag =3D "iotl" iotl-value =3D "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA" / "homeA-visitedA" /" visitedA-homeB" / gen-value Given the current set of values, it would seem reasonable that they would b= e mutually exclusive. But do you expect this to always be true? Would it be= possible that if additional values are defined that they could compliment = the currently set, i.e., should the syntax allow one or more values to be i= ncluded? Jim From nobody Wed May 7 10:46: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 28C171A0251 for ; Wed, 7 May 2014 10:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGh4DunAeHVO for ; Wed, 7 May 2014 10:46:35 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2B75D1A01CE for ; Wed, 7 May 2014 10:46:33 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-e1-536a71742fcf Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 17.ED.04199.4717A635; Wed, 7 May 2014 19:46:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0174.001; Wed, 7 May 2014 19:46:28 +0200 From: Christer Holmberg To: "Calme, James A (Jim)" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: AQHPaTfK+XDW89DjUkeYlKBaW9iAB5szl4uAgAAJO4CAAC3WoP//6kwAgAAi7vCAAU2RAIAAPLRv Date: Wed, 7 May 2014 17:46:27 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> <5369258A.6050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se>, <7B8DC1AC12241143921AC7733AF3C17B3B3AFA9A@US70TWXCHMBA10.zam.alcatel-lucent.com> In-Reply-To: <7B8DC1AC12241143921AC7733AF3C17B3B3AFA9A@US70TWXCHMBA10.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvjW5pYVawwY9Qi6WTFrBaXJi0hN2B yaP12V5WjyVLfjIFMEVx2aSk5mSWpRbp2yVwZfw4P5eloJmj4uqOG+wNjDPYuhg5OSQETCR2 bupjhbDFJC7cWw8U5+IQEjjKKNF8ZSIjhLOYUeL46yksXYwcHGwCFhLd/7RBGkQEUiR2TLnK DmILCzhJbLmzkxUi7izxqfslC4QdJfHy4womEJtFQEXi6N5uMJtXwE3iy6IZzBDz13NKnG+C uIhTIFbi4uqpzCA2I9BF30+tAWtgFhCXuPVkPhPEpQISS/acZ4awRSVePv7HClGjI7Fg9yc2 CFtbYtnC18wQywQlTs58wjKBUWQWklGzkLTMQtIyC0nLAkaWVYyixanFSbnpRkZ6qUWZycXF +Xl6eaklmxiB8XBwy2+DHYwvnzseYhTgYFTi4X34KiNYiDWxrLgy9xCjNAeLkjjvt7PuwUIC 6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYNSe6FotkrGteubQ1uer9SXXfTKfc6TIS9llnuH2c gxnNY4yNriozdxRMdHvVW2wUaid3aZaSUNzcFRlWwWIihbEiez9ostQ+/5RwzGtRI7Nd8tzG 1CDd0+vtdB89/7rcqLG+1eUKi9fx9XZSKo6yK4tK3ZZPeLxex6rt/puFPnzb7/kwnFRiKc5I NNRiLipOBADmgaRwaAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/Eut_cOLROsxK_mkr-guhYQGNqSU Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 07 May 2014 17:46:36 -0000 Hi Jim, Currently there are no use-cases which, for a given URI, would require mult= iple values. But, if people think it would be useful to allow it for possible future usa= ge, we can for sure modify the ABNF to allow it. Regards, Christer Sent from my Sony Ericsson Xperia arc S "Calme, James A (Jim)" wrote: Hi, Looking at the ABNF for this new parameter it would appear that only a sing= le value is expected to used. iotl-param =3D iotl-tag "=3D" iotl-value iotl-tag =3D "iotl" iotl-value =3D "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA" / "homeA-visitedA" /" visitedA-homeB" / gen-value Given the current set of values, it would seem reasonable that they would b= e mutually exclusive. But do you expect this to always be true? Would it be= possible that if additional values are defined that they could compliment = the currently set, i.e., should the syntax allow one or more values to be i= ncluded? Jim From nobody Wed May 7 11:09: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 88ACD1A0848 for ; Wed, 7 May 2014 11:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 uQ0pHnGlgu8J for ; Wed, 7 May 2014 11:09:28 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 77D9A1A0845 for ; Wed, 7 May 2014 11:09:27 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta12.westchester.pa.mail.comcast.net with comcast id z5L71n0041ZXKqc5C69PXM; Wed, 07 May 2014 18:09:23 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta21.westchester.pa.mail.comcast.net with comcast id z69N1n00X1KKtkw3h69NA9; Wed, 07 May 2014 18:09:23 +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 s47I9M0j024160; Wed, 7 May 2014 14:09:22 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s47I9MgY024159; Wed, 7 May 2014 14:09:22 -0400 Date: Wed, 7 May 2014 14:09:22 -0400 Message-Id: <201405071809.s47I9MgY024159@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D2EF00C@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> <5369258A.6050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se> <5369307F.6050003@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EF00C@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399486163; bh=Ef2YJgq7AA5x/yx2Fh1RWjBT0k99ljpY+jBJ993cV3E=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=EMCzhG4Bs1F+g2OwnXOZzek6lXoTnUQu63eERIjNMJcwdWv5uNFNwvZoelkphFGz3 ccV3K1PEzSGC4uHsehWRFV7Tsvkqn9UtkreCFs7pbB+IQxWUaKjXTg4grRf8zpuLNV /5nxDftUuoFWZJM/zAXl1gogGPIFnoA3T1ioCqFbo64sAObp4p7GC1eKmFzPndVe97 nZrOlqiKqImpW/4KDGbE4KLUZN7a8kX7cW0oSc4c7ojrjSw/PySs2QGfpVYSSZYSIK QtHRLLaMQWmDDALptj6cg2MJDMuvMu8eGrZLm7YyYsRL750y/Rj9A+L25BqLN3IzBz mVlP5GoVCvRHw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/VSD1-quXVm4m9LcT_YgLsZfeeUM Cc: dispatch@ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 07 May 2014 18:09:29 -0000 > From: Christer Holmberg > In addition, there is one use-case where an existing FCI is used to > carry a URI. As far as I can figure out, "FCI" means "Forward Call Indicator", which is a field in the IAM message. I can't find any definition of its structure in any RFC, but all uses of the term suggest that it is a group of bit-fields, not a character string. I also can't find "FCI" in 3GPP TR 24.802, "Indication of Network to Network Interface (NNI) routeing scenarios in Session Initiation Protocol (SIP) requests in the IP Multimedia Subsystem (IMS)", which Keith says is the technical analysis behind this draft. Can you present us this use-case, or provide us with a reference? And why does it not appear in 24.802? Dale From nobody Wed May 7 11:22: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 B647D1A0844 for ; Wed, 7 May 2014 11:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 yRkQ8LkBcg3i for ; Wed, 7 May 2014 11:22:34 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 43A331A06AB for ; Wed, 7 May 2014 11:22:34 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 6e97a635.2b2f35047940.10388168.00-2419.28971052.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 07 May 2014 18:22:30 +0000 (UTC) X-MXL-Hash: 536a79e667854b06-1b5e420f1a52f59f4824258f3c85b289c948c834 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 4e97a635.0.10388153.00-2128.28971006.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 07 May 2014 18:22:29 +0000 (UTC) X-MXL-Hash: 536a79e53aab28ab-e25abcca993470b3450712336c23791c298961b4 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s47IMRjr006008; Wed, 7 May 2014 14:22:28 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s47IMGDW005768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2014 14:22:25 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (MISOUT7MSGHUB9E.itservices.sbc.com [144.151.223.61]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 7 May 2014 18:22:03 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.03.0174.001; Wed, 7 May 2014 14:22:02 -0400 From: "DOLLY, MARTIN C" To: Christer Holmberg Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: AQHPag64JSllYkLewECcnB1spXtt7ps1p3uA///G44g= Date: Wed, 7 May 2014 18:22:02 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> <5369258A.6050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se>, <7B8DC1AC12241143921AC7733AF3C17B3B3AFA9A@US70TWXCHMBA10.zam.alcatel-lucent.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Ia0wrxWa c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ibEq050wP9sA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=0FD05c-RAAAA:8 a=gxZvrgisA] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=Ua8iDAmjaxli8i_3rDoA:9 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=qM39cor4HRgA:10 a=Hz7IrDYlS0cA:10 a=f7GxY0FH8QIA] X-AnalysisOut: [:10 a=3FZX-ydVlcEA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014050601)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/wV9xdRKs1V1NwTNyaNmGTQz8MBE Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 07 May 2014 18:22:37 -0000 I support the ability to signal multiple values Martin Dolly Lead Member of Technical Staff Core Network & Gov't/Regulatory Standards =20 AT&T Standards and Industry Alliances +1-609-903-3360 md3135@att.com > On May 7, 2014, at 1:46 PM, "Christer Holmberg" wrote: >=20 > Hi Jim, >=20 > Currently there are no use-cases which, for a given URI, would require mu= ltiple values. >=20 > But, if people think it would be useful to allow it for possible future u= sage, we can for sure modify the ABNF to allow it. >=20 > Regards, >=20 > Christer >=20 > Sent from my Sony Ericsson Xperia arc S >=20 > "Calme, James A (Jim)" wrote: >=20 >=20 > Hi, >=20 > Looking at the ABNF for this new parameter it would appear that only a si= ngle value is expected to used. > iotl-param =3D iotl-tag "=3D" iotl-value > iotl-tag =3D "iotl" > iotl-value =3D "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA" > / "homeA-visitedA" /" visitedA-homeB" / gen-value >=20 > Given the current set of values, it would seem reasonable that they would= be mutually exclusive. But do you expect this to always be true? Would it = be possible that if additional values are defined that they could complimen= t the currently set, i.e., should the syntax allow one or more values to be= included? >=20 > Jim >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed May 7 11:54: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 0A3E41A0268 for ; Wed, 7 May 2014 11:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNTVPQDzT8oN for ; Wed, 7 May 2014 11:54:37 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE1F1A01D7 for ; Wed, 7 May 2014 11:54:37 -0700 (PDT) X-AuditID: c1b4fb25-f798c6d000001521-13-536a8168a57f Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 69.59.05409.8618A635; Wed, 7 May 2014 20:54:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Wed, 7 May 2014 20:54:32 +0200 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: AQHPaTfK+XDW89DjUkeYlKBaW9iAB5szl4uAgAAJO4CAAC3WoP//6kwAgAAi7vD//+oigIAAJTIggAGBWkSAAAuNUA== Date: Wed, 7 May 2014 18:54:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2F0702@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> <5369258A.6050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se> <5369307F.6050003@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EF00C@ESESSMB209.ericsson.se> <201405071809.s47I9MgY024159@hobgoblin.ariadne.com> In-Reply-To: <201405071809.s47I9MgY024159@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+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvjW5GY1awQfM+BYulkxawWrw8UebA 5DF5/1dmjyVLfjIFMEVx2aSk5mSWpRbp2yVwZZycfpuxYCZ7xZqFGQ2MZ1m7GDk5JARMJPoe fGWCsMUkLtxbz9bFyMUhJHCUUeLXky/MEM5iRomG7slAGQ4ONgELie5/2iCmiICmRMeCHJBe ZgFtif/X1zGC2MICThJb7uwEmy8i4CzxqfslC4SdJbH/2m+wXSwCKhIrXvxiBrF5BXwler8+ YoJYNYVTovNpD9ggTgEHie17drCD2IxAx30/tYYJYpm4xK0n86GOFpBYsuc8M4QtKvHy8T+o x5QkFt3+DFWvI7Fg9yc2mEOXLXwNtVhQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBkWcUoWpxa nJSbbmSsl1qUmVxcnJ+nl5dasokRGDsHt/xW3cF4+Y3jIUYBDkYlHt4FJVnBQqyJZcWVuYcY pTlYlMR5v9zyCRYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAKNl3+v7CL5HLm3ZEvejilM1Z KhZ9eVrI7i+5Vw9LneutaT/68s6NyMYYDk/tKQJzIiLcqxm/3hJtksw4ob1y0/sA15bguEsL 7Np3Zf29J3AkTsR6Fbuq8uHnP+wKXT4e/GJ7u+O2Smykvq31gbzNqv+SLqkuXXCGJ+a4juGr Nz+ZD2Y8+HpYQomlOCPRUIu5qDgRAETQ3s9+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/s1i7WhZ3VBihKsFm7pDUsOuhSds Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 07 May 2014 18:54:39 -0000 Hi, >> In addition, there is one use-case where an existing FCI is used to carr= y a URI. > > As far as I can figure out, "FCI" means "Forward Call Indicator", which i= s a field in the IAM message. > I can't find any definition of its structu= re in any RFC, but all uses of the term suggest that it is a=20 > group of bit-fields, not a character string. > > I also can't find "FCI" in 3GPP TR 24.802, "Indication of Network to Netw= ork Interface (NNI) routeing > scenarios in Session Initiation Protocol (SI= P) requests in the IP Multimedia Subsystem (IMS)", which > Keith says is th= e technical analysis behind this draft. Sorry for the Christer-Paul slang - I meant Feature-Capability Indicator :) > Can you present us this use-case, or provide us with a reference? And wh= y does it not appear in=20 > 24.802? I don't know, but it would good to add it there. Regards, Christer From nobody Wed May 7 12:20: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 084661A0306 for ; Wed, 7 May 2014 12:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 JcXI39R-mg0V for ; Wed, 7 May 2014 12:20:43 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE2D1A02AC for ; Wed, 7 May 2014 12:20:37 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta07.westchester.pa.mail.comcast.net with comcast id z5R31n0040vyq2s577LYG3; Wed, 07 May 2014 19:20:32 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta05.westchester.pa.mail.comcast.net with comcast id z7LY1n00A1KKtkw3R7LYe2; Wed, 07 May 2014 19:20:32 +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 s47JKVk3031294 for ; Wed, 7 May 2014 15:20:31 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s47JKVZZ031293; Wed, 7 May 2014 15:20:31 -0400 Date: Wed, 7 May 2014 15:20:31 -0400 Message-Id: <201405071920.s47JKVZZ031293@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-reply-to: <5369307F.6050003@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> <5369258A.6050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se> <5369307F.6050003@alum.mit.edu> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399490432; bh=dKCVgzECrkpeaV8PLDHGNN2ix2QlOiam9dNa2sRokFM=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=UWWA0fTG22Aeyx2yIVCGNMhsO733m5WM9ueDS8fPge24BDZ8S243abGMN3vapzTUQ LnPA0fNkxbl+sFjpNCeOLbG6bfMdVKJhDQrFVEhfatFxo24TcG40xGg242njg1Mbec qzc4EJF3tVDWO9PGQGtxEbdGhOMRGcdY26zskkGbytlv3DxcxX8y9JbJmVyagz4iro g2WxAGBMOQ28awSVa8oEZcMrS1jJrZu38MOVUxEpZ/CaDvIdcW778qtE08Hox4r+NT XuBxYONn+YNpqPXzIXk4OYQyLvjz7KP08hUnVldG1hsHorbddeEATdJUjC3y3ct7bS PC60QL2v1wEgQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/C1EwmNw79bSPrFxl11wIYCOIkbk Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 07 May 2014 19:20:46 -0000 > From: Paul Kyzivat > > On 5/6/14 2:25 PM, Christer Holmberg wrote: > > Not sure how that works when the R-URI e.g. addresses an end-user, > > but is "consumed" by another node, e.g. the registrar serving the > > end-user (e.g. the home S-CSCF in 3GPP). I think you would have to > > add a Route header that points to the actual registrar/S-CSCF, and > > the starting point (which can be an S-CSCF in another operator > > network) may not even have that information (there is no > > registration path between the S-CSCFs). > > I don't follow. The R-URI that is "consumed" by the registrar is the > AOR. Are you imagining that this parameter will be present in the AOR > all the time? If not, who adds it, and when? Whoever adds it to the AOR > could just as easily add a Route header. That Route header could have > the full AOR and the header parameter. Or it could just have the domain > from the AOR and the header parameter. Let me raise an alternative proposal, partly to show that alternatives exist, and partly to illustrate what I think is Paul's point. The proposal is that the iotl information is encoded not in a URI parameter, but a header of the URI. (This does get around any semantic objection, because it is established that a 'header' is a decoration of the base URI, not intrinsically part of it.) There seem to be no published examples for me to crib from, so I'm going to have to improvise, and likely will make some mistakes. But this should illustrate the point. We want the path of the call to be: A to VisitedA, presumably with no iotl, since it's all within one network (and A doesn't know what iotl to use) VisitedA to HomeA with iotl visitedA-homeA HomeA to HomeB with iotl homeA-homeB HomeB to VisitedB with iotl homeB-visitedB VisitedB to B, again presumably with no iotl (and there seems to be no relevant iotl value) Then, departing from VisitedA, the request would look like: INVITE B SIP/2.0 Route: Route: Route: From: ;tag=xxx To: ;tag=yyy Decorating B is problematic. While a request-URI is permitted syntactically to have a header, the process for forming a request in RFC 3261 prevents headers from appearing on request-URIs. So we should probably avoid putting headers on request-URIs. Of course, this may not matter, as it's not clear that the hops from the last proxy/B2BUA to B will need an iotl, as those hops are always within one network and always after any network-provided services. (Since any such services would show up as a routing, and this hop is after all routings.) OTOH, one could provide an additional Route duplicating the request-URI to carry an iotl for those hops: INVITE B SIP/2.0 Route: Route: Route: Route: From: ;tag=xxx To: ;tag=yyy Would this be processed correctly? When the request arrives at VisitedB, it will look like: INVITE B SIP/2.0 Route: Route: From: ;tag=xxx To: ;tag=yyy VisitedB must remove the topmost Route value. One possibility is that it sees that both the remaining Route and the request-URI are both in its domain and are the same, and so it will delete the Route and forward the INVITE to B's binding: INVITE Bbinding SIP/2.0 From: ;tag=xxx To: ;tag=yyy When this arrives at B, B accepts it. An alternative is that VisitedB replaces B in the Route header with B's binding: INVITE B SIP/2.0 Route: From: ;tag=xxx To: ;tag=yyy When this arrives at B, B deletes the Route value (because that is its binding), and accepts the request (because the request-URI is its AOR). Or maybe B accepts all INVITEs that arrive at it because it is a UA and doesn't forward requests at all. Dale From nobody Wed May 7 12:34:56 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 4C72D1A03A4 for ; Wed, 7 May 2014 12:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 iUd_CjAagQne for ; Wed, 7 May 2014 12:34:53 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 342831A039B for ; Wed, 7 May 2014 12:34:53 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta09.westchester.pa.mail.comcast.net with comcast id z4bY1n0080mv7h0597ao5D; Wed, 07 May 2014 19:34:48 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta11.westchester.pa.mail.comcast.net with comcast id z7ao1n00N1KKtkw3X7aoR4; Wed, 07 May 2014 19:34:48 +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 s47JYls0000328 for ; Wed, 7 May 2014 15:34:47 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s47JYl3b000327; Wed, 7 May 2014 15:34:47 -0400 Date: Wed, 7 May 2014 15:34:47 -0400 Message-Id: <201405071934.s47JYl3b000327@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D2EECDD@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2ECF6D@ESESSMB209.ericsson.se> <201405061532.s46FWhk5019260@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EECDD@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399491288; bh=Qycb981OkJ4BIaujs5As4IPiKBurHVVuhpTyIj6h8us=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=nsAoeS/1Qpybhm4ZrzCmhMelNrNvbPG3AtYEPy3uCQ7Nwq/MDErk+8r3cDmBbFe2H 3EY6EKJShI+YIykCXmRjVPJHpY7FI4yRxRzUpP492Rc21aeSc4QwMUjshWE8oB5Vlx GDmpOsOhl12I55TWacT/72Fn3lT93qVxcFUzNgeIaC1lDEUvdu+NLR2peNisAHxHvR 87Vad/jbrqgHWkrGfly3lCV7UpSstpdZvoodtGKiOZ8aWVQP/6rktmMuo+hQeSlkmr 1STWwjH4Bh+UitHr76JANAuezH+ERTcSmJnbwPaIsmbD5CbzVEWbYkDeFvvB80OjNP 4WRlnggvOfzTw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/PLKjNGKiDJBTr0-Qt-2107oCdR0 Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 07 May 2014 19:34:54 -0000 > From: Christer Holmberg > "lr" is just one example. Please take a look at the IANA list, and > see whether you think all the other parameters are "part of" the > URI... True, I looked and the situation isn't as clear as I thought. But all of the URI parameters (other than 'lr') seem to be examined only by a device constructing a request from the URI, or a device "within the domain" of the URI; devices that the request is simply transiting treat the parameter opaquely. 'lr' seems to be the exception, in that it must be interpreted by the proxies of every domain. And the purpose of 'iotl' seems to be to modify the process of network transit, not trigger specific processing at the proxies (or B2BUAs?) designated by the URIs containing them. Dale From nobody Wed May 7 12:41:15 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 6640C1A02F1 for ; Wed, 7 May 2014 12:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW5GgSGav5tX for ; Wed, 7 May 2014 12:41:09 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B5A5D1A02E8 for ; Wed, 7 May 2014 12:41:08 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-59-536a8c4ffaf9 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6B.E1.04714.F4C8A635; Wed, 7 May 2014 21:41:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Wed, 7 May 2014 21:41:03 +0200 From: Christer Holmberg To: "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAxuudP///zawCAAG22oP//+eQA//9KsDCAAg/BAIABWf9pgAJZ9Wf//+JMgAAdF7GzAAOkqAD//+A7kP/+TO1q//yBiZD/90Vyy//uiiWA Date: Wed, 7 May 2014 19:41:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2F07DE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2ECF6D@ESESSMB209.ericsson.se> <201405061532.s46FWhk5019260@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EECDD@ESESSMB209.ericsson.se> <201405071934.s47JYl3b000327@hobgoblin.ariadne.com> In-Reply-To: <201405071934.s47JYl3b000327@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+NgFnrILMWRmVeSWpSXmKPExsUyM+JvjW5AT1awQddjRoulkxawWrw8UebA 5DF5/1dmjyVLfjIFMEVx2aSk5mSWpRbp2yVwZax4sZyt4B97xZ07x9gbGOexdTFyckgImEic WzGJCcIWk7hwbz1QnItDSOAoo8TjfWeYIZzFjBJvzi8EquLgYBOwkOj+pw3SICIQIvF5Wicj iC0s4Czx7/AGdoi4i8Suz93sIL0iAqsYJdqnLALbxiKgIvHh4nxWEJtXwFeipWcOO8SCJg6J SY8uMoMs4BRwkNh8vRqkhhHoou+n1oBdxywgLnHryXyoSwUkluw5zwxhi0q8fPyPFcJWklh0 +zNUvY7Egt2f2CBsbYllC18zQ+wVlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxihanFhfn phsZ66UWZSYXF+fn6eWllmxiBMbJwS2/dXcwrn7teIhRgINRiYd3QUlWsBBrYllxZe4hRmkO FiVx3ra73sFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGLn6FU8Ji51xYtQxW+D9+u30gH83 9Je+vGXBz3anZL9Y1jybVUkRyzebibw45PPRJbJpa+cUE4vXLTscfpaf1s7/WiFRsl4l/d3D u9EZ29vvVZt0bq3sf+Ai/f6M3Ea+E/80c+12hYpLZmQEmrrXc7Hq2asyPXsa5PbubmjGxqyD Gptvp+zPVWIpzkg01GIuKk4EALpuN8R0AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/x4T5lIu4tLB1i0yQkjzZfXfh85c Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 07 May 2014 19:41:11 -0000 Hi, >> "lr" is just one example. Please take a look at the IANA list, and see=20 >> whether you think all the other parameters are "part of" the URI... > > True, I looked and the situation isn't as clear as I thought. But all of= the URI parameters (other than > 'lr') seem to be examined only by a devic= e constructing a request from the URI, or a device "within > the domain" of= the URI;=20 It still doesn't mean that the parameter is "part of" the URI. > devices that the request is simply transiting treat the parameter opaquel= y. =20 > 'lr' seems to be the exception, in that it must be interpreted by the pro= xies of every domain. > > And the purpose of 'iotl' seems to be to modify the process of network tr= ansit, not trigger specific=20 > processing at the proxies (or B2BUAs?) designated by the URIs containing = them. 'iotl' may trigger actions both at intermediary nodes, and at the node cons= uming the URI (i.e. the endpoint of the traffic leg). Regards, Christer From nobody Wed May 7 12:51:46 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 539D41A02DB for ; Wed, 7 May 2014 12:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 Lc18EIWCcY4B for ; Wed, 7 May 2014 12:51:42 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id BD4981A037B for ; Wed, 7 May 2014 12:51:41 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta05.westchester.pa.mail.comcast.net with comcast id z7Vt1n0021HzFnQ557rd0k; Wed, 07 May 2014 19:51:37 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta14.westchester.pa.mail.comcast.net with comcast id z7rc1n00K1KKtkw3a7rdYD; Wed, 07 May 2014 19:51:37 +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 s47JpaWn002203; Wed, 7 May 2014 15:51:36 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s47JpZbF002202; Wed, 7 May 2014 15:51:35 -0400 Date: Wed, 7 May 2014 15:51:35 -0400 Message-Id: <201405071951.s47JpZbF002202@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "DRAGE\, Keith \(Keith\)" In-reply-to: <949EF20990823C4C85C18D59AA11AD8B196273@FR712WXCHMBA11.zeu.alcatel-lucent.com> (keith.drage@alcatel-lucent.com) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <201405061517.s46FHlL1017748@hobgoblin.ariadne.com> <5369028D.1050109@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B196273@FR712WXCHMBA11.zeu.alcatel-lucent.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399492297; bh=X2EUhGDle4EXzXRYluZiIB4NOGKPuEiPEoUvbFOZnf0=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=CmFaNmRAPL+fubcnnH9QNLlkJteQsQ4P3csjpei9xegS4PKUHkXOY0bPeAZxzy1R9 BIB/zvfoAvUPHhvNruRtk6NyDMpUGeNP1gkrzshAUcTjCAf3SD4uvp2sSnLqEvY6ZK EbpR89/QPCEJB+Kc4T4cLjmTfz2W8NT8O0pvXtrfgMK53RAUhQQTkQb10o+nRmJ0Xq JHqL1G6o97zB94S1XzVnqreJQkql/w6h0hN+xekG0BKS7FCBxt22pQ+4xCrHkfx6/F EPeLq3OYcV2mHAIU/lMEaZGXhKfkdXXhTuC/ESRyLxqIPWnCznknOSEK6homO5PXl1 TEQP7w5HV3uvA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/QlZsCkfa7Ili5uAaP31a6Z54-IY Cc: dispatch@ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 07 May 2014 19:51:43 -0000 > From: "DRAGE, Keith (Keith)" > [...] I am not convinced the mechanism here need to be totally > defined as an IMS specific - without the names of particular types > of interface, the mechanism becomes fairly general purpose and could > be useful for other SIP routeing networks outside IMS - in other > words the mechanism could well be justified on standards track on > that basis, [...] I think part of the difficulty is that those of us not in contact with 3GPP don't have a good idea what the mechanism is intended to do. One possibility is that it's simply to notify, say, a proxy in A's home network that when the request arrives, the request has had certain service-specific processing applied and that certain other service-specific processing has not yet applied. In that case, the iotl is a modification of "where this request is to be sent at this stage", and a URI parameter is clearly acceptable; the device responsible for the base URI is the only one that needs to process the attached iotl value. In the context of Figure 1 of the draft, iotl=visitedA-homeA modifies what happens *at* proxy/B2BUA "ORIG HNW". With this possibility, it's not clear that there are any interoperability issues, or that is anything that needs to be standardized. Although it would be nice to record that 'iotl' is the parameter 3GPP uses to specify this information. Another possibility is that the iotl modifies *how the request progresses from one Route point to another*. In the context of Figure 1, iotl=visitedA-homeA modifies what happens on the path (the sequence of +'s) from "ORIG VNW" to "ORIG HNW". This possibility is altogether heavier, because devices that aren't within any of the domains of the routing URIs may need to see and act on the iotl values. (Maybe this isn't an issue in 3GPP, but it is in the general case.) This is like the Resource-Priority header. And in this case, it's important that everybody does it the same way, and that the semantics are clearly structured. But conversely, it isn't information that is particularly attached to the URI. Dale From nobody Wed May 7 12:55:23 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 2E4AF1A0383 for ; Wed, 7 May 2014 12:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LFQqMWxDvctc for ; Wed, 7 May 2014 12:55:20 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id 80B371A0366 for ; Wed, 7 May 2014 12:55:19 -0700 (PDT) X-AuditID: c1b4fb3a-f79a86d0000010e9-3c-536a8fa2b0f5 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 15.2B.04329.2AF8A635; Wed, 7 May 2014 21:55:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Wed, 7 May 2014 21:55:14 +0200 From: Christer Holmberg To: "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: AQHPaTfK+XDW89DjUkeYlKBaW9iAB5szl4uAgAAJO4CAAC3WoP//6kwAgAAi7vCAAaSfZIAAAqRQ Date: Wed, 7 May 2014 19:55:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2F081F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> <5369258A.6050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se> <5369307F.6050003@alum.mit.edu> <201405071920.s47JKVZZ031293@hobgoblin.ariadne.com> In-Reply-To: <201405071920.s47JKVZZ031293@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+Jvje6i/qxggxVHDS2WTlrAavHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbF0sn/BTdaK5d1r2RoY97F0MXJySAiYSJzu /soIYYtJXLi3nq2LkYtDSOAoo8TlTSdZIZzFjBK3r65l6mLk4GATsJDo/qcN0iAiECLxeVon WLOwgJPEljs7WSHizhKful+yQNhREifXLAarYRFQkeg/PZUdxOYV8JU4uvoWM8T8CxwSR/sv gTVzCjhIPFkzEayZEeii76fWMIHYzALiEreezGeCuFRAYsme88wQtqjEy8f/WCFsJYlFtz9D 1etILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo2hxanFxbrqR kV5qUWZycXF+nl5easkmRmCUHNzy22oH48HnjocYBTgYlXh4F5ZkBQuxJpYVV+YeYpTmYFES 5520yD1YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+OkrmbLPedDA79vYnwba+Icp3B+sq62 q9KEU3ZrZ/gdMVf37tx22vxBr/e6++fadPsMNgbIsLnH7JM9HrHp+fI1RY93PuiR7WJ66evR XL79StKOOe/uXLt06u9SlY9f/j2yPHXjSpbPrO2t6hN/Fc32mc1+4Ytsh7W2VaX4Q2NhNd2n Dw5f/7xOiaU4I9FQi7moOBEAXLbTMnMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/v2_rauinKn8TIMkSX9KQJw9MGJA Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 07 May 2014 19:55:21 -0000 Hi, > Let me raise an alternative proposal, partly to show that alternatives=20 > exist, and partly to illustrate what I think is Paul's point. > > The proposal is that the iotl information is encoded not in a URI paramet= er >, but a header of the URI. (This does get around any semantic objection, = because=20 > it is established that a 'header' is a decoration of the base URI, not in= trinsically=20 > part of it.) Please show me some text justifying your claim. Again, a big part of the existing SIP URI parameters (including parameters = defined in 3261) are using similar semantics, so I think it very strange th= at someone suddenly decides that it is semantically wrong. Regards, Christer From nobody Wed May 7 12:59: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 5479E1A0383 for ; Wed, 7 May 2014 12:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 yID7KQUdYJOc for ; Wed, 7 May 2014 12:59:38 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5011A02F8 for ; Wed, 7 May 2014 12:59:38 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta07.westchester.pa.mail.comcast.net with comcast id z3181n00j1ei1Bg577zav0; Wed, 07 May 2014 19:59:34 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta24.westchester.pa.mail.comcast.net with comcast id z7zZ1n00i1KKtkw3k7zZKL; Wed, 07 May 2014 19:59: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 s47JxXLa003005; Wed, 7 May 2014 15:59:33 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s47JxXTC003004; Wed, 7 May 2014 15:59:33 -0400 Date: Wed, 7 May 2014 15:59:33 -0400 Message-Id: <201405071959.s47JxXTC003004@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D2F0702@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> <5369258A.6050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se> <5369307F.6050003@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EF00C@ESESSMB209.ericsson.se> <201405071809.s47I9MgY024159@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2F0702@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399492774; bh=j9IkTvdUYknnn+dnyvvhOEK15zIbZjGxzR6A9L6fUKo=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=SCyESL3F1mnVyODzfba6hlK5GOEHPW+9p0MO171gEDWnMJw1OH2ncC2oHPc4J7gpf AYZfL3Agx1PU8UGyun5DQe5i8wq1JAjaiAYD75xGkZbXWuywMqqy3gBRgeIgTOV2Xa Kms6hkpZWau8s86FngIkiHtpnbhuQImHaGj0JiuVm2NYqtxrtoty+CPTjXJmbMlA7G V9rFNjCDi15lLXENu0SaTG30yEIKT/vIVfTzcpZmpYr6LiYg/lQHOYRR/Elo8OtVYt fXW5HyW62IA8IWFG8Z/UWofvBl4qLx2k4O6fecen+gPWIH4t+B8ruT3H4gAf85WQzP SVteUHAQsdMlg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/ohtR3aNXxfrRCIJjmwFd0efaXQM Cc: dispatch@ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 07 May 2014 19:59:40 -0000 > >> In addition, there is one use-case where an existing FCI is used > >> to carry a URI. > > Sorry for the Christer-Paul slang - I meant Feature-Capability Indicator :) OK. But there's a treacherous problem: If device A attaches an iotl value to a URI in a FCI value, and that FCI value is read and used by device B, device A has to know where device B sits in the network, and what iotl value will be appropriate for device B to use when it generates a request using that URI. My understanding is that iotl values are added to requests by proxies/B2BUAs early in the routing of a request. This makes sense, because the router needs to know both the source and destination locations of the request, and it is *sitting there*, so it knows all of the relevant policies. Dale From nobody Wed May 7 13:09: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 6A9DF1A0207 for ; Wed, 7 May 2014 13:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VlcmocPkvWBA for ; Wed, 7 May 2014 13:09:39 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id C79B11A0381 for ; Wed, 7 May 2014 13:09:38 -0700 (PDT) X-AuditID: c1b4fb3a-f79a86d0000010e9-95-536a92fd8a0e Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B2.EB.04329.DF29A635; Wed, 7 May 2014 22:09:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Wed, 7 May 2014 22:09:33 +0200 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: AQHPaTfK+XDW89DjUkeYlKBaW9iAB5szl4uAgAAJO4CAAC3WoP//6kwAgAAi7vD//+oigIAAJTIggAGBWkSAAAuNUIAAEzzrgAACCPA= Date: Wed, 7 May 2014 20:09:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2F086B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> <5369258A.6050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se> <5369307F.6050003@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EF00C@ESESSMB209.ericsson.se> <201405071809.s47I9MgY024159@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2F0702@ESESSMB209.ericsson.se> <201405071959.s47JxXTC003004@hobgoblin.ariadne.com> In-Reply-To: <201405071959.s47JxXTC003004@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+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje6/SVnBBi+3MFssnbSA1eLliTIH Jo/J+78yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+PwoYlMBbM4Ki5PWM/YwLiBrYuRk0NCwERi xsVnTBC2mMSFe+uB4lwcQgJHGSWuLdwG5SxmlLh+4iZ7FyMHB5uAhUT3P20QU0RAU6JjQQ5I L7OAtsT/6+sYQWxhASeJLXd2soLYIgLOEp+6X7JAlJdJfN8dCxJmEVCR6P1ykQXE5hXwlbjZ 85UFYlMfl8TFVVvYQRKcAg4Sf6a0gBUxAt32/dQaJohd4hK3nsyHullAYsme88wQtqjEy8f/ WCFsJYlFtz9D1etILNj9iQ3mzmULXzNDLBaUODnzCcsERrFZSMbOQtIyC0nLLCQtCxhZVjGK FqcWF+emGxnppRZlJhcX5+fp5aWWbGIExs7BLb+tdjAefO54iFGAg1GJh3dhSVawEGtiWXFl 7iFGaQ4WJXHeSYvcg4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwcqv0617wPnDmUmZk7EsH Hdn3qw/KpMcIzjr7Kcr5wafC1nOPDnVwaP+Pyg6sTt26hdP17tSUzsDlhn7LHFgOfdy994Pw J6dXvpP+cLq8PhFy/5kM1wJj0Yd+nlafuDlnnHr1rvhpgNaiy17T2C03LgjjXH5zW5POHJG7 148Jh3Pfid5qIVXRqcRSnJFoqMVcVJwIAKbhaTZ+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/wZNjW_fpjPcA_j9FZjYXLyWBmgs Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 07 May 2014 20:09:40 -0000 Hi, >>>> In addition, there is one use-case where an existing FCI is used to=20 >>>> carry a URI. >> >> Sorry for the Christer-Paul slang - I meant Feature-Capability=20 >> Indicator :) > > OK. > > But there's a treacherous problem: If device A attaches an iotl value to= a URI in a FCI value, and=20 > that FCI value is read and used by device B, device A has to know where d= evice B sits in the=20 > network, and what iotl value will be appropriate for device B to use when= it generates a request=20 > using that URI. Sure, and this will only be used in a very specific use-case, when that inf= ormation is known. >My understanding is that iotl values are added to requests by proxies/B2BU= As early in the routing >of a request. This makes sense, because the route= r needs to know both the source and destination >locations of the request, = and it is *sitting there*, so it knows all of the relevant policies. The URI provided in the FCI will later be used in the R-URI of an INVITE. Regards, Christer From nobody Wed May 7 13:10: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 E7C791A038A for ; Wed, 7 May 2014 13:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 IlZwFxXgYo8W for ; Wed, 7 May 2014 13:09:58 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id B6C9E1A0207 for ; Wed, 7 May 2014 13:09:57 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta10.westchester.pa.mail.comcast.net with comcast id z8111n0051c6gX85A89tiv; Wed, 07 May 2014 20:09:53 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta23.westchester.pa.mail.comcast.net with comcast id z89s1n01B1KKtkw3j89tQK; Wed, 07 May 2014 20:09:53 +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 s47K9qdV004068 for ; Wed, 7 May 2014 16:09:52 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s47K9qE4004067; Wed, 7 May 2014 16:09:52 -0400 Date: Wed, 7 May 2014 16:09:52 -0400 Message-Id: <201405072009.s47K9qE4004067@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-reply-to: <7B8DC1AC12241143921AC7733AF3C17B3B3AFA9A@US70TWXCHMBA10.zam.alcatel-lucent.com> (jim.calme@alcatel-lucent.com) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se> <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> <5369258A.6050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se> <7B8DC1AC12241143921AC7733AF3C17B3B3AFA9A@US70TWXCHMBA10.zam.alcatel-lucent.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399493393; bh=MQ24I9KZ6i/DVibzoGu7HXSlwD1+pbLmkOK37MLj23Q=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=phaqHL+5k7mpjn338n8r0PKbeTKQIdZBhEzieAtQKclgLg5MBKXJH8Pkqs2Qj5zVf 9hIYiRmPzbEH/NXXKPE1bYrez9NqE6eJzkpsZVYw49SFsJPfhY7/KpZtrDqQNsCLeB PGlAaikxVZy8uHScESZmnNLbKTe5XPwDJ3W4dw+TmoNZ65OOaHzGk0rMOylkZTOY0W 9WqyUefkNJMwMARfM2yszaFGRGIfhOyiR0C7+CqMgxtGpQtf2pG8dsYLUu+BKskgyO QiavU9d9BYLBJU3yA7MPmqpC0PLR4Pbll3FSTyUqnITZuS+NPM5YVgsqhpkyZ7FWop x7PshQdJF0auQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/jAvzt8NoPbQZAJEwut5QTzOkbzY Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 07 May 2014 20:10:00 -0000 > From: "Calme, James A (Jim)" > iotl-param = iotl-tag "=" iotl-value > iotl-tag = "iotl" > iotl-value = "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA" > / "homeA-visitedA" /" visitedA-homeB" / gen-value > Given the current set of values, it would seem reasonable that they > would be mutually exclusive. But do you expect this to always be > true? Would it be possible that if additional values are defined > that they could compliment the currently set, i.e., should the > syntax allow one or more values to be included? RFC 3261 specifies that there can be only one URI parameter of a single name attached to a URI. OTOH, given that can produce , there's no reason that one cannot define values that mean "the effect of 'homeA-homeB' plus special feature XYZ". Perhaps the thing to do is to define a particular character to mean "separator of multiple values" in s. This allows people who want to have combined iotl values in the future a consistent way to do it. If we want to avoid the necessity of quoting , we are restricted to : token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) Which allows . ! % * _ + ` ' ~ for delimiters. Dale From nobody Wed May 7 19:27: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 C76FA1A048F for ; Wed, 7 May 2014 19:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.152 X-Spam-Level: X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 ktUsxiKkZz1d for ; Wed, 7 May 2014 19:27:29 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 650D31A0206 for ; Wed, 7 May 2014 19:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1986; q=dns/txt; s=iport; t=1399516045; x=1400725645; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mNuxnjZfXpB+8TtK2fGHzQn4YesIx9SrhQvB1rilK1I=; b=htYa47FBs7ppdLrbeWa5Z4Iqft5QWn7e6wQNe5x7OXl5HEKSXzlfs1kz eeBTBhGkZ0Kk0+s3nyW5q96RWl+qumZuSTgs7eaKkQArrnHW9LfIyjJB/ dDEA9S7ZQ/+vC2zaOMe7GMgLtFKUrzyJcS17bQPoRo6Hb5bCanXsr67Pf 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMIAM7qalOtJA2B/2dsb2JhbABZgwZPWKsJAQEBAQEBBQGSUoZrUQGBGRZ0giUBAQEDAQEBATc0CwUHBAIBCBEEAQEfCQcnCxQJCAIEDgUbiB4IDc9QEwSFVohJMwcGgySBFQSZN5J7gzSCLw X-IronPort-AV: E=Sophos;i="4.97,1007,1389744000"; d="scan'208";a="41965127" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP; 08 May 2014 02:27:24 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s482RO06002013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 May 2014 02:27:24 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Wed, 7 May 2014 21:27:24 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: AQHPamULVMeeHy62BECkAH3cK6Tuiw== Date: Thu, 8 May 2014 02:27:24 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> 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: <2494B0950A5C2248B0593DA87E809949@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/m6EAJK9fhkZ2NKWBl0SaJ0Vr-BU Cc: "dispatch-chairs@tools.ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 08 May 2014 02:27:31 -0000 one possibility is to simply make it standard track with a sufficient warni= ng in the abstract and intro about the environment for which it is intended= to be used for I skimmed the draft but did not really get the motivation for the design - = perhaps at next meeting we should spend 5 minutes filling me in on it.=20 I will note our agreement with 3GPP is they bring us problems not solutions= and then we try and work on a solution together.=20 On May 6, 2014, at 12:30 AM, Christer Holmberg wrote: > Perhaps the chairs and/or ADs could give some guidance? >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Dale R. Wo= rley > Sent: 6. toukokuuta 2014 0:28 > To: Paul Kyzivat > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 >=20 >> From: Paul Kyzivat >>=20 >> I'm not sure I follow what you are suggesting. >>=20 >> As you note, the registration procedure requires "Standards Action"=20 >> and that requires a "Standards Track" RFC. IIUC an Informational RFC=20 >> isn't Standards Track. Is that the point you are making? >=20 > Yes. If we're going to document iotl at all, it should go into the table= of URI parameters. But strictly speaking, it seems that an informational = RFC can't add an entry to this registry. >=20 >> Are you suggesting that the IESG could override this? >=20 > I don't know for certain, but it seems to me to be likely that it can, an= d that would be a way around the apparent problem. >=20 > Dale >=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 >=20 From nobody Thu May 8 00:49:58 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 EAF4F1A04E8 for ; Thu, 8 May 2014 00:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ud_h9ZX5iu20 for ; Thu, 8 May 2014 00:49:55 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6851A04A7 for ; Thu, 8 May 2014 00:49:54 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-41-536b371d0694 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 92.28.04199.D173B635; Thu, 8 May 2014 09:49:50 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Thu, 8 May 2014 09:49:49 +0200 From: Christer Holmberg To: "Dale R. Worley" , "dispatch@ietf.org" , "Calme, James A (Jim)" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 - ABNF Thread-Index: Ac9qkZJIqq7oJYQfS0anruxhN3clMA== Date: Thu, 8 May 2014 07:49:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2F1260@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvja6ceXawwcNLXBZLJy1gtbgwaQm7 xcsTZQ7MHq3P9rJ6TN7/ldljyZKfTAHMUVw2Kak5mWWpRfp2CVwZR6a/YCyYzFsx8/EsxgbG r5xdjJwcEgImEo+nTWaFsMUkLtxbz9bFyMUhJHCUUeJubyNYQkhgMaPEoXOCXYwcHGwCFhLd /7RBakQEuhklpj67DFYjLOAp8e7gXhYQW0TAS+L/wxPMELaeRN+Dl2A1LAIqEtdu7GUCsXkF fCV2fz/CDmIzAi3+fmoNWJxZQFzi1pP5TBAHCUgs2XOeGcIWlXj5+B8ryA0SAooSy/vlIMp1 JBbs/sQGYWtLLFv4mhlivKDEyZlPWCYwCs9CMnUWkpZZSFpmIWlZwMiyilG0OLU4KTfdyEgv tSgzubg4P08vL7VkEyMwDg5u+W2wg/Hlc8dDjAIcjEo8vAtKsoKFWBPLiitzDzFKc7AoifN+ O+seLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRglv90sF9FjsXxPW7WW3sKrjlnBcin3ju 57ovJ3u+3ZY/OcGv74XIxevq+rcvMp//oPanaM/JK33//gX+Srn7Yf993sMJ4RYyJ4417V+v 9Mj13vGFTlYCRj+vZXxatIHjqAlPNfPhH91BfB0a7kd8Yplso6v4o3lZe2VvaoaueLnwzRnj 4tXZSizFGYmGWsxFxYkAjKV1ZWQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/KlZ1i2PnoBoY5hB3MAZAhCAuKX4 Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 - 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: Thu, 08 May 2014 07:49:57 -0000 Hi, >> iotl-param =3D iotl-tag "=3D" iotl-value >> iotl-tag =3D "iotl" >> iotl-value =3D "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA" >> / "homeA-visitedA" /" visitedA-homeB" / gen-value > >> Given the current set of values, it would seem reasonable that they=20 >> would be mutually exclusive. But do you expect this to always be true?=20 >> Would it be possible that if additional values are defined that they=20 >> could compliment the currently set, i.e., should the syntax allow one=20 >> or more values to be included? > > RFC 3261 specifies that there can be only one URI parameter of a single n= ame attached to a URI.=20 Correct. We would have to define a way to, for one URI parameter, provide a= list of values. > OTOH, given that can produce , there's no reason = that one cannot define values that mean "the effect of 'homeA-homeB' plus s= pecial feature XYZ". Correct. Jim, just to verify: did you talk about multiple values for a single URI?=20 (If you have multiple URIs, you can naturally put a different value in each= of them.) > Perhaps the thing to do is to define a particular character to mean "sepa= rator of multiple values" in s. This allows people who want to= have combined iotl values in the future a consistent way to do it. > > If we want to avoid the necessity of quoting , we are restric= ted to : > > token =3D 1*(alphanum / "-" / "." / "!" / "%" / "*" > / "_" / "+" / "`" / "'" / "~" ) > > Which allows . ! % * _ + ` ' ~ for delimiters. Yes. Regards, Christer From nobody Thu May 8 05:11: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 8F2C91A0515 for ; Thu, 8 May 2014 05:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9FGH7DSD1oE for ; Thu, 8 May 2014 05:10:51 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C9D911A02BB for ; Thu, 8 May 2014 05:10:50 -0700 (PDT) X-AuditID: c1b4fb25-f798c6d000001521-c1-536b7445443d Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A2.0D.05409.5447B635; Thu, 8 May 2014 14:10:45 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0174.001; Thu, 8 May 2014 14:10:44 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAxuudP///zawCAAG22oP//+eQA//9KsDCAAg/BAIABWf9pgAJZ9Wf//+JMgAAdF7GzAAOkqAAADIn1rf//aP0A//wSVgD/92CPMA== Date: Thu, 8 May 2014 12:10:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2F199C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se>, <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGfG3Rte1JDvYYM4FbYutL1azWCydtIDV omMym8WKDQdYLV6eKHNg9fj7/gOTx+T9X5k9pvzeyOqxZMlPJo8vlz+zBbBGcdmkpOZklqUW 6dslcGVsX32bueCTQMWE5b9YGhhP8XYxcnJICJhIHJ7+iB3CFpO4cG89WxcjF4eQwFFGiZXT JjFDOIsZJd79bWHtYuTgYBOwkOj+pw3SICJgKNG0Zx4TSA2zwH5GiUXnLjGCJIQFnCX+Hd7A DlHkIrHrczc7SJGIwDJGiW8rfzCBJFgEVCTmTt3JCmLzCvhKrLv0kR1i2252iS9N25hBtnEK 2Eo8P1QIUsMIdN73U2vAepkFxCVuPZnPBHG2gMSSPeeZIWxRiZeP/4EdKiGgKLG8Xw6iXEdi we5PbBC2tsSyha+ZIdYKSpyc+YRlAqPYLCRTZyFpmYWkZRaSlgWMLKsYRYtTi5Ny042M9VKL MpOLi/Pz9PJSSzYxAiPv4JbfqjsYL79xPMQowMGoxMO7oCQrWIg1say4MvcQozQHi5I475db PsFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGPlz9BXOzU1sWbfFZl+K+TnTPTYrt9xLmX/O NFtZijH1yP9Pjmu4i0XcP1qInPuy/ipj/AkPiZxt2nO2xd/9dMqrZUtl7c/k0wXM/lUmMX7F Pf5Xej+W9xxr/HW37szXgG6NywZqVi++H5D+su92sMiULReXF4rFLYm16uFSWrTgQ7p5id7P SiWW4oxEQy3mouJEAAOGHeydAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/okSGWIqisI0nnOUyWkdKgDrG8ak Cc: "dispatch-chairs@tools.ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 08 May 2014 12:10:53 -0000 Hi Cullen, >one possibility is to simply make it standard track with a sufficient warn= ing in the abstract and intro about the environment for which it is intende= d to be used for > >I skimmed the draft but did not really get the motivation for the design -= perhaps at next meeting we should spend 5 minutes filling me in on it.=20 > >I will note our agreement with 3GPP is they bring us problems not solution= s and then we try and work on a solution together.=20 The draft does try to explain what this is used for. And, the draft does suggest a solution. But, if it doesn't work, or if it f= or some other reason can't be used, of course we need to look at something = else. Regards, Christer > Perhaps the chairs and/or ADs could give some guidance? >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Dale R.=20 > Worley > Sent: 6. toukokuuta 2014 0:28 > To: Paul Kyzivat > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 >=20 >> From: Paul Kyzivat >>=20 >> I'm not sure I follow what you are suggesting. >>=20 >> As you note, the registration procedure requires "Standards Action"=20 >> and that requires a "Standards Track" RFC. IIUC an Informational RFC=20 >> isn't Standards Track. Is that the point you are making? >=20 > Yes. If we're going to document iotl at all, it should go into the table= of URI parameters. But strictly speaking, it seems that an informational = RFC can't add an entry to this registry. >=20 >> Are you suggesting that the IESG could override this? >=20 > I don't know for certain, but it seems to me to be likely that it can, an= d that would be a way around the apparent problem. >=20 > Dale >=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 >=20 From nobody Thu May 8 06:16: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 2DA3B1A02B2 for ; Thu, 8 May 2014 06:16:52 -0700 (PDT) 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, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpzksaw3VXbj for ; Thu, 8 May 2014 06:16:51 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id EA0431A0227 for ; Thu, 8 May 2014 06:16:50 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s48DGYLu000449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 May 2014 08:16:35 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s48DGXUC005300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 May 2014 09:16:33 -0400 Received: from US70TWXCHMBA10.zam.alcatel-lucent.com ([169.254.4.2]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 8 May 2014 09:16:33 -0400 From: "Calme, James A (Jim)" To: Christer Holmberg , "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 - ABNF Thread-Index: Ac9qkZJIqq7oJYQfS0anruxhN3clMAALdoGQ Date: Thu, 8 May 2014 13:16:33 +0000 Message-ID: <7B8DC1AC12241143921AC7733AF3C17B3B3AFEBC@US70TWXCHMBA10.zam.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D2F1260@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2F1260@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] 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/kxz-51EcETSqCwE0_h00iKTCuyE Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 - 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: Thu, 08 May 2014 13:16:52 -0000 Hi Christer, > Jim, just to verify: did you talk about multiple values for a single URI? [jac] Yes, on a single URI. > (If you have multiple URIs, you can naturally put a different value in ea= ch of them.) [jac] Understood, but not my immediate concern. ... > Regards, > Christer BR, Jim From nobody Thu May 8 07:31: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 D724E1A000B for ; Thu, 8 May 2014 07:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4Y5xgup9Rd8 for ; Thu, 8 May 2014 07:31:24 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 23E8C1A000A for ; Thu, 8 May 2014 07:31:23 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-ea-536b9536d5e7 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 67.BA.04714.6359B635; Thu, 8 May 2014 16:31:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Thu, 8 May 2014 16:31:18 +0200 From: Christer Holmberg To: "Calme, James A (Jim)" , "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 - ABNF Thread-Index: Ac9qkZJIqq7oJYQfS0anruxhN3clMAALdoGQAAKwHWs= Date: Thu, 8 May 2014 14:31:18 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D2F1260@ESESSMB209.ericsson.se>, <7B8DC1AC12241143921AC7733AF3C17B3B3AFEBC@US70TWXCHMBA10.zam.alcatel-lucent.com> In-Reply-To: <7B8DC1AC12241143921AC7733AF3C17B3B3AFEBC@US70TWXCHMBA10.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvja751Oxgg+Z7HBZLJy1gtbgwaQm7 xcsTZQ7MHq3P9rJ6TN7/ldljyZKfTAHMUVw2Kak5mWWpRfp2CVwZGz8uYCtYwlJx4kMPYwPj QuYuRk4OCQETiYsLetkhbDGJC/fWs3UxcnEICRxllNiz+DgThLOYUWLN9g1AHRwcbAIWEt3/ tEEaRAS6GSW6tuiB2MICnhLvDu5lgYh7Sfx/eIIZwraSaL98lRXEZhFQkbi39hQTyBheATeJ /XdYIcbPY5SY+aMb7AhOgViJ5oYfbCA2I9BB30+tYQKxmQXEJW49mc8EcaiAxJI956EeEJV4 +fgfK0SNjsSC3Z/YIGxtiWULX4PV8AoISpyc+YRlAqPILCSjZiFpmYWkZRaSlgWMLKsYRYtT i4tz042M9VKLMpOLi/Pz9PJSSzYxAiPk4JbfujsYV792PMQowMGoxMO7oCQrWIg1say4MvcQ ozQHi5I4b9td72AhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjLIFPTtZXt0OlzxUcaeBIbuT 1SJ96yTZovAGK1ZN9pPaOsdESqx5RHLnzfdiOL5Nzab/1cJHDHL92TMfHbE8L3W+b9GxpJvB RoKXFrlOmfBtSk1E3GfVu72S/bUx7YoXi99ZqMXl538R97HawDiznXX/i39tDNzBf5KMVro3 X/J5lODF9ChOiaU4I9FQi7moOBEAwU4vl3ECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/jkau2JHsygdkAVpicnFQMtg0ffs Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 - 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: Thu, 08 May 2014 14:31:26 -0000 Hi Jim, Ok, so perhaps we could use e.g. dot as separator (and disallow dot in the = value itself). Regards, Christer Sent from my Sony Ericsson Xperia arc S "Calme, James A (Jim)" wrote: Hi Christer, > Jim, just to verify: did you talk about multiple values for a single URI? [jac] Yes, on a single URI. > (If you have multiple URIs, you can naturally put a different value in ea= ch of them.) [jac] Understood, but not my immediate concern. ... > Regards, > Christer BR, Jim From nobody Thu May 8 08:13: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 60EC41A0057 for ; Thu, 8 May 2014 08:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKpunZdOm4Fh for ; Thu, 8 May 2014 08:13:22 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 9314B1A0053 for ; Thu, 8 May 2014 08:13:22 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta05.westchester.pa.mail.comcast.net with comcast id zPjE1n0051HzFnQ55TDH9c; Thu, 08 May 2014 15:13:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id zTDH1n00T3ZTu2S3aTDHiZ; Thu, 08 May 2014 15:13:17 +0000 Message-ID: <536B9F0D.6070506@alum.mit.edu> Date: Thu, 08 May 2014 11:13:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> <5369258A.6050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se> <5369307F.6050003@alum.mit.edu> <201405071920.s47JKVZZ031293@hobgoblin.ariadne.com> In-Reply-To: <201405071920.s47JKVZZ031293@hobgoblin.ariadne.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=1399561997; bh=RFhraZdEVrTwjFc+aOsAuG6E/H6lrUzM0vC8jqWgmQA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BH6ryifdRHMQYIOmD1Nq3bZkjD762zngsbPpwDyksXwxGKAgPDSnWJma9UCSSLdkP Rf2+XVLA8KRcBQ8YpimLC3hV5xlP+/mXHsOBIxB9acKXLjRJ29atq947HGg4Ya/oEF d7oZkfCcsZ+DIHYPF97xN4jZwwAb80TmdbQPygcRmsy09rHSwiSXNUi00M5LvOnn9L ZNIMeCpqTM5k5CPWph53gZFGRaDUkDEVThGLD9xUohZWOT1NgRXyCF1/CNJz+YkNfj QF89mK3CNOnPcwIv3WlNzkT/g7p2+XTjgOAyMbiORUSae8WRRcZNBwTAtxJlZpSqed gU0Hy348JZgHA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/fL2nEt0NHsaFYc8WoKtd4SQ_K0c Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 08 May 2014 15:13:23 -0000 On 5/7/14 3:20 PM, Dale R. Worley wrote: > Then, departing from VisitedA, the request would look like: > > INVITE B SIP/2.0 > Route: > Route: > Route: > From: ;tag=xxx > To: ;tag=yyy I think you meant: INVITE B SIP/2.0 Route: ;Iotl=visitedA-homeA Route: ;Iotl=homeA-homeB Route: ;Iotl=homeB-visitedB From: ;tag=xxx To: ;tag=yyy Thanks, Paul From nobody Thu May 8 08:31: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 CAF6D1A0052 for ; Thu, 8 May 2014 08:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtl51YMT3T8z for ; Thu, 8 May 2014 08:31:19 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id EB5FB1A004E for ; Thu, 8 May 2014 08:31:18 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta06.westchester.pa.mail.comcast.net with comcast id zSqn1n0010ldTLk56TXEVB; Thu, 08 May 2014 15:31:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id zTXE1n00B3ZTu2S01TXE3u; Thu, 08 May 2014 15:31:14 +0000 Message-ID: <536BA342.6040001@alum.mit.edu> Date: Thu, 08 May 2014 11:31:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2ECF6D@ESESSMB209.ericsson.se> <201405061532.s46FWhk5019260@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EECDD@ESESSMB209.ericsson.se> <201405071934.s47JYl3b000327@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2F07DE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2F07DE@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=1399563074; bh=feu5aDmHtXg2KlgByABce/tV0aRmbwSQEYoXZWSzWBc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YrfNLWdkYml0KACiy/KbDj74pyCkrLKGhLAgnQKJgvTH33zpUHdCnpgsRUzzzRbNj SmVfe3X3lyooG0I+N5oYa7urW7FrEIsHZVsKAjRDPEWsNDLEMQVBBys467MzoW+i1O OdcLmu4Wv8c67nifrWpafQpcyrFC4LW573PMoWR0plUdNQPDfcYWgjIZs+ZPzN0QLJ wCZHrSHfBYCYYmIAIotuCpPHetLq9kJL0qLoWQ9BCzxmJkumejTuTVeEIC9os7yhHU QCVdF6YYq4LrRbvkNyHLhghl7rloZGK+mhy8EpYsMlM+kTCblJNPaYaQQajFuT0m6w yM/I7WDgQKlcg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/NGD6kKsATQMUoitVuPqlFQtecE4 Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 08 May 2014 15:31:20 -0000 On 5/7/14 3:41 PM, Christer Holmberg wrote: > Hi, > >>> "lr" is just one example. Please take a look at the IANA list, and see >>> whether you think all the other parameters are "part of" the URI... >> >> True, I looked and the situation isn't as clear as I thought. But all of the URI parameters (other than > 'lr') seem to be examined only by a device constructing a request from the URI, or a device "within > the domain" of the URI; > > It still doesn't mean that the parameter is "part of" the URI. It is part of the URI by definition: SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ] It is also by definition an identifier of a resource. It is a *name*, like your name. It is assigned by the owner of the resource, or by someone acting on behalf of the owner of the resource. It isn't really proper for others who simply want to *reference* that resource to change its name. Instead, we put information on how to reference the resource in other places, such as in header parameters. This is a philosophical point. I don't know if it is written down anywhere. Certainly it has been violated. Yet I think it remains the right way to view things. Thanks, Paul From nobody Thu May 8 08:37:29 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 967DA1A00B7 for ; Thu, 8 May 2014 08:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFeAuXYWfAc2 for ; Thu, 8 May 2014 08:37:26 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 596D91A0096 for ; Thu, 8 May 2014 08:37:26 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta12.westchester.pa.mail.comcast.net with comcast id zRYp1n0070xGWP85CTdMPU; Thu, 08 May 2014 15:37:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id zTdM1n00N3ZTu2S3YTdMzq; Thu, 08 May 2014 15:37:21 +0000 Message-ID: <536BA4B1.5020100@alum.mit.edu> Date: Thu, 08 May 2014 11:37:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> <5369258A.6050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se>, <7B8DC1AC12241143921AC7733AF3C17B3B3AFA9A@US70TWXCHMBA10.zam.alcatel-lucent.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=1399563441; bh=UNzB3aVOEk07Y+upZHFPegF++u3jlx/JCVUflqAvGfI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YDk51qM3BZ8LI8Vou1sRci35VrGv0X93ZRbge78edI0kVqbmL2NZhyPrmPDDCrZ7o 7/EPb5fi91ySh9HboF9s3ZydOKGgNKkaT8HQkjZS9JSWfinV3cAaYfgNOfJMDiz2NG 87luJIOAzMtI3QxpmyMMJK94jIaLpBQ5YFYuQujVc/x8XHQ+0rPJLsxBHuftLQnaiG 9ZVu0/FTpUvl/fSp/S0JLuQ3HbGsjkAwlqBQEnZkRMOpbWi3x7lSyxvNqzL62QuYYs KyMAOaENWg/gj8h8qF6ONESxoguvPa5ZUF7a6rbM4GoWaIMN4xic5WejwyVTUBl3rm 8q6/yVLOxoewA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/mlBXtB4k2qSTvnj1Nqu0tXs50mY Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 08 May 2014 15:37:27 -0000 On 5/7/14 2:22 PM, DOLLY, MARTIN C wrote: > I support the ability to signal multiple values When I saw that it can be put into Path and Service-Route, I immediately assumed that there might be multiple values. I was surprised when Christer said that there would only be one at a time. But, it did lead me to post questions about how the "current" value is to be determined. I had some questions about that earlier in this thread. That discussion was squelched when Christer said there will only be one. So if multiple values are to be allowed, then more explanation is needed about the details of the semantics in those cases. Thanks, Paul > Martin Dolly > Lead Member of Technical Staff > Core Network & Gov't/Regulatory Standards > AT&T Standards and Industry Alliances > +1-609-903-3360 > md3135@att.com > >> On May 7, 2014, at 1:46 PM, "Christer Holmberg" wrote: >> >> Hi Jim, >> >> Currently there are no use-cases which, for a given URI, would require multiple values. >> >> But, if people think it would be useful to allow it for possible future usage, we can for sure modify the ABNF to allow it. >> >> Regards, >> >> Christer >> >> Sent from my Sony Ericsson Xperia arc S >> >> "Calme, James A (Jim)" wrote: >> >> >> Hi, >> >> Looking at the ABNF for this new parameter it would appear that only a single value is expected to used. >> iotl-param = iotl-tag "=" iotl-value >> iotl-tag = "iotl" >> iotl-value = "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA" >> / "homeA-visitedA" /" visitedA-homeB" / gen-value >> >> Given the current set of values, it would seem reasonable that they would be mutually exclusive. But do you expect this to always be true? Would it be possible that if additional values are defined that they could compliment the currently set, i.e., should the syntax allow one or more values to be included? >> >> Jim >> >> _______________________________________________ >> 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 Thu May 8 10:34: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 2BF701A00CB for ; Thu, 8 May 2014 10:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvlRNRNf-F-m for ; Thu, 8 May 2014 10:34:31 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 03BB21A00DC for ; Thu, 8 May 2014 10:34:30 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-c5-536bc021df90 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 51.C4.04199.120CB635; Thu, 8 May 2014 19:34:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Thu, 8 May 2014 19:34:25 +0200 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 - Multiple traffic legs per URI Thread-Index: Ac9q49AFC1mXHAIRTMGDkD3UQXdmmA== Date: Thu, 8 May 2014 17:34:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2F2142@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+Jvja7igexgg7m9FhZLJy1gtVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVxdM13toI14hXbJn9na2A8JdTFyMkhIWAi MX3tSzYIW0ziwr31YLaQwFFGiRdz1LsYuYDsxYwS6y72MXcxcnCwCVhIdP/TBqkREQiWOHh4 JwtIWFggRWLhL1eIcKrEzxntjCBhEQE9iYNnLUDCLAIqEr3nTzKD2LwCvhIHnh9nArEZgbZ+ P7UGzGYWEJe49WQ+E8Q1AhJL9pxnhrBFJV4+/scKYStJNC55wgpRryOxYPcnNghbW2LZwtdQ 8wUlTs58wjKBUXgWkrGzkLTMQtIyC0nLAkaWVYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiB AX9wy2+DHYwvnzseYhTgYFTi4V1QkhUsxJpYVlyZe4hRmoNFSZz321n3YCGB9MSS1OzU1ILU ovii0pzU4kOMTBycUg2M8o3aETUSWWLTeqsFTMJ33YhkjFBtsRPOW87jdF1RaJ2Ky1+hWZ3W 4p+O6qlcXqc94dHn6NILbxbKbimaeZz/aGXJTZ5bHdMcXZmML+jPuposblHqHaDQcXFX1/mO nyWqT5RXrNnA5uGt3/W77uWxxN0rLlZHHJ6S5/PltJjGxaXqk5yzl61SYinOSDTUYi4qTgQA 7IfyilkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/oLsDQOS-vus_LuFve1cgArYKRcU Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 - Multiple traffic legs per URI 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, 08 May 2014 17:34:33 -0000 Hi, >> I support the ability to signal multiple values > > When I saw that it can be put into Path and Service-Route, I immediately = assumed that there might > be multiple values. I was surprised when Christe= r said that there would only be one at a time. > > But, it did lead me to post questions about how the "current" value is to= be determined. I had=20 > some questions about that earlier in this thread. That discussion was squ= elched when Christer said > there will only be one. > > So if multiple values are to be allowed, then more explanation is needed = about the details of the=20 > semantics in those cases. What I meant was that there can't be "iotl" values in the Request-URI and R= oute(s) at the same time. I don't think there is a problem in having values in multiple Routes, becau= se the current one would be the Route representing the "nearest" node. And, yes, we will have to describe that :) HOWEVER, what Jim and Martin are talking about is to assign multiple values= to a SINGLE URI - i.e. a request would be associated with multiple traffic= legs at the same time. Regards, Christer > Martin Dolly > Lead Member of Technical Staff > Core Network & Gov't/Regulatory Standards AT&T Standards and Industry=20 > Alliances > +1-609-903-3360 > md3135@att.com > >> On May 7, 2014, at 1:46 PM, "Christer Holmberg" wrote: >> >> Hi Jim, >> >> Currently there are no use-cases which, for a given URI, would require m= ultiple values. >> >> But, if people think it would be useful to allow it for possible future = usage, we can for sure modify the ABNF to allow it. >> >> Regards, >> >> Christer >> >> Sent from my Sony Ericsson Xperia arc S >> >> "Calme, James A (Jim)" wrote: >> >> >> Hi, >> >> Looking at the ABNF for this new parameter it would appear that only a s= ingle value is expected to used. >> iotl-param =3D iotl-tag "=3D" iotl-value >> iotl-tag =3D "iotl" >> iotl-value =3D "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA" >> / "homeA-visitedA" /" visitedA-homeB" / gen-value >> >> Given the current set of values, it would seem reasonable that they woul= d be mutually exclusive. But do you expect this to always be true? Would it= be possible that if additional values are defined that they could complime= nt the currently set, i.e., should the syntax allow one or more values to b= e included? >> >> Jim >> >> _______________________________________________ >> 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 Thu May 8 10:42: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 9D14E1A00DA for ; Thu, 8 May 2014 10:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bEUSsLBWalM9 for ; Thu, 8 May 2014 10:42:43 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id A816B1A00D8 for ; Thu, 8 May 2014 10:42:42 -0700 (PDT) X-AuditID: c1b4fb3a-f79a86d0000010e9-72-536bc20d443d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 68.9C.04329.D02CB635; Thu, 8 May 2014 19:42:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Thu, 8 May 2014 19:42:37 +0200 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAxuudP///zawCAAG22oP//+eQA//9KsDCAAg/BAIABWf9pgAJZ9Wf//+JMgAAdF7GzAAOkqAD//+A7kP/+TO1q//yBiZD/90Vyy//uiiWA/9voUgD/t4yNoA== Date: Thu, 8 May 2014 17:42:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2F217A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2ECF6D@ESESSMB209.ericsson.se> <201405061532.s46FWhk5019260@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EECDD@ESESSMB209.ericsson.se> <201405071934.s47JYl3b000327@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2F07DE@ESESSMB209.ericsson.se> <536BA342.6040001@alum.mit.edu> In-Reply-To: <536BA342.6040001@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvjS7voexgg7dHtSyWTlrAarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj8+151oJZfBWvPr9gb2D8zNXFyMkhIWAi cbR9OQuELSZx4d56ti5GLg4hgaOMEo1LdjJDOIsZJTpbzjF1MXJwsAlYSHT/0wZpEBEIljh4 eCdYs7CAs8S/wxvYIeIuErs+d7OD9IoI7GKUuHZzCwtIL4uAisTF6WYgNbwCvhJfVj2DWtbI IbF/wkmwZk4BHYl1z1uYQWxGoIu+n1rDBGIzC4hL3HoynwniUgGJJXvOM0PYohIvH/9jhbCV gI5+wgpRryOxYPcnNghbW2LZwtfMEIsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWMosWp xcW56UZGeqlFmcnFxfl5enmpJZsYgZFycMtvqx2MB587HmIU4GBU4uFdWJIVLMSaWFZcmXuI UZqDRUmcd9Ii92AhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjBKSu0Qn7OMvD1NZbDL7r/WV tEeJ/9z+8Tdu6e9mtVI/p2Y8aQWfz+/A9dU8h0LEnl604dwxpfHVJdmjxVkHpn11OJdjaP9M snVTdPg8lc9nvm4wYf7D6iM+5W8VM/fqvT/q7VgnlV+MFv16k/lKXp366tvaF9M+XivpqVBY Pit20Q3Bmyf4BZVYijMSDbWYi4oTAQ7E0SB1AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/MfAX2XpGPng_CNok5c_yWNIT-Ow Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 08 May 2014 17:42:47 -0000 Hi, >>>> "lr" is just one example. Please take a look at the IANA list, and=20 >>>> see whether you think all the other parameters are "part of" the URI..= . >>> >>> True, I looked and the situation isn't as clear as I thought. But=20 >>> all of the URI parameters (other than > 'lr') seem to be examined=20 >>> only by a device constructing a request from the URI, or a device=20 >>> "within > the domain" of the URI; >> >> It still doesn't mean that the parameter is "part of" the URI. > > It is part of the URI by definition: > > SIP-URI =3D "sip:" [ userinfo ] hostport > uri-parameters [ headers ] > > It is also by definition an identifier of a resource. It is a *name*, lik= e your name. It is assigned by=20 > the owner of the resource, or by someone acting on behalf of the owner of= the resource. I am not really sure I understand, but I think there are many cases ("lr" i= s only one example - eventhough it is widely used) where that is not the ca= se. > It isn't really proper for others who simply want to *reference* that res= ource to change its name.=20 > Instead, we put information on how to reference the resource in other pla= ces, such as in header=20 > parameters. > > This is a philosophical point. I don't know if it is written down anywher= e. Certainly it has been=20 > violated. Yet I think it remains the right way to view things. If we have chosen a path, and we can't clearly show that it's semantically = wrong or breaks the protocol, I think we should stick to it. Otherwise it = is very difficult to design anything, and it only causes delays and frustra= tion, if people suddenly decide to become philosophical and then decide tha= t we can no more do things in certain ways... Regards, Christer From nobody Thu May 8 11:18:56 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 631501A00B7 for ; Thu, 8 May 2014 11:18:53 -0700 (PDT) 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, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M1fx06QSCjM for ; Thu, 8 May 2014 11:18:51 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D42481A00B2 for ; Thu, 8 May 2014 11:18:50 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s48IIb2q001012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 May 2014 13:18:38 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s48IIaTu014160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 May 2014 14:18:36 -0400 Received: from US70TWXCHMBA10.zam.alcatel-lucent.com ([169.254.4.2]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 8 May 2014 14:18:37 -0400 From: "Calme, James A (Jim)" To: Christer Holmberg , "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 - ABNF Thread-Index: Ac9qkZJIqq7oJYQfS0anruxhN3clMAALdoGQAAKwHWsAB95fIA== Date: Thu, 8 May 2014 18:18:36 +0000 Message-ID: <7B8DC1AC12241143921AC7733AF3C17B3B3B0140@US70TWXCHMBA10.zam.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D2F1260@ESESSMB209.ericsson.se>, <7B8DC1AC12241143921AC7733AF3C17B3B3AFEBC@US70TWXCHMBA10.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] 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/WqLP0metUtJwN_BRR-lNMBY1hz4 Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 - 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: Thu, 08 May 2014 18:18:53 -0000 Hi Christer, I'm flexible on what to use as a separator, so long as multiple values are = allowed. Dot seems to be as good as any other value. BR, Jim -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Thursday, May 08, 2014 9:31 AM To: Calme, James A (Jim); Dale R. Worley; dispatch@ietf.org Subject: RE: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 - ABNF Hi Jim, Ok, so perhaps we could use e.g. dot as separator (and disallow dot in the = value itself). Regards, Christer Sent from my Sony Ericsson Xperia arc S "Calme, James A (Jim)" wrote: Hi Christer, > Jim, just to verify: did you talk about multiple values for a single URI? [jac] Yes, on a single URI. > (If you have multiple URIs, you can naturally put a different value in ea= ch of them.) [jac] Understood, but not my immediate concern. ... > Regards, > Christer BR, Jim From nobody Thu May 8 12:11: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 E9CEA1A00F4 for ; Thu, 8 May 2014 12:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id We8RIXVj5sfd for ; Thu, 8 May 2014 12:11:50 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDFE1A00FE for ; Thu, 8 May 2014 12:11:50 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id lc6so3884910vcb.2 for ; Thu, 08 May 2014 12:11:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=jOzZOqnP0W0BaROCi7hvI1yifh1xvHmpncmtdJNWAOc=; b=BQzNIKLoWDBBQFUrcQ5MaMKw/uO8XH3M7FB1XlNBiMmZbDlmVz+tEkzz7mYRBsObVR gxi4b8kz7qiv5n2+WObLaEL1PShlqEZqr5XbYdupE3V5QmUC/jkeJXiKrAr6paUoQ5ox W17BKl6ToL76lxJD5ov7B5y6aNUG/KCKlFrsMN5m5DSBueuBbscU4XO/sUovYvJU+7ll LGJi6IE2ZWcPvyVc0jX30P65H84qGR4Ho/H6a+4+oWgzcat5GdaNwFO1Xw41ZdFBmQ9p GpNvw6Zrx87jhnEhkXCm8AYyAKHFvBBnmAtd3Z6WMEhX0x5q2HG9ShTjRdnv7CtUT/vC onkA== X-Gm-Message-State: ALoCoQm3PIxN750z0uyX7umugOq8CVWcrKyqrhon1j1wiLcxbvgpognba5d3vBTKR2KRw1KM0YqhqU0YJ/HxCL5IGPldVR0XYg== X-Received: by 10.58.198.36 with SMTP id iz4mr2162008vec.53.1399576305832; Thu, 08 May 2014 12:11:45 -0700 (PDT) From: Brett Tate References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2ECF6D@ESESSMB209.ericsson.se> <201405061532.s46FWhk5019260@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EECDD@ESESSMB209.ericsson.se> <201405071934.s47JYl3b000327@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2F07DE@ESESSMB209.ericsson.se> <536BA342.6040001@alum.mit.edu> <7594FB04B1934943A5C02 806D1A2204B1D2F217A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2F217A@ESESSMB209.ericsson.se> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAxuudP///zawCAAG22oP//+eQA//9KsDCAAg/BAIABWf9pgAJZ9Wf//+JMgAAdF7GzAAOkqAD//+A7kP/+TO1q//yBiZD/90Vyy//uiiWA/9voUgD/t4yNoP9vEd3g Date: Thu, 8 May 2014 15:11:45 -0400 Message-ID: <075749d6cdfbc47f77ae693fddf6c0ef@mail.gmail.com> To: dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/3mbcfou0Lvj6JUoNL8o-9bgJW8A Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 08 May 2014 19:11:53 -0000 Since RFC 3261 section 19.1.4 allows some parameters to be added or removed without it impacting equality, I'm not sure that I understand the arguments against allowing iotl to be included within a sip-uri. It may or may not be the best location for it; however it doesn't seem too different from the rest of the parameters that get shoved into the sip-uri (especially if needs to be received within a Request-URI). The following are the sip-uri parameters indicated within IANA: aai, bnc, cause, ccxml, comp, content-type, delay, duration, extension, gr, locale, lr, m, maddr, maxage, maxstale, method, method (yes IANA shows two method parameters), ob, param[n], play, postbody, repeat, sg, sigcomp-id, target, transport, ttl, user, and voicexml. > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: Thursday, May 08, 2014 1:43 PM > To: Paul Kyzivat; dispatch@ietf.org > Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 > > Hi, > > >>>> "lr" is just one example. Please take a look at the IANA list, and > >>>> see whether you think all the other parameters are "part of" the > URI... > >>> > >>> True, I looked and the situation isn't as clear as I thought. But > >>> all of the URI parameters (other than > 'lr') seem to be examined > >>> only by a device constructing a request from the URI, or a device > >>> "within > the domain" of the URI; > >> > >> It still doesn't mean that the parameter is "part of" the URI. > > > > It is part of the URI by definition: > > > > SIP-URI = "sip:" [ userinfo ] hostport > > uri-parameters [ headers ] > > > > It is also by definition an identifier of a resource. It is a *name*, > like your name. It is assigned by > > the owner of the resource, or by someone acting on behalf of the > owner of the resource. > > I am not really sure I understand, but I think there are many cases > ("lr" is only one example - eventhough it is widely used) where that is > not the case. > > > It isn't really proper for others who simply want to *reference* that > resource to change its name. > > Instead, we put information on how to reference the resource in other > places, such as in header > > parameters. > > > > This is a philosophical point. I don't know if it is written down > anywhere. Certainly it has been > > violated. Yet I think it remains the right way to view things. > > If we have chosen a path, and we can't clearly show that it's > semantically wrong or breaks the protocol, I think we should stick to > it. Otherwise it is very difficult to design anything, and it only > causes delays and frustration, if people suddenly decide to become > philosophical and then decide that we can no more do things in certain > ways... > > Regards, > > Christer -- See why you should attend BroadSoft Connections 2014 This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. From nobody Thu May 8 13:27: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 C3BC41A00D3 for ; Thu, 8 May 2014 13:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 pj2VRAXV6t5O for ; Thu, 8 May 2014 13:27:48 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 705301A0067 for ; Thu, 8 May 2014 13:27:47 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta10.westchester.pa.mail.comcast.net with comcast id zYCT1n0071ZXKqc5AYTifj; Thu, 08 May 2014 20:27:42 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta21.westchester.pa.mail.comcast.net with comcast id zYTi1n00S1KKtkw3hYTi36; Thu, 08 May 2014 20:27:42 +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 s48KRg1G027479; Thu, 8 May 2014 16:27:42 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s48KRfFp027478; Thu, 8 May 2014 16:27:41 -0400 Date: Thu, 8 May 2014 16:27:41 -0400 Message-Id: <201405082027.s48KRfFp027478@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <536B9F0D.6070506@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se> <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se> <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <201405052128.s45LSLN5031861@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EDB9F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B196261@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5369114B.20907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EED5E@ESESSMB209.ericsson.se> <5369258A.6050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EEF04@ESESSMB209.ericsson.se> <5369307F.6050003@alum.mit.edu> <201405071920.s47JKVZZ031293@hobgoblin.ariadne.com> <536B9F0D.6070506@alum.mit.edu> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399580862; bh=HeW3LhVQ42X/bZFsrbdqW7CucCQMwyQS5Am2KsaW4QE=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=bM2Do+cJY++ZnaJ3a8NVx9SBNqiQyYRb3HP9W/8ktNaFXeDIZ6qSVV0JjvSHolLXN MGuSC6GEDcXVeBTiFVaM37nodOChr/1TiDWJGXlXhxI9HyEYoNPvdzNyM3Iri8cSdW EFN1O3pdG3vX/FfphpXDxBkKdRe5ktmplPUkaZZAyjQ/GYkq8A/7FVv63MrWbuqi+q 0MMnG5LWlhCCC8LIXxk2xFQgRssVU/PesnBKCTp5o5Ttr/ueBoCPwxVCGB6cYBNwGk LnkJ7iA1/ZrvV4pV4vmudtr6M/X0Bpp6VHO7WySORBBblE0hO1xq4LXZmKeXYJVLOr qKMPkJJucloOg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/aFU7aG5_1EtVonM2iZ5_SAye1EQ Cc: dispatch@ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 08 May 2014 20:27:49 -0000 > From: Paul Kyzivat > On 5/7/14 3:20 PM, Dale R. Worley wrote: > > > Then, departing from VisitedA, the request would look like: > > > > INVITE B SIP/2.0 > > Route: > > Route: > > Route: > > From: ;tag=xxx > > To: ;tag=yyy > > I think you meant: > > INVITE B SIP/2.0 > Route: ;Iotl=visitedA-homeA > Route: ;Iotl=homeA-homeB > Route: ;Iotl=homeB-visitedB > From: ;tag=xxx > To: ;tag=yyy In this instance, I meant to use "headers" rather than header-parameters, to illustrate that possibility. Dale From nobody Thu May 8 13:35:28 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 F29C71A010C for ; Thu, 8 May 2014 13:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 w9amyKrwAC9B for ; Thu, 8 May 2014 13:35:25 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 715441A00FA for ; Thu, 8 May 2014 13:35:25 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta05.westchester.pa.mail.comcast.net with comcast id zVya1n00E1HzFnQ55YbLji; Thu, 08 May 2014 20:35:20 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta14.westchester.pa.mail.comcast.net with comcast id zYbL1n00J1KKtkw3aYbLfh; Thu, 08 May 2014 20:35:20 +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 s48KZJlB028231 for ; Thu, 8 May 2014 16:35:19 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s48KZJTN028230; Thu, 8 May 2014 16:35:19 -0400 Date: Thu, 8 May 2014 16:35:19 -0400 Message-Id: <201405082035.s48KZJTN028230@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D2F217A@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2ECF6D@ESESSMB209.ericsson.se> <201405061532.s46FWhk5019260@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EECDD@ESESSMB209.ericsson.se> <201405071934.s47JYl3b000327@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2F07DE@ESESSMB209.ericsson.se> <536BA342.6040001@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2F217A@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399581320; bh=wcn26wgh2eRIfpiMDAFHZj4gwnV0nRsQ1i3wlkNLAow=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=MXLwKJVAIKkUNGoZidvW33v7PS9SZrk5QvmaJF2M1vOR1GpPMmvsnUrJD1+NzzJBK stk2VzCv5dd+I1LdAwWex4tmLjA5P2wbZN9qTtc7cvqoDwz/Gx2N1phsQLah0qtoqS wLlm1cnErPYP+gCoMqTwHRBHeW5YwXCkeRvB2LV3lgwIeKAFo0DqXxtgzcU1S7JzWq +7+cPcIvrlYqnRJwizgJdEwQ38gGcmbEOUVCZHYndT9PYzgxa4NJdyuLdfNqKLXFgq sodk62KeziOHwt1eAOtWPcV5hdLd7/hxTAXWxYyiYNJRY14nKwT6YnZrq0mMx9ViOi 1gOuh87qq7C9Q== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/r0uaQ7s4L9jaFJUpBUKbgQ01MPg Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 08 May 2014 20:35:27 -0000 > From: Christer Holmberg > I am not really sure I understand, but I think there are many cases > ("lr" is only one example - eventhough it is widely used) where that > is not the case. Which URI parameters, other than "lr", are routinely manipulated by SIP entities outside of the domain of the URI? I didn't spot any myself, though I didn't examine the list comprehensively. > If we have chosen a path, and we can't clearly show that it's > semantically wrong or breaks the protocol, I think we should stick > to it. Uh, who is the "we" that has chosen a path? Currently, 3GPP has made a proposal, but (as far as I can tell from the document referenced by Keith), two alternatives (a header parameter and a "header" component) are quite similar relative to the advantages listed in the technical assessment document. And that document doesn't actually cover the various desired scenarios that are quoted in this discussion. As Cullen says, "I will note our agreement with 3GPP is they bring us problems not solutions and then we try and work on a solution together." > From: Christer Holmberg > What I meant was that there can't be "iotl" values in the > Request-URI and Route(s) at the same time. I am surprised that that idea. It seems natural to me that (assuming iotl is a URI parameter), the request-URI and the Route values can each have their own iotl. The "current" iotl is the one on the URI that currently controls routing of the request, either the topmost Route, or if one does not exist, the request-URI. (This is assuming all Route URIs have "lr"; if that isn't true, further rules are needed.) That allows the transport segment controlled by each Route URI to be within a different call leg. I've always assumed that is one of the desired features of this proposal. If there is only one iotl applicable to the whole set of URIs, then many more solutions become plausible. > From: Christer Holmberg > > > > The proposal is that the iotl information is encoded not in a URI > > parameter, but a header of the URI. (This does get around any > > semantic objection, because it is established that a 'header' is a > > decoration of the base URI, not intrinsically part of it.) > > Please show me some text justifying your claim. It's not particularly well described in RFC 3261, but when a request is to be sent to a URI containing a headers component, the headers component is removed and used to construct additional headers in the request. Hence, devices outside the domain of the URI are intended to manipulate the headers component of a URI. Dale From nobody Thu May 8 14:37:22 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 223C31A0179 for ; Thu, 8 May 2014 14:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c9VG1IRY_9P for ; Thu, 8 May 2014 14:37:19 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2841A0162 for ; Thu, 8 May 2014 14:37:19 -0700 (PDT) X-AuditID: c1b4fb25-f798c6d000001521-9f-536bf90a5245 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 90.6D.05409.A09FB635; Thu, 8 May 2014 23:37:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0174.001; Thu, 8 May 2014 23:37:13 +0200 From: Christer Holmberg To: "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewAAPReaAAAxuudP///zawCAAG22oP//+eQA//9KsDCAAg/BAIABWf9pgAJZ9Wf//+JMgAAdF7GzAAOkqAD//+A7kP/+TO1q//yBiZD/90Vyy//uiiWA/9voUgD/t4yNoP9u5qvo/t3FgmA= Date: Thu, 8 May 2014 21:37:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2F29B1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2ECF6D@ESESSMB209.ericsson.se> <201405061532.s46FWhk5019260@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EECDD@ESESSMB209.ericsson.se> <201405071934.s47JYl3b000327@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2F07DE@ESESSMB209.ericsson.se> <536BA342.6040001@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2F217A@ESESSMB209.ericsson.se> <201405082035.s48KZJTN028230@hobgoblin.ariadne.com> In-Reply-To: <201405082035.s48KZJTN028230@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.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvjS7Xz+xgg4ttfBZLJy1gtXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgyph5bClrwT2ZikU3F7E3MF4R62Lk5JAQMJG4 u2UaI4QtJnHh3nq2LkYuDiGBo4wS/xd/YwFJCAksZpQ41p3SxcjBwSZgIdH9TxskLCIQIvF5 WidYr7CAs8S/wxvYIeIuErs+d7ODzBEROMYo0dd7hBkkwSKgItH++RpYEa+Ar8TN+bvZIZb9 5pCYeOcYWIJTwEHi6q17YFMZgS76fmoNE4jNLCAucevJfCaISwUkluw5zwxhi0q8fPyPFcJW klh7eDsLRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMYoW pxYn5aYbGeulFmUmFxfn5+nlpZZsYgTGycEtv1V3MF5+43iIUYCDUYmHV+FYdrAQa2JZcWXu IUZpDhYlcd4vt3yChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBWnd1mPv20s29De9JHjonH Qu/uEj5tf/R35L4jM7qmlF3ut3G0mJCz4tQrFYmKkzOuzV0wqWX17XKXqMRj2pOaPBddbmDb JLPkX4DBZb3ZjvolL5ke1i678DGl6kfH5YKLM76u3XyAycFM/3Z4aWsij4VJyYyfm6oV1PS/ P7q0NcnuZ/an2r9+SizFGYmGWsxFxYkARpOfQHQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/ys3xey6oYG_5kk1YR-PEUSLDP4c Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 08 May 2014 21:37:21 -0000 Hi, >> I am not really sure I understand, but I think there are many cases=20 >> ("lr" is only one example - eventhough it is widely used) where that=20 >> is not the case. > > Which URI parameters, other than "lr", are routinely manipulated by SIP e= ntities outside of the=20 > domain of the URI? I didn't spot any myself, though I didn't examine the= list comprehensively. What do you mean by "routinely manipulated"? >> If we have chosen a path, and we can't clearly show that it's=20 >> semantically wrong or breaks the protocol, I think we should stick to=20 >> it. > > Uh, who is the "we" that has chosen a path?=20 The IETF community, that has defined the existing URI parameters. > Currently, 3GPP has made a proposal, but (as far as I can tell from the d= ocument referenced by=20 > Keith), two alternatives (a header parameter and a "header" component) ar= e quite similar relative > to the advantages listed in the technical assess= ment document. And that document doesn't=20 > actually cover the various desired scenarios that are quoted in this disc= ussion. The plan is to add the header parameter alternative to that document. More on the headers component below. > As Cullen says, "I will note our agreement with 3GPP is they bring us pro= blems not=20 > solutions and then we try and work on a solution together." Sure, and I am happy to discuss alternatives (which we are currently doing = :).=20 But, people suggesting alternatives should also show why a suggested soluti= on does not work. >> What I meant was that there can't be "iotl" values in the Request-URI=20 >> and Route(s) at the same time. > > I am surprised that that idea. It seems natural to me that (assuming iot= l is a URI parameter), the=20 > request-URI and the Route values can each have their own iotl. The "curr= ent" iotl is the one on the > URI that currently controls routing of the re= quest, either the topmost Route, or if one does not=20 > exist, the request-URI. (This is assuming all Route URIs have "lr"; if t= hat isn't true, further rules are > needed.) > > That allows the transport segment controlled by each Route URI to be with= in a different call leg. =20 > I've always assumed that is one of the desired features of this proposal. > > If there is only one iotl applicable to the whole set of URIs, then many = more solutions become=20 > plausible. As long as we can specify how to determine the "current", we can allow what= ever combinations. >>> The proposal is that the iotl information is encoded not in a URI=20 >>> parameter, but a header of the URI. (This does get around any=20 >>> semantic objection, because it is established that a 'header' is a=20 >>> decoration of the base URI, not intrinsically part of it.) >>=20 >> Please show me some text justifying your claim. > > It's not particularly well described in RFC 3261, but when a request is t= o be sent to a URI containing > a headers component, the headers component = is removed and used to construct additional=20 > headers in the request. Hence, devices outside the domain of the URI are= intended to manipulate > the headers component of a URI. But, how is that semantically more correct? When the INVITE is sent, nobody= is going to remove the Iotl headers components from the URIs and construct= additional Iotl headers to the request.=20 If I understand you correctly, you are suggesting to define a new SIP heade= r field (Iotl) that will never we used as a "standalone" header field in a = request - only as a headers component in a URI...? Regards, Christer From nobody Fri May 9 04:01:29 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 D1DCF1A026B for ; Fri, 9 May 2014 04:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZM9ahZNTCbM for ; Fri, 9 May 2014 04:01:26 -0700 (PDT) Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEB01A0243 for ; Fri, 9 May 2014 04:01:26 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id oy12so4926458veb.24 for ; Fri, 09 May 2014 04:01:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=SZgNQxbZk0xgwCoR5smHHXOUv6r9DCLQA42+PsU3POM=; b=jdnlloS2ClWR7hPno3TiTFIQ3VgiVyE+xgUELeWRnUbPQvu33lTXf0nVPBwhgBsdTp JB0epA1QfOdVLbuo1DDWTy0ti8IGyaSbPI8Klgol1emxDmia52h24bfcnM5J3UzhyAhD C6MGaY+hxCRXni4k/5nVtT87QSid2vXPrAq2MKZFbgz66e3cxpuuBvcjqa9r3fqbzCZk TNORLedcLBvSJ1iZuED3Nzj3ulwSAOOjzoNlTwMlJOPJpvEQ7eP9qsGqwSmH4owrv2eZ q2aYMt97tpRQj7vXOtXMa6DQGQwrs3JfqL2BujatdIqMTVoyF7IxXNtvNNJlPG92Ee3h CWrg== X-Gm-Message-State: ALoCoQmWe01+iv3+iTcU6rt+bN9upKyyETFAYlDb9DKROEkvv/w0UZi6rcosIF0Sm3ajMm1Ktrjm9wPIesoWTQuC9BVBRZ982Q== X-Received: by 10.58.211.69 with SMTP id na5mr1795313vec.30.1399633281266; Fri, 09 May 2014 04:01:21 -0700 (PDT) From: Brett Tate References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E7936@ESESSMB209.ericsson.se>, <536272FA.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E81D4@ESESSMB209.ericsson.se> <5362C9E2.1040306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E90B6@ESESSMB209.ericsson.se>, <5363EC80.9010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2EA8E6@ESESSMB209.ericsson.se>, <201405050138.s451cIJ7002929@hobgoblin.ariadne.com> <035F9B3F-F923-4FBB-B0C1-ABAAD84491D4@att.com> <201405051344.s45Dixmj016585@hobgoblin.ariadne.com> <53679992.5060404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2ECF6D@ESESSMB209.ericsson.se> <201405061532.s46FWhk5019260@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2EECDD@ESESSMB209.ericsson.se> <201405071934.s47JYl3b000327@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D2F07DE@ESESSMB209.ericsson.se> <536BA342.6040001@alum.mit.edu> <7594FB04B1934943A5C02 806D1A2204B1D2F217A@ESESSMB209.ericsson.se> <201405082035.s48KZJTN028230@hobgoblin.ariadne.com> In-Reply-To: <201405082035.s48KZJTN028230@hobgoblin.ariadne.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9q/QryUMUz4vqARP6D1Kceoc13lAAcaGZA Date: Fri, 9 May 2014 07:01:21 -0400 Message-ID: To: "Dale R. Worley" , dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/6Umeav_osFeeqbn3iLL5yzqVGvo Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-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, 09 May 2014 11:01:28 -0000 > Which URI parameters, other than "lr", are routinely > manipulated by SIP entities outside of the domain of > the URI? Parameters that are malformed or problematic routinely get removed or adjusted if configured or chose to remove/adjust the parameter instead of rejecting the request or relaying the malformed or problematic URI. Since RFC 3261 changed the RFC 2543 equality rules, parameters with default values are no longer routinely manipulated. > It's not particularly well described in RFC 3261, but > when a request is to be sent to a URI containing a > headers component, the headers component is removed > and used to construct additional headers in the request. > Hence, devices outside the domain of the URI are > intended to manipulate the headers component of a URI. RFC 3261 sections 19.1.1 and 19.1.2 (Table 1) indicate that headers are not allowed within Route. -- See why you should attend BroadSoft Connections 2014 This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. From nobody Mon May 12 05:52:15 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 71ED21A0698 for ; Mon, 12 May 2014 05:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvh_G8MHZKcW for ; Mon, 12 May 2014 05:52:13 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4538F1A0694 for ; Mon, 12 May 2014 05:52:13 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-b3-5370c3f6f44f Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.12.04714.6F3C0735; Mon, 12 May 2014 14:52:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Mon, 12 May 2014 14:52:05 +0200 From: Christer Holmberg To: Brett Tate , "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 - headers alternative Thread-Index: Ac9t4KdaxFU4+tm0TTOsP0L0vbc7GA== Date: Mon, 12 May 2014 12:52:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2F7529@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvje63wwXBBr/atC2a5/9jtFg6aQGr xcsTZQ7MHpP3f2X2+HE70GPJkp9MAcxRXDYpqTmZZalF+nYJXBknz4kX3GSt+HHkJlsD4xaW LkYODgkBE4njf926GDmBTDGJC/fWs4HYQgJHGSV2P4yBsJcwSszZmwRSziZgIdH9TxskLCJQ JnHyVyMriC0sECXxY9Z8Joh4tETfj2UsELaeRPuRqWBxFgFViTeP7rOD2LwCvhIL2t+BrWIE Wvv91BqwGmYBcYlbTyDmSAgISCzZc54ZwhaVePn4HyvExYoSy/vlIMp1JBbs/sQGYWtLLFv4 mhlivKDEyZlPWCYwCs9CMnUWkpZZSFpmIWlZwMiyilG0OLW4ODfdyFgvtSgzubg4P08vL7Vk EyMw+A9u+a27g3H1a8dDjAIcjEo8vAraBcFCrIllxZW5hxilOViUxHnb7noHCwmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamBMOJzgZ5uVtvCDf+wBz+sbr1952pX9T/h6yqp1Ojsvyi13UnsU yTNtktuCaQu/LNZIbf2S0yNnEF11Lfvdrf7KH5wd3GsOtWittt4bWnWBV8n41dUtv6eyWEcw PBM1SvLyXnLoVq7E33pZzXLP1bl211TWH77k/W3pN81pW5dz3nx48esP0+sTlFiKMxINtZiL ihMB5+pIPl8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/LQ3PF_T94NCv0qaGH0bg36csBAg Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 - headers alternative 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, 12 May 2014 12:52:14 -0000 Hi, >> It's not particularly well described in RFC 3261, but when a request=20 >> is to be sent to a URI containing a headers component, the headers=20 >> component is removed and used to construct additional headers in the=20 >> request. >> Hence, devices outside the domain of the URI are intended to=20 >> manipulate the headers component of a URI. > > RFC 3261 sections 19.1.1 and 19.1.2 (Table 1) indicate that headers are n= ot allowed within Route. Correct. Also, 19.1.1 says: "Headers: Header fields to be included in a request constructed from the URI." But, when iotl is included in an INVITE, the receiver is not going construc= t a request from the URI. Regards, Christer From nobody Tue May 13 02:00: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 3D9231A044A for ; Tue, 13 May 2014 02:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FJmu3hiaOvp for ; Tue, 13 May 2014 02:00:02 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DC9A31A018F for ; Tue, 13 May 2014 02:00:01 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-9f-5371df0af201 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id FB.69.04714.A0FD1735; Tue, 13 May 2014 10:59:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Tue, 13 May 2014 10:59:54 +0200 From: Christer Holmberg To: "dispatch@ietf.org" Thread-Topic: IOTL: use-case message flows Thread-Index: Ac9uiUabYgQH5rIbTXuc/QqKi86GDw== Date: Tue, 13 May 2014 08:59:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2F9DAA@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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D2F9DAAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvjS73/cJgg83zOCyWTlrA6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFM/bQrOSlY03jjO3sD4WayLkZNDQsBE4sKU1UwQtpjEhXvr 2boYuTiEBI4yShy/Pp8VwlnCKLF69SPmLkYODjYBC4nuf9ogDSIC2hJHV3Uxg9jCAqoSPYdm skPEtSQO3djBAmHrSRye3QFWwwJU83bbCxaQMbwCvhKzriuBhBmB9n4/tQbsBmYBcYlbT+ZD 3SMgsWTPeWYIW1Ti5eN/rBC2osTV6cuh6vMl9k07zwZi8woISpyc+YRlAqPQLCSjZiEpm4Wk DCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnE CIyHg1t+6+5gXP3a8RCjAAejEg+vAk9hsBBrYllxZe4hRmkOFiVx3ra73sFCAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGKf0f7k8gf2Fcpzxiif7fh8+ergoV3DPVV855u53JyK3dW0Wcry6 PrNi36QXHga2oXqlSgJWW0teB3DLsr3Sn7f6qfTl+93Pk+ZJaMU+5zV4fjY2PdDRzeeEJMf0 OSr1bi8atkkv7NjXu/SP3ana+onPXzdzC++b3D/zq2Px918GijrJH/MOT1RiKc5INNRiLipO BADyW3mMaAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/fa7KF5-HC7BExHekgGNf84dWnbw Subject: [dispatch] IOTL: use-case message flows 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, 13 May 2014 09:00:04 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D2F9DAAESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below is a link to a discussion document, submitted to the upcoming 3GPP CT= 1 meeting, showing use-case message flows for iotl (using the SIP URI param= eter solution). ftp://ftp.3gpp.org/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_87_Phoenix/docs/C1-1417= 55.zip You can skip the THIG flows. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D2F9DAAESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_7594FB04B1934943A5C02806D1A2204B1D2F9DAAESESSMB209erics_-- From nobody Wed May 14 06:30: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 8BACE1A0821 for ; Mon, 12 May 2014 20:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JEtZdP3hldo for ; Mon, 12 May 2014 20:45:39 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4785B1A0823 for ; Mon, 12 May 2014 20:45:39 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id w8so7869810qac.5 for ; Mon, 12 May 2014 20:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=gIQbFsmBq4iWM2dtgGsY9RoLGblIW5F2jCoIY9mE/cg=; b=w9xaJWocMlk4n0MAbRufQWKT7BTsNyc5gVAbQEjFdZbCnsBclri7l+cxxRm6Csy9g2 kXnN5nXAZ3NyQYhulqZzHQeNDXCv3Z1Ktyjw1vR70h4Ngi1ZjUV/5OC45cNJNodRYSki y0YG39G6PfZtANfKfABPumIWO3Wfq2zACxitY2Q4Z5FmgZVD0zhI8ThGmOR0d1Ye97yO LU/jJTQRPTPoef95GtK2sdqIzk+g9HMNqzK+4tE9fl6KArLPw/TRJFhtP7dsmnCKgONd mw4IYHG0EH0Rj5PDU+kR61fV0DlOnlbcN7wD8CfPz7GmfEx46dcZs2DLKxy+tzvsl4VK TzXw== X-Received: by 10.140.29.34 with SMTP id a31mr41603635qga.95.1399952732984; Mon, 12 May 2014 20:45:32 -0700 (PDT) MIME-Version: 1.0 Sender: doug.turner@gmail.com Received: by 10.140.93.99 with HTTP; Mon, 12 May 2014 20:45:12 -0700 (PDT) From: Doug Turner Date: Mon, 12 May 2014 20:45:12 -0700 X-Google-Sender-Auth: 5UehBOlcyUpCJsXoKhuM3_cBOLo Message-ID: To: dispatch@ietf.org, mary.ietf.barnes@gmail.com, fluffy@cisco.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/iKZgpaH9swAo_-DzoNPdDGDsAYk X-Mailman-Approved-At: Wed, 14 May 2014 06:30:05 -0700 Cc: Andrei Popescu , Jungkee Song , "Ebert, Bob" Subject: [dispatch] web push protocol 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, 13 May 2014 03:45:40 -0000 Hi all, The W3C web apps working group is specifying a web API for delivering push notifications on the web. This is a well-understood space with a number of proprietary solutions. The goal of work in the IETF is: 1. to define a protocol that can be used to send push messages from an application to a device 2. to define a protocol that can be used to support the registration features of the API We are using webpush@ietf.org to discuss this work, and there is already a draft submitted that addresses both use cases [1]. Sincerely yours, Doug Turner [1] http://tools.ietf.org/html/draft-thomson-webpush-http2-00 From andreip@google.com Tue May 13 03:29:03 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 C77391A000D for ; Tue, 13 May 2014 03:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 kIV9LrJmox4U for ; Tue, 13 May 2014 03:29:02 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id DCBDA1A0037 for ; Tue, 13 May 2014 03:29:01 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h3so192828igd.8 for ; Tue, 13 May 2014 03:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kGQTEUcfxnhG+hF83Q4hwdieAipyUhzS3ZXjXWCGzGM=; b=XehSeqoloGaAwFljRoUicU+AVNKgDUBiukNhs5RJZ0+cL3w6oFr+ISRpXriKbH44ep FsOJ2ArPX5uzBjkm5NPC9j6eFeZ2YW4K6DbDnBagIay0gXORijK2VhEgZIKTpSHP6MA/ +O6GaS/YPXCXxTs5iNKpFOCXoEavGbtLmvoIKkIFwcidQCopxVQ4hHIvUeGe+LXC284Y oQBHt+cH3KUbmTUbYRIBo/BD8Z2WOJaGOrcSSM3bV2qYoRAv4cHrtdXLgha7008xL3gy JeCmzHnAYDOTL2z826X8uInJlJi03PsOwJKNhLsornuEpIJMtFw03bRspOLXMevU3uOP 85tA== 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=kGQTEUcfxnhG+hF83Q4hwdieAipyUhzS3ZXjXWCGzGM=; b=GrCS3bNLhBiy73yyXso7H91sUpC6C0RUWUXZx2M0zTrP9T9KRqLqyQR2KIDPeHEflt NuPQWW2hhkFx64l3knsKPtRRP3FENYWNvtuG5tv47+kg1Xx2HIkTgp9QmJu36tyRHH+t 8+E1snltOOf1JPjH55HilP9j7STjR8LdtEibW5C09OOdQOsoUMJCXD5V08FdE3xSC15X 6rCAoxSp75ZwJlTZizR4qSSOd1l+bwjOJEtZEPh3Ydclum08wC3f8aFxkUiyrHqRcVQG Hu2TmyktpLhbAbPQ7a1qZRY+yLi6njN5kMeoi0ZyIgO7/5q5MSqh6qNYuZa6SQ9ZhqSl 4G7g== X-Gm-Message-State: ALoCoQneNNW2kXuniBOrVNCq/yoVTNwsKAWVjiyC96aR2WDipHA0Kx5WE/uZaZKsEGmqOPjkZ3RN MIME-Version: 1.0 X-Received: by 10.50.82.105 with SMTP id h9mr53271473igy.6.1399976935331; Tue, 13 May 2014 03:28:55 -0700 (PDT) Received: by 10.65.14.130 with HTTP; Tue, 13 May 2014 03:28:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 May 2014 11:28:55 +0100 Message-ID: From: Andrei Popescu To: Doug Turner Content-Type: multipart/alternative; boundary=089e0111bb5cecc3c304f945878a Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/lB9MU9LGF6ByuCw6DThxNAhYx34 X-Mailman-Approved-At: Wed, 14 May 2014 06:30:05 -0700 Cc: fluffy@cisco.com, dispatch@ietf.org, Jungkee Song , "Ebert, Bob" Subject: Re: [dispatch] web push protocol 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, 13 May 2014 10:30:18 -0000 --089e0111bb5cecc3c304f945878a Content-Type: text/plain; charset=UTF-8 Hi Doug! Thanks a lot for this. We are happy to help with this effort! All the best, Andrei On Tue, May 13, 2014 at 4:45 AM, Doug Turner wrote: > Hi all, > > The W3C web apps working group is specifying a web API for delivering > push notifications on the web. > > This is a well-understood space with a number of proprietary > solutions. The goal of work in the IETF is: > > 1. to define a protocol that can be used to send push messages from an > application to a device > > 2. to define a protocol that can be used to support the registration > features of the API > > We are using webpush@ietf.org to discuss this work, and there is > already a draft submitted that addresses both use cases [1]. > > Sincerely yours, > Doug Turner > > [1] http://tools.ietf.org/html/draft-thomson-webpush-http2-00 > --089e0111bb5cecc3c304f945878a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Doug!

Thanks a lot for this. We are = happy to help with this effort!

All the best,
Andrei




On Tue, May 13, 2014 at 4:45 AM, Doug Tu= rner <dougt@mozilla.com> wrote:
Hi all,

The W3C web apps working group is specifying a web API for delivering
push notifications <https://w3c.github.io/push-api/> on the web.

This is a well-understood space with a number of proprietary
solutions. =C2=A0The goal of work in the IETF is:

1. to define a protocol that can be used to send push messages from an
application to a device

2. to define a protocol that can be used to support the registration
features of the API

We are using webpush@ietf.org to di= scuss this work, and there is
already a draft submitted that addresses both use cases [1].

Sincerely yours,
Doug Turner

[1] http://tools.ietf.org/html/draft-thomson-webpush-http2-00<= /a>

--089e0111bb5cecc3c304f945878a-- From nobody Wed May 28 01:39: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 637F71A010B for ; Wed, 28 May 2014 01:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbgT6kMwH5Z8 for ; Wed, 28 May 2014 01:39:15 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0540F1A0161 for ; Wed, 28 May 2014 01:39:14 -0700 (PDT) X-AuditID: c1b4fb2d-f79ed6d000003d40-46-5385a0ad79a2 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 82.FD.15680.DA0A5835; Wed, 28 May 2014 10:39:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Wed, 28 May 2014 10:39:09 +0200 From: Christer Holmberg To: "dispatch@ietf.org" Thread-Topic: IOTL: use-case message flows - new version Thread-Index: Ac96UCZbKSDinI8fTpm9Z2HhHcYnuw== Date: Wed, 28 May 2014 08:39:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D341B2D@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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D341B2DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje66Ba3BBjP+cVssnbSA1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGd93n2ErmGxcsWrhP7YGxru6XYycHBICJhLd7bdYIGwxiQv3 1rN1MXJxCAkcZZToeHGRHSQhJLCYUWLBl/guRg4ONgELie5/2iBhEQFtiaOruphBbGEBc4mt e9ayQ8QtJKZtOANl60k8WPmKDcRmEVCVWLvxH5jNK+ArMbuxhxHEZgTa+/3UGiYQm1lAXOLW k/lMEPcISCzZc54ZwhaVePn4HyuErSix82w7M0R9vsT3pzNYIWYKSpyc+YRlAqPQLCSjZiEp m4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9iFC1OLS7OTTcy1kstykwuLs7P08tL LdnECIyIg1t+6+5gXP3a8RCjAAejEg/vgkstwUKsiWXFlbmHGKU5WJTEeS9pVAcLCaQnlqRm p6YWpBbFF5XmpBYfYmTi4JRqYAxd8Ead+zODeEeXxqZb0ofb/7CLflzxyGbKtZDKOy+5fW5Y +z/Vmsazr8fP4Wtrw+x1JQVp+7fIV+s3fW/8rDzJI6u1a69NUP/m+Ywv3c6dctaz7rX+l6TB Y8+vuNn8y6klJx4+aDTg8Nqz8+gMw+yyi7Ed+Wv/HX/N1XBq0YWrgfxR2kKPViuxFGckGmox FxUnAgD0V3jFaQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/r-aamjZSchXb1sRYzotp0civs6Q Subject: Re: [dispatch] IOTL: use-case message flows - new version 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, 28 May 2014 08:39:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D341B2DESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below is an updated version of the discussion document with use-cases. The = THIG flows have been removed, and some bugs have been fixed. There is still one minor bug, though. In section 2.1.1, the P-CSCF inserts = "homeB-visitedB" in the REGISTER request (the P-CSCF box says "homaA-visite= dA). ftp://ftp.3gpp.org/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_87_Phoenix/docs/C1-1423= 54.zip Regards, Christer From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Hol= mberg Sent: 13. toukokuuta 2014 12:00 To: dispatch@ietf.org Subject: [dispatch] IOTL: use-case message flows Hi, Below is a link to a discussion document, submitted to the upcoming 3GPP CT= 1 meeting, showing use-case message flows for iotl (using the SIP URI param= eter solution). ftp://ftp.3gpp.org/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_87_Phoenix/docs/C1-1417= 55.zip You can skip the THIG flows. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D341B2DESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

Below is an updated ve= rsion of the discussion document with use-cases. The THIG flows have been r= emoved, and some bugs have been fixed.

 

There is still one min= or bug, though. In section 2.1.1, the P-CSCF inserts “homeB-visitedB&= #8221; in the REGISTER request (the P-CSCF box says “homaA-visitedA).=

 

ftp= ://ftp.3gpp.org/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_87_Phoenix/docs/C1-142354.= zip

 

Regards,

 

Christer

 

 

 

 

 

From: dispatch= [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 13. toukokuuta 2014 12:00
To: dispatch@ietf.org
Subject: [dispatch] IOTL: use-case message flows

 

Hi,

 

Below is a link to a discussion document, submitted = to the upcoming 3GPP CT1 meeting, showing use-case message flows for iotl (= using the SIP URI parameter solution).

 

ftp://ftp.3gpp.= org/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_87_Phoenix/docs/C1-141755.zip=

 

You can skip the THIG flows.

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D341B2DESESSMB209erics_-- From nobody Fri May 30 07:28: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 EF9681A0911; Fri, 30 May 2014 07:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 QInsDuiKo73Y; Fri, 30 May 2014 07:28:23 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5511A0901; Fri, 30 May 2014 07:28:22 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id bs8so1250123wib.6 for ; Fri, 30 May 2014 07:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EhdaMli6ItsBkZDhY51nUPfK+aRLzl3xlGcING2sDM4=; b=GbMtDjAF6mxHBWt3ITorkOzFiGPXp1pQT740HHKsF0dUQm9hxd7eRrVhWvAeMMHuUS mUHrIeX3jcsryH+4e2q7F7q50mC7/H3iPm+c+G64kbbxNZm6pnoBczpGB7GDNHCRuaZj iOe9l7dcIWHBCE037cy7i3EpieLxbT6TmN59/qqq6WQzY+kqVo53ZcHwqFJ2pPfuVn9l BLQuMc2rkxYRRhBeJs+SUqYp0Wdmu9vw/tCUljgHGrjgb73n4zzTNiT2vMwZ/Ym9RQjX f3jAgztq8cIebc65hbmGlRqhTOoj4d5Qu4ASomZ5i555hJMIa3+C5kB8s0Y65mkUPNkU Od6Q== MIME-Version: 1.0 X-Received: by 10.194.184.179 with SMTP id ev19mr22669867wjc.85.1401460095782; Fri, 30 May 2014 07:28:15 -0700 (PDT) Received: by 10.216.202.74 with HTTP; Fri, 30 May 2014 07:28:15 -0700 (PDT) In-Reply-To: <53862503.2a108c0a.3b2d.60c4SMTPIN_ADDED_BROKEN@mx.google.com> References: <53862503.2a108c0a.3b2d.60c4SMTPIN_ADDED_BROKEN@mx.google.com> Date: Fri, 30 May 2014 09:28:15 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=047d7b87371e2d155a04fa9edb53 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/peNZnnvpNK1ZPP95isghwMHoIxQ Cc: SIPCORE Subject: [dispatch] Fwd: [SIPForum-techwg] SIPNOC 2014: Only Two Weeks Away! 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, 30 May 2014 14:28:26 -0000 --047d7b87371e2d155a04fa9edb53 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm forwarding this as I believe the event is quite relevant for a lot of folks on this list. If your schedule allows I think you'll find a lot of the topics to be of interest. Regards, Mary. ---------- Forwarded message ---------- From: Marc Robins Date: Wed, May 28, 2014 at 1:00 PM Subject: [SIPForum-techwg] SIPNOC 2014: Only Two Weeks Away! To: techwg@sipforum.org [image: Introducing SIPNOC - The SIP Network Operators Conference] *PLATINUM SPONSORS* [image: Image] *GOLD SPONSORS * [image: Image] [image: Image] [image: Image] [image: Image] *POWERSTATION SPONSORS* [image: Image] Two-Weeks Till SIPNOC 2014! Don=E2=80=99t Miss the Opportunity to Network with Some of the IP Communica= tions Industry=E2=80=99s Best and Brightest! Now in its fourth year, *SIPNOC 2014* is a unique educational conference for international telecom stakeholders responsible for the deployment, management and ongoing operation of SIP-based services in service provider networks. Come meet the engineering talent from service providers of all sizes, leading equipment vendors, and the brightest minds doing academic research. *Symposium Atmosphere, Absent of Marketing Spin* This is not a marketing meeting full of vendor sales pitches. It's about real-world problems and how the technical community is solving them. *Learn how to* *avoid problems before you even encounter them.* Attending service providers have included AT&T, Armstrong Utilities, babyTEL, Bandwidth.com, Bell Canada, Bright House Networks, Broadvox, Cablevision, Cbeyond, Cinchcast, Cincinnati Bell, Comcast Cable, Cologix, Consolidated Telecom, Cox Communications, Deutche Telecom, France Telecom Orange, Global Crossing, Grandstream Networks, iBasis, Level3, Liveops, nexVortex, NTT, One Source Networks, Optimum Lightpath, Purple Communications, Rogers Business Solutions, Shoretel, Socket Telecom, Sorenson Communications, Sprint, Swisscom, TDS Telecom, Time Warner Cable, Telefonica International, Telmex, UNINETT, Verizon, Vocalocity, Vonage, Voxbone, WDT (World Discount Telecommunications), Wholesale Carrier Services, XO Communications, and Ziggo. In addition to carrier participants, SIPNOC regularly attracts a group of SIP community stakeholders from vendors, governments and research organizations such as AudioCodes, Avaya, Broadsoft, CableLabs, Cequint, Cisco Systems, Commetrex, Current Analysis, Dialogic, ECG Inc, Edgewater Networks, Ericsson, Faxcore, Federal Communications Commission, GENBAND, Georgetown University, Huawei Technologies, iconectiv, Integrated Research, Internet Society (ISOC), Metaswitch Networks, NENA, NetNumber, NTCA, Oracle, Patton Electronics, Polycom, Public Knowledge, RecordMyCalls, Sangoma Technologies, Sansay, SecureLogix, ScanSource, SNOM Technology, Sonus Networks, UNH-IOL, Unify, and Yealink Network Technology. You can review the *SIPNOC 2014 conference schedule * and list of presenters now. Speakers will explore critical =E2=80=9Creal-world=E2=80=9D service provide= r challenges related to SIP applications and infrastructure, including: network security, SIP trunking, testing and application development, Fax over IP, call routing and peering, IPv6, troubleshooting and monitoring, emergency services and more. *SIPNOC 2014 Registration Information* For a limited time, you can take advantage of a special discounted rate of $895, a savings of $100 off the regular rate. To obtain the discount, enter the following code on the registration page: =E2=80=9Csipnoctmc100=E2=80=9D= . Your registration includes access to all conference sessions, keynotes, meals and breaks, plus networking receptions each evening. *To register for SIPNOC 2014, please visit http://www.regonline.com/sipnoc2014 .* *Don't Forget!* Individuals from SIP Forum Full Member companies save even more! Please contact Marc Robins, SIP Forum President and Managing Director, at marc.robins@sipforum.org to obtain the exclusive Full Member discount code. *Hotel Reservations* SIPNOC 2014 is located at the four-star Hyatt Dulles Hotel. To reserve your stay at the Hyatt Dulles, please visit: https://resweb.passkey.com/go/SIPNOC2014 *For more information, please visit:www.sipnoc.org or email sipnocinfo@sipforum.org * _______________________________________________ techwg mailing list Send mail to: techwg@sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techw= g --047d7b87371e2d155a04fa9edb53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm forwarding this as I believe the event is quite re= levant for a lot of folks on this list. =C2=A0If your schedule allows I thi= nk you'll find a lot of the topics to be of interest.

Regards,
Mary.=C2=A0

---------- Forwarded mes= sage ----------
From: Marc Robins <marc.robins@s= ipforum.org>
Date: Wed, May 28, 2014 at 1:00 PM
Subject: [SIPForum-techwg] SIPNOC 201= 4: Only Two Weeks Away!
To: techw= g@sipforum.org


=C2=A0

<= table border=3D"0" cellspacing=3D"0" cellpadding=3D"0" width=3D"650" style= =3D"width:487.5pt;background:white">

3D"Introducing

=

=

=

= =

=

3D"Image"=

PLATINUM SPONSORS

GOLD SPONSORS <= u>

3D"=

3D"I=

3D"I=

3D"Image"

POWERST= ATION SPONSORS

3D"Image=

= Two-Weeks Till SIPNOC = 2014!

Don=E2=80=99t Miss the Opportunity to= Network with Some of the IP Communications Industry=E2=80=99s Best and Bri= ghtest!

Now in its fourth year, SIPNOC 2014 is a unique educational conference for international telecom stakeholder= s responsible for the deployment, management and ongoing operation of SIP-b= ased services in service provider networks. =C2=A0Come meet the engineering= talent from service providers of all sizes, leading equipment vendors, and the brightest minds doing academic= research.

Symposium Atmosphere, Absent of Marketing Spin
=
This is not a marketing meeting full of vendor sales=C2=A0pitches. It&#= 39;s about real-world problems and how the technical community is solving t= hem.=C2=A0Learn how to=C2=A0avoid problems=C2=A0before you even= encounter them.

Attending service providers have included AT&T, Armstrong Utilities= , babyTEL, Bandwidth.com, Bell Canada, Bright House Networks, Broadvox, Cab= levision, Cbeyond, Cinchcast, Cincinnati Bell, Comcast Cable, Cologix, Cons= olidated Telecom, Cox Communications, Deutche Telecom, France Telecom Orang= e, Global Crossing, Grandstream Networks, iBasis, Level3, Liveops,=C2=A0 ne= xVortex, NTT, One Source Networks, Optimum Lightpath, Purple Communications= , Rogers Business Solutions, Shoretel, Socket Telecom, Sorenson Communicati= ons, Sprint, Swisscom, TDS Telecom, Time Warner Cable, Telefonica Internati= onal, Telmex, UNINETT, Verizon, Vocalocity, Vonage, Voxbone, WDT (World Dis= count Telecommunications), Wholesale Carrier Services, XO Communications, a= nd Ziggo.

In addition to carrier participants, SIPNOC regularly attracts a group = of SIP community stakeholders from vendors, governments and research organi= zations such as AudioCodes, Avaya, Broadsoft, CableLabs, Cequint, Cisco Sys= tems, Commetrex, Current Analysis, Dialogic, ECG Inc, Edgewater Networks, E= ricsson, Faxcore, Federal Communications Commission, GENBAND, Georgetown Un= iversity, Huawei Technologies, iconectiv, Integrated Research, Internet Soc= iety (ISOC), Metaswitch Networks, NENA, NetNumber, NTCA, Oracle, Patton Ele= ctronics, Polycom, Public Knowledge, RecordMyCalls, Sangoma Technologies, S= ansay, SecureLogix, ScanSource, SNOM Technology, Sonus Networks, UNH-IOL,= =C2=A0 Unify, and Yealink Network Technology.

You can review the SIPNOC 2014 conference schedule and list of presenters= now. Speakers will explore critical =E2=80=9Creal-world=E2=80=9D service p= rovider challenges related to SIP applications and infrastructure, includin= g: network security, SIP trunking, testing and application development, Fax= over IP, call routing and peering, IPv6, troubleshooting and monitoring, e= mergency services and more.

SIPNOC 2014 Registration Information
For = a limited time, you can take advantage of a special discounted rate of $895= , a savings of $100 off the regular rate. To obtain the discount, enter the= following code on the registration page: =E2=80=9Csipnoctmc100=E2=80=9D. Y= our registration includes access to all conference sessions, keynotes, meal= s and breaks, plus networking receptions each evening.

To register for SIPNOC 2014, please visit http= ://www.regonline.com/sipnoc2014.

Don't Forget!
Individuals fro= m SIP Forum Full Member companies save even more! Please contact Marc Robin= s, SIP Forum President and Managing Director, at marc.robi= ns@sipforum.org to obtain the exclusive Full Member discount cod= e.

Hotel Reservations
SIPNOC 2014 is located= at the four-star Hyatt Dulles Hotel. To reserve your stay at the Hyatt Dul= les, please visit: https://resweb.passkey.com/go/= SIPNOC2014

=

For more information, please visit:
www.sipnoc.org or email sipnocinfo@sipfor= um.org

= =


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


--047d7b87371e2d155a04fa9edb53--

Hi,

 

Below is a link to a discussion document, submitted = to the upcoming 3GPP CT1 meeting, showing use-case message flows for iotl (= using the SIP URI parameter solution).

 

ftp://ftp.3gpp.= org/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_87_Phoenix/docs/C1-141755.zip=

 

You can skip the THIG flows.

 

Regards,

 

Christer